# Reverse the X-axis of a G-code file

I've got some sliced models that represent the right-side arms and legs of a robot. I'm really happy with how they printed, so now I'd like to print the left-side arms and legs.

I was thinking it would be pretty trivial to parse the G-code file using Python and change the value of all the Xn commands from n to 2*h - n, where h is in the middle of the bed, say 110 or 120 mm for an Ender 3.

Before I fire up my favorite IDE, are there any major gotchas I might encounter from such a naïve approach to mirroring the G-code like this? I originally sliced in Cura 4.9.1.

• There are g-code visualizers which will allow you to open your newly modified file to observe obvious problems. Is your reference to the middle of the bed valid? I've not examined a g-code file sufficiently enough to note if the origin is the bed center or a specific corner. Jul 3, 2021 at 0:09
• @fred_dot_u good point, I suppose I could find the bounding box of the print while I'm parsing the file. At least on the Ender 3 the home position seems to be at (0,0,0). Jul 3, 2021 at 1:41
• often times you can scale with a -1 value to mirror an axis if your slicer does not have an explicit mirror option. Jul 3, 2021 at 3:32

If your slicer does not have a mirror operation or a scale that allows negative values then mirroring in the G-code should be straightforward.

As long as your printer doesn't have certain specific tool change or homing or purge positions that are done in the G-code you can just transform it, otherwise you would want to skip these sections and just do the model data (it should be obvious looking at the code where model data starts).

In order to mirror it you just need to swap out the X coordinates in your G-code, If (0,0) is the center of your bed, as is often (but not always) the case for delta printers you will just want to negate the X, so G1 X30 Y-3 Z2 becomes G1 X-30 Y-3 Z2. If your coordinates have (0,0) in a corner (often the case for orthogonal printers) then you want to subtract X from the maximum X value. for instance if your bed is 250 mm wide then in G1 X30 Y10 Z3 X30 becomes X(250-30) or G1 X220 Y10 Z3.

There is only one caveat, some slicers will switch to relative movement using G91 for certain operations and then back to absolute with G90, so you will want to look out for these. Between a G91 and a G90 you will want to negate the X, no matter where the origin of your printer is.

When writing your script, I'd keep track of the minimum and maximum values encountered and the new minimum and maximum values and print them at the end as a sanity check so you can see if anything is wonky.

Based on @John Mecham's comprehensive answer, I whipped up a quick proof of concept. In the image below, the left arrow (top) is the original and the right arrow (bottom) is the reversed clone. Cura does generate a little relative offset code at the end, I think I handled it correctly.

import re

data_start = re.compile('^;LAYER_COUNT:[0-9]+')

new_data =[]
BEDX = float(235)
h = BEDX # Absolute Positioning is default

mode='Skip'

with open(ifilename, 'r') as ifp:
for d in ifp:
new_d = ''
tokens = d.split()
if len(tokens) == 0:
pass
elif mode == 'Skip':
new_d = d[0:-1]
if data_start .match(d):
mode = 'Go'
else:
if tokens[0] == 'G91': # Relative Positioning
h = 0
elif tokens[0] == 'G90':# Absolute Positioning
h = BEDX

for t in tokens:
if t.startswith('X'):
if len(t) > 1:
x = h - float(t[1:])
t = 'X'+f'{x:.3f}'
new_d += t+' '

new_data.append(new_d)

with open(ofilename, 'w') as ofp:
for d in new_data:
ofp.write(d+'\n') # how does writelines not support a line separator?