Editing G-Code – a cautionary tale

[Tony JeffreeParticipant @tonyjeffree56510]

I have an Ender 3 that I use from time to time – I’m afraid my excursions into 3D CAD have been fairly primitive so far, so in the last week, when I wanted to modify a Thingiverse design for a router base I decided to have a go at editing the G-Code rather than re-drawing the part in 3D CAD. Partly sheer laziness on my part, but partly the realisation that as the part had a long section of M54 X 4mm thread (!), it might take a while to get the design “just right” in CAD, and at ~ 5 hours of printing per part that could end up being very time consuming.

Anyhow, there ensued an interesting excursion into the mysteries of 3D printer G-code. Easy enough to pick out, and delete, the chunk of code representing the material I didn’t want – the part printed vertically, and I just had to pick out the Z moves for the section I wanted to remove, and edit the Z values of the subsequent moves to adjust for the removed material. The section removed was 33mm long, starting from 25.04mm above the build plate, so all Z values in moves from 58mm onwards needed reducing by 33mm. So far, so good. Saved the file, started up the printer. All was well until it reached the 25mm level, and then the printer ejected the filament from the extruder, and carried on doing “air moves” for the rest of the program – at least, until I killed the run.

Much head scratching etc., until a bit of research on ‘t web revealed the non-obvious (to me at least!) fact that the extruder feed is controlled by the same G1 commands that control the printer moves – the parameters X,Y,Z define the end position, F defines feedrate, E defines the length of filament that will be extruded during the move. Unfortunately, and very counter-intuitively, the E value is either absolute or relative, depending on whether you are using absolute or relative coordinates, and Cura seems to choose to use absolute coordinates (selected with M82). This means that the E value is the absolute length extruded since E was last zeroed (using a G92 command); the amount extruded in any one move will be the value of E in that command less the value of E in the previous command. Thankfully, in my case, somewhere in the chopped out section of code there was a G92 E0 command that reset the extruder, and the E value in the first command after the cut was less than the last value before, so the machine unloaded the filament – if it had been the other way around, the machine would have attempted to extrude a very large amount of filament during the first move after the cut, which would have been “interesting”.

Inserting a G92 EXXX after the cut to reset the extruder to XXX, the value of E in the last move of the deleted section, restored proper operation and the part then printed as I had intended.

It did leave a question in my mind as to why the slicer chooses to operate in absolute coordinates – seems to me that life would be a lot simpler for the average hacker if the file was specified in relative moves. Anyone know why they do this? Obviously, for the most part, it doesn’t matter, only when you need to go into the code and “fix” stuff.

[Martin ConnellyParticipant @martinconnelly55370]

Why use absolute and not relative?

A loop using relative moves is a useful way of keeping code short for a part with a repetitive form. If it is using absolute mode then there is a requirement to keep incrementing one of the values in a loop or to not even go as far as using a loop but, using the sledgehammer method, explicitly writing every line of code with the increment in it.

So for example, you are printing a square section like a piece of RHS. There is some code for the layer to complete one layer (eg 20 lines). You then move up the required thickness and repeat that same piece of code. Clearly for a simple part like this the layer code can be put in a loop. If the layer is 0.1mm thick you move up 0.1mm after each layer so for a total height of 50mm you would have 500 layers. If you loop the layer code 500 times it is quite a short program but in absolute mode you would have to change the Z value after every loop. In absolute mode you would just say move up the 0.1mm thickness. Explicitly writing each line in absolute mode would result in 500 times the 20 lines of code for one layer, 10000 lines, and 500 Z axis values.

Once you have this code if you want to put it on top of a flat plate it is just a case of setting the starting coordinates in absolute mode and then switching to relative to place it at whatever height is needed to cater for different plate thicknesses.

A length of thread would be an ideal candidate for a loop for one pitch in relative mode. You may also have a nested loop for the helix angular rotation per layer. Clearly being able to do this in a relative way makes everything simpler.

For a program producing the code it would be sensible to get it to look for sections where a loop can be used to keep the total lines of code low. Maybe this is something that takes a lot more coding and was put in the “too hard and gives a small return box” so we will just use the 10000 lines of code sledge hammer method. That is part of the trouble with modern computers and programmers, they can easily write a program that churns out and handles the 10000 lines of code where a human writing the Gcode would want to minimise their work and keep the line count low.

Martin C

[FulmenParticipant @fulmen]

