<p>You can open the G-code file in any text editor and copy-paste the relevant sections of G-code to reorder them. It will be fairly obvious where one object ends and the next one starts because the printhead will move back down to Z=0; you can do a simple search to find the commands that move to Z=0 (in my version of Cura, it inserts a comment <code>;LAYER:0</code> at the start of each object).</p>
<p>To ensure that the extruder starts in the correct position, look back at the previous print (in the original order) to see where the extruder finished, then insert (at the start of the new print) <code>G92 Exx.xx</code> where <code>xx.xx</code> is the previous position of the extruder. If looking back to the previous print is too tedious, you can also just use the very first extruder position in the print itself and use that. It will just skip printing the very first section of brim/skirt, which doesn't make a big difference.</p>

CC BY-SA 4.0
2021-05-22T11:24:28.557Z
Unfortunately it is not that simple. The position of the extruder progresses from model to model in the original print order - and it is cumulative. So the first model E starts at 0. The second model E starts at (let's say) 23.214 mm because that's how much filament has been extruded so far for your first model. If you just swap them around with cut and paste then the printer will spew forth 23.214 mm of filament before starting your first print then, when it gets to the second one it will retract back to E=0 sucking up air all the way and your second print will be made of thin air.
WildCat
CC BY-SA 4.0
2021-05-22T11:38:05.183Z
@WildCat Good point. You can just use G92 to fix that.
Tom van der Zanden
CC BY-SA 4.0
2021-05-22T12:30:39.057Z
@WildCat The G92 command really does fix that issue. You don't need to (programatically) change all of the E position commands. Using G92 tells the printer that it should "virtually" move the extruder, that is, not physically move it but only update the printer's memory to set the extruder to that position. For example (if the starting position is zero) issuing `G92 E10` followed by `G1 E20` results in 10mm of filament being extruded, the same as if we had just issued `G1 E10`.
Tom van der Zanden
CC BY-SA 4.0
2021-05-22T13:08:06.237Z
OK. My apologies - I didn't fully appreciate the meaning of G92. That would make it a lot easier to re-jig the code with simple cut-paste style re-ordering. It would still help to have a program to do this for many prints on a plate but that should be a lot easier to write. I will experiment a bit to make sure it works in practice before accepting your answer (although if someone could point to a free tool that already does this, that would be even better).
WildCat
CC BY-SA 4.0
2021-05-22T14:10:46.737Z
Switching slicer to relative extrusion mode might be an easier option.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2021-05-23T10:00:17.937Z
@R.. GitHub STOP HELPING ICE Thanks.That does make it a bit easier (less work) to algorithmically recognise the retraction that occurs prior to each new model starting but I wonder why Cura warns of 'extruding slightly less plastic' with relative mode as the E differences appear to be the same to me on inspection (between absolute and relative modes). They also warn that not all printers are compatible but that's not a problem as one can always convert back to absolute mode using the G92 command in the post edited G-code and removing the relative mode once models have been re-arranged.
WildCat
CC BY-SA 4.0
2021-05-23T19:27:17.690Z
@WildCat: It's a matter of cumulative floating point inaccuracy in letting the printer's firmware sum up the the decimal values printed in the g-code, which are each individually inexact, vs getting a new position value from the slicer that gets rounded to the nearest representable value on each move. This is a real mathematical issue, but the order of magnitude of the error is likely much smaller than the error on calibration of your e-steps or filament diameter, so in practice I think it's a non-issue.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2021-05-25T16:05:02.637Z
Exactly. For absolute E values, find the E value for the last print move of object 1 and edit it into a G92 at the beginning of object 2, etc. Then, when you reorder, the values will start at the proper number for each object.
Davo
CC BY-SA 4.0
2021-05-22T11:08:48.157Z
2021-05-22T11:37:53.670Z
2021-05-22T11:37:53.670Z
Tom van der Zanden
<p>SUMMARY: I use a Creality Ender 3 and Cura 4.8 slicer. I need to print multiple objects 'one-at-a-time' (Cura allows this, that is fine) and I must specify the order in which each model is printed but Cura does not have this facility. My question is: how can I change the order of the printed objects by editing the G-code?</p>
<p>DETAIL: Sometimes it is essential or useful to specify the order of printing multiple objects in a 'one-at-a-time' batch print to allow the printing of some objects that are taller than the X-gantry clearance together with other objects that are shorter than the gantry because if you can control the order then you can print the small objects first and then the tall objects (because the gantry won't get in the way of the already-printed small objects but if the tall objects are printed first then the gantry will crash into them). Specifically I am talking about two or more objects printed at roughly the same Y-level on the print bed (I know you can 'get-away' with it if you separate them in Y but I want to print multiple rows of such objects). Without control over print order this cannot be done thereby limiting productivity (number of models per print run).</p>
<p>WHAT HAVE I DONE TO RESOLVE THIS ALREADY: I can control the print order of multiple identical objects in Cura (they are printed in reverse order to their creation as duplicates of an initial model and if there are problems you can sometimes control the order by moving objects around) but this does not work for multiple different objects. I did several Google searches and found some conversations that deal with this issue including on the official GitHub page of the Cura slicer (see for example this <a href="https://github.com/Ultimaker/Cura/issues/6772" rel="nofollow noreferrer">Cura GitHub Discussion</a>). The conclusion given by the Cura developers is that they understand the limitation, but it is not an issue for Ultimaker printers so they have no plans to make user-customisable print order a feature in Cura because it would be too much work for them to do the changes and maintain them. One person mentioned a python script to allow post editing of G-code to change print order but I could find no links to it. Another person described a 'workaround' in Cura to do with grouping and ungrouping models in a specific sequence but this does not work for me (?maybe it only worked in older versions of Cura). Perhaps someone on this forum has G-coding knowledge and could shed some light on how it may be done? [PS: I am only interested in G-code editing solutions for this question, or a Cura workaround that works in v4.8 - I don't use Octoprint/Rasperry Pi controllers].</p>
<p>Thanks.</p>
<p>[EDIT] Thanks to the contributors in the accepted answer I managed to do this with 'cut-and-paste' (via a small C program - you could do it manually but it is tedious and there is more risk of making a mistake if you have many models). I used the comments in Cura's G-code and a few other G-code cues to calculate the correct splice points.</p>
<p>It works <strong>provided</strong> you take care to ensure the new extruder code is either altered according to the new model positions or use the 'relative extrusion' mode when saving the original G-code from Cura (I used the latter method). Also you must splice the G-code at the right points to ensure pre-model start and post-model finish G-code commands are properly carried around and the final model in the original G-code needs a terminal G0 command to be constructed if it is no longer terminal in the new order so that it can properly position the nozzle to go to the next model in the chain. Also you need to ensure M107 is included prior to each model's first layer. There is danger in doing any of this - the new G-code might damage your printer if you get anything wrong - but it can work (at least it has for me).</p>
<p>I made several manual checks on the new re-arranged G-code as well as loading it into Cura and running Cura's nozzle simulator on it to ensure it does what I expected of it prior to risking running it in my printer, but after that it printed OK.</p>

CC BY-SA 4.0
2021-05-25T16:42:37.887Z
This would suggest a useful feature request to forward to the Cura development team, assuming it isn't already in 4.9...
Zeiss Ikon
CC BY-SA 4.0
2021-05-25T17:01:28.897Z
@ZeissIkon The Cura developers know that people want this feature but they don't want to do it. It is potentially dangerous but then messing about with Cura settings (overriding machine defaults for your printer, etc.) is similarly dangerous. As long as people know that and accept the risk then that's fine I think. If there is enough demand then perhaps if I can get my code into a form others can easily use I will post it on GitHub - with a big health warning!
WildCat
CC BY-SA 4.0
2021-05-25T17:33:49.393Z
Seems obvious that you'd want/need to make the shorter parts first, even if they're spread to the corners of the bed.  If they're spread enough, on the other hand, it doesn't matter as long as none of them are high enough to interfere with the gantry and they're far enough apart not to hit the hot end fan cases etc.
Zeiss Ikon
<creality-ender-3><ultimaker-cura><g-code>
Edit G-code to change print order of multiple one-at-a-time print jobs
WildCat
# Edit G-code to change print order of multiple one-at-a-time print jobs

(Asked by: username_0 on 2021-05-21)

SUMMARY: I use a Creality Ender 3 and Cura 4.8 slicer. I need to print multiple objects 'one-at-a-time' (Cura allows this, that is fine) and I must specify the order in which each model is printed but Cura does not have this facility. My question is: how can I change the order of the printed objects by editing the G-code?

DETAIL: Sometimes it is essential or useful to specify the order of printing multiple objects in a 'one-at-a-time' batch print to allow the printing of some objects that are taller than the X-gantry clearance together with other objects that are shorter than the gantry because if you can control the order then you can print the small objects first and then the tall objects (because the gantry won't get in the way of the already-printed small objects but if the tall objects are printed first then the gantry will crash into them). Specifically I am talking about two or more objects printed at roughly the same Y-level on the print bed (I know you can 'get-away' with it if you separate them in Y but I want to print multiple rows of such objects). Without control over print order this cannot be done thereby limiting productivity (number of models per print run).

WHAT HAVE I DONE TO RESOLVE THIS ALREADY: I can control the print order of multiple identical objects in Cura (they are printed in reverse order to their creation as duplicates of an initial model and if there are problems you can sometimes control the order by moving objects around) but this does not work for multiple different objects. I did several Google searches and found some conversations that deal with this issue including on the official GitHub page of the Cura slicer (see for example this [Cura GitHub Discussion](https://github.com/Ultimaker/Cura/issues/6772)). The conclusion given by the Cura developers is that they understand the limitation, but it is not an issue for Ultimaker printers so they have no plans to make user-customisable print order a feature in Cura because it would be too much work for them to do the changes and maintain them. One person mentioned a python script to allow post editing of G-code to change print order but I could find no links to it. Another person described a 'workaround' in Cura to do with grouping and ungrouping models in a specific sequence but this does not work for me (?maybe it only worked in older versions of Cura). Perhaps someone on this forum has G-coding knowledge and could shed some light on how it may be done? [PS: I am only interested in G-code editing solutions for this question, or a Cura workaround that works in v4.8 - I don't use Octoprint/Rasperry Pi controllers].

Thanks.

[EDIT] Thanks to the contributors in the accepted answer I managed to do this with 'cut-and-paste' (via a small C program - you could do it manually but it is tedious and there is more risk of making a mistake if you have many models). I used the comments in Cura's G-code and a few other G-code cues to calculate the correct splice points.

It works **provided** you take care to ensure the new extruder code is either altered according to the new model positions or use the 'relative extrusion' mode when saving the original G-code from Cura (I used the latter method). Also you must splice the G-code at the right points to ensure pre-model start and post-model finish G-code commands are properly carried around and the final model in the original G-code needs a terminal G0 command to be constructed if it is no longer terminal in the new order so that it can properly position the nozzle to go to the next model in the chain. Also you need to ensure M107 is included prior to each model's first layer. There is danger in doing any of this - the new G-code might damage your printer if you get anything wrong - but it can work (at least it has for me).

I made several manual checks on the new re-arranged G-code as well as loading it into Cura and running Cura's nozzle simulator on it to ensure it does what I expected of it prior to risking running it in my printer, but after that it printed OK.

**Tags:** creality-ender-3, ultimaker-cura, g-code

> **Comments:**
> **username_1**: This would suggest a useful feature request to forward to the Cura development team, assuming it isn't already in 4.9...  
> **username_0**: @username_1 The Cura developers know that people want this feature but they don't want to do it. It is potentially dangerous but then messing about with Cura settings (overriding machine defaults for your printer, etc.) is similarly dangerous. As long as people know that and accept the risk then that's fine I think. If there is enough demand then perhaps if I can get my code into a form others can easily use I will post it on GitHub - with a big health warning!  
> **username_1**: Seems obvious that you'd want/need to make the shorter parts first, even if they're spread to the corners of the bed.  If they're spread enough, on the other hand, it doesn't matter as long as none of them are high enough to interfere with the gantry and they're far enough apart not to hit the hot end fan cases etc.  

---

## 1 answers

### Answer by username_2 on 2021-05-22. Score: 3 | Accepted answer

You can open the G-code file in any text editor and copy-paste the relevant sections of G-code to reorder them. It will be fairly obvious where one object ends and the next one starts because the printhead will move back down to Z=0; you can do a simple search to find the commands that move to Z=0 (in my version of Cura, it inserts a comment `;LAYER:0` at the start of each object).

To ensure that the extruder starts in the correct position, look back at the previous print (in the original order) to see where the extruder finished, then insert (at the start of the new print) `G92 Exx.xx` where `xx.xx` is the previous position of the extruder. If looking back to the previous print is too tedious, you can also just use the very first extruder position in the print itself and use that. It will just skip printing the very first section of brim/skirt, which doesn't make a big difference.

> **Comments:**
> **username_0**: Unfortunately it is not that simple. The position of the extruder progresses from model to model in the original print order - and it is cumulative. So the first model E starts at 0. The second model E starts at (let's say) 23.214 mm because that's how much filament has been extruded so far for your first model. If you just swap them around with cut and paste then the printer will spew forth 23.214 mm of filament before starting your first print then, when it gets to the second one it will retract back to E=0 sucking up air all the way and your second print will be made of thin air.  
> **username_2**: @username_0 Good point. You can just use G92 to fix that.  
> **username_2**: @username_0 The G92 command really does fix that issue. You don't need to (programatically) change all of the E position commands. Using G92 tells the printer that it should "virtually" move the extruder, that is, not physically move it but only update the printer's memory to set the extruder to that position. For example (if the starting position is zero) issuing `G92 E10` followed by `G1 E20` results in 10mm of filament being extruded, the same as if we had just issued `G1 E10`.  
> **username_0**: OK. My apologies - I didn't fully appreciate the meaning of G92. That would make it a lot easier to re-jig the code with simple cut-paste style re-ordering. It would still help to have a program to do this for many prints on a plate but that should be a lot easier to write. I will experiment a bit to make sure it works in practice before accepting your answer (although if someone could point to a free tool that already does this, that would be even better).  
> **username_3**: Switching slicer to relative extrusion mode might be an easier option.  
> **username_0**: @username_3 Thanks.That does make it a bit easier (less work) to algorithmically recognise the retraction that occurs prior to each new model starting but I wonder why Cura warns of 'extruding slightly less plastic' with relative mode as the E differences appear to be the same to me on inspection (between absolute and relative modes). They also warn that not all printers are compatible but that's not a problem as one can always convert back to absolute mode using the G92 command in the post edited G-code and removing the relative mode once models have been re-arranged.  
> **username_3**: @username_0: It's a matter of cumulative floating point inaccuracy in letting the printer's firmware sum up the the decimal values printed in the g-code, which are each individually inexact, vs getting a new position value from the slicer that gets rounded to the nearest representable value on each move. This is a real mathematical issue, but the order of magnitude of the error is likely much smaller than the error on calibration of your e-steps or filament diameter, so in practice I think it's a non-issue.  
> **username_4**: Exactly. For absolute E values, find the E value for the last print move of object 1 and edit it into a G92 at the beginning of object 2, etc. Then, when you reorder, the values will start at the proper number for each object.  

---