I refuse to even touch g-code. If they can’t make it readable I can’t be arsed to learn it. What other programming languages use random numerical codes rather than legible commands?

[Tony JeffreeParticipant @tonyjeffree56510]

This is code generated by a “slicer” rather than by a human, so definitely falls into the sledge hammer category – far too hard to write a code generator that would optimise the output (I can entirely understand that having worked on the development of programming language systems in a former life) so this is definitely a case of many thousands of lines of code where maybe a couple of thousand would do. However, just thinking about what the slicer needs to remember during the code generation, it seems to me that relative moves would actually be easier for it (as well as for me).

[Fulmen]

On Fulmen Said:

I refuse to even touch g-code. If they can’t make it readable I can’t be arsed to learn it. What other programming languages use random numerical codes rather than legible commands?

I cut my programming teeth on machine code/assembler – at one time, I could programme a PDP8 in octal – so that doesn’t bother me.

[Fulmen]

On Fulmen Said:

I refuse to even touch g-code. If they can’t make it readable I can’t be arsed to learn it. What other programming languages use random numerical codes rather than legible commands?

As one who is crap at all foreign languages I soon got used to programming G code back in the day, nowadays the advanced software will do most of it for you.

Tony

[SillyOldDufferModerator @sillyoldduffer]

I thought Cura supported relative movement under Preferences->Special Modes, but the pop-up hover tip is discouraging:

Looks like Cura decided to keep it simple by not producing relative G-code because not all printers support it, so they avoid an extra level of complexity that not many users are smart enough to want.

Nice programming challenge though:  write a program to convert absolute g-code into relative g-code.  Bet somebody’s done it already.

Dave

 

 

[Tony JeffreeParticipant @tonyjeffree56510]

Interesting. I will look more closely at the Cura settings.

Having said that…

The ideal combo for what I was doing would have been absolute x/y positions and relative z/e positions, because if you go relative for all 4, when chopping out a section of code you have to be very careful about the first relative x/y move after the cut because your starting position for that move would have been affected by the code you chopped out… Nothing is straightforward unfortunately!

[FulmenParticipant @fulmen]

You’re one of those, eh? Had a friend like that back in the days, he coded the C64 in straight hex. That was something to behold.

Still, I can’t believe I’m the first to complain about this. It makes no sense using nondescript codes like that, and whatever limitations that lead to this blunder surely isn’t an issue anymore. It could even be done at the editor level.

[Tony Jeffree]

On Tony Jeffree Said:

On Fulmen Said:

I refuse to even touch g-code. If they can’t make it readable I can’t be arsed to learn it. What other programming languages use random numerical codes rather than legible commands?

I cut my programming teeth on machine code/assembler – at one time, I could programme a PDP8 in octal – so that doesn’t bother me.

I used to be fluent in PDP8 and could enter the bootstap with my eyes closed

– now all I can recall is ‘7402’ ( Halt! )  🙂

 

IanT

[IanT]

On IanT Said:

On Tony Jeffree Said:

On Fulmen Said:

I refuse to even touch g-code. If they can’t make it readable I can’t be arsed to learn it. What other programming languages use random numerical codes rather than legible commands?

I cut my programming teeth on machine code/assembler – at one time, I could programme a PDP8 in octal – so that doesn’t bother me.

I used to be fluent in PDP8 and could enter the bootstap with my eyes closed

– now all I can recall is ‘7402’ ( Halt! )  🙂

 

IanT

Yes, I used to be able to do that on the keys on the front panel – the RIM loader if I remember rightly! Great little machine – all of 32K of 12 bit memory – and we used them to control chemical plant. Amazing what you can do if you don’t have to control GUIs etc…

[SillyOldDuffer]

On SillyOldDuffer Said:

I thought Cura supported relative movement under Preferences->Special Modes, but the pop-up hover tip is discouraging:

Looks like Cura decided to keep it simple by not producing relative G-code because not all printers support it, so they avoid an extra level of complexity that not many users are smart enough to want.

Nice programming challenge though:  write a program to convert absolute g-code into relative g-code.  Bet somebody’s done it already.

Dave

 

 

I tried a brief test with that – looking at the G-code output it looked very much as if the extruder commands were still absolute, so I have no clue what that setting actually does.

Long term, the solution to this problem is going to be to learn 3D CAD – editing the G-Code gets way to long winded except in the simplest of cases.

[Author]

Posts