I’ve recently moved from my Debian laptop to a MacBook Air as my main machine for tech projects and everyday computing. While FlashPrint is perfectly serviceable, I’ve never really been thrilled to use it, so I decided to move over to Cura. However, this presented a challenge. FlashForge uses a proprietary .gx format for their gcode, which includes some extra metadata. This wasn’t required, though, as you could use plain .gcode files on the printer. But of course, a firmware update was released in 2021 that disabled this functionality. Naturally, I could just go back to the FlashPrint app, but I can’t be the only person facing this issue. So I’ve set out to find a way to create .gx files from .gcode files.

Initial analysis

So, the first thing I did was open a .gx file in a hex editor. I picked a very simple print that I created as part of a repair of a bass guitar. It’s just a simple bushing. I also loaded up another print I had designed, a tray that holds scrap pieces of paper for notes. Binwalk didn’t provide any useful output, and looking at the contents, I didn’t see anything immediate to indicate how this is constructed. Blocks like the second and third sections of this dump repeat probably 50 times or so throughout the file:

Hex dump of the beginning of the file

Diffing the uppermost header of the two gx files was interesting, but still fairly opaque to me:

Diff of the initial header

Image extraction

Thinking further about this, I remembered that one of the features of the FlashForge Adventurer is that it will display and image of whatever object you’re printing on the status screen on the printer. Surely this isn’t being generated on the fly by the printer. At this point, I had a hunch that a large portion of this binary header was this image. Thinking about those repeating blocks of information throughout the header made me think that it was most likely a BMP image. Sure enough, the magic number 0x424d appeared a little bit into the binary header on both files, followed by another number, 0x7638 which indicates the size of the image in little-endian, 14,454 bytes. Further confirming my hunch, following this is the exact place that the actual g-code starts in the file. Extracting this into a new file proves my theory:

Preview image in all of its pixelated glory

This leaves us with the following much more decipherable header that follows xgcode 1.0:

Hex View  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F
 
00000000                                 0A 00 00 00 00 00            ......
00000010  3A 00 00 00 B0 38 00 00  B0 38 00 00 79 01 00 00  :....8...8..y...
00000020  41 01 00 00 00 00 00 00  0B 00 B4 00 64 00 03 00  A...........d...
00000030  3C 00 32 00 D2 00 D2 00  01 FF                    <.2.......

Header structure

Before trying to reverse this, I wanted to see if there was anyone else that has tried to do what I’ve done. As luck would have it, I found maugier/rust-xgcode, where the structure of the header had already been almost completely reversed. Of particular interest to me, was this code:

pub struct Header {
    /// Print time, in seconds
    pub print_time: u32,
    /// Filament usage, extruder 0 (right), in mm
    pub filament_0_usage: u32,
    /// Filament usage, extruder 1 (left), in mm
    pub filament_1_usage: u32,

    /// Type of multi-extruder
    pub multi_extruder_type: u16,

    /// Layer height, microns
    pub layer_height: u16,

    /// Function unknown
    pub reserved0: u16,

    /// Perimeter shells, number
    pub perimeter_shells: u16,

    /// Print speed, mm/s
    pub print_speed: u16,

    /// Hotbed temperature, °C
    pub hotbed_temp: u16,

    /// Extruder 0 (right) temperature, °C
    pub extruder_0_temp: u16,

    /// Extruder 1 (left) temperature, °C
    pub extruder_1_temp: u16,

    /// Function unknown
    pub reserved1: u16,

}

By the way, the above code is licensed under the GNU Public License. As such, when I publish my python script to convert this, I’ll make that project licensed under the GPL as well.

Anyway, looking at this code, I actually found that the entire first 16 bytes, including null bytes, are part of the file’s magic bytes. So that just leaves us with:

Hex View  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F
 
00000010  3A 00 00 00 B0 38 00 00  B0 38 00 00 79 01 00 00  :....8...8..y...
00000020  41 01 00 00 00 00 00 00  0B 00 B4 00 64 00 03 00  A...........d...
00000030  3C 00 32 00 D2 00 D2 00  01 FF                    <.2.......

This lines up nicely with the code above. So, my understanding of the header is:

3A 00 00 00 = BMP offset
B0 38 00 00 = Gcode offset
B0 38 00 00 = Gcode offset (repeated)
79 01 00 00 = Print time in seconds (377 = 6m17s)
41 01 00 00 = Filament 0 usage (321 mm)
00 00 00 00 = Filament 1 usage (0 mm)
      0B 00 = Multi-extruder type (11?)
      B4 00 = Layer height (180 µ)
      64 00 = Unknown (100)
      03 00 = Shell count (3)
      3C 00 = Print speed (60 mm/s)
      32 00 = Hotbed Temperature (50 °C)
      D2 00 = Extruder 1 temp (210 °C)
      D2 00 = Extruder 2 temp (210 °C)
      01 FF = Unknown (-255)

Successful Print

Armed with this knowledge. I’ll slice a calibration cube in Cura, and see if it prints. So, I edited the .gcode file, renamed it with a .gx extension, and… file format error. Eventually, I figured out that the issue now was in the starting g-code. FlashForge has published this document, which as far as I can tell is no longer accurate. So I copied the gcode from a previous print, modified it where necessary using the Marlin documentation as a reference, and after some trial and error, I had successfully printed a calibration cube!

Successful print of a Cura-sliced .gx file

However, there are two main issues that I’ve identified so far:

The brim printed in two parts, rather than one thick brim.
The Z dimension of the print is squished down too much.

Fine Tuning

In order to figure out what’s going wrong, I have to find out what the Marlin commands in the original .gx file actually do. So, I went through and commented all of the g-code. For this next part, I have changed some of the parameters to what I found works best for my printer, so if you notice some different values for, say, the hotend temperature, this is intended. So, here’s my understanding of the gx g-code:

M118 X17.55 Y15.00 Z10.10 T0 ;Send text to serial - Perhaps these are print dimensions?
M140 S50 T0 ;Set Bed Temperature to 50
M104 S222 T0 ;Set Hotend 0 Temperature to 222
M104 S0 T1 ;Set Hotend 1 Temperature to 0
M107 ;Turn fan off
G90 ;Absolute Positioning
G28 ;Auto Home
M132 X Y Z A B ;Loads the axis offset of the current home position from the EEPROM and waits for the buffer to empty
G1 Z50.000 F420 ;Linear move with extrusion - Z is the zpos, and F is the feed rate of material
G161 X Y F3300 ;Home axes to minimum (go all the way to a corner?)
M7 T0 ;Mist coolant on - I have no idea why this is here.
M6 T0 ;Flood coolant on - I have no idea why this is here.
M651 S255 ;Execute peel move - I guess this is how the nozzle moves from the print to cleanly break?
;layer_count: 55
M108 T0 ;Break and Continue - Start printing, I suppose?
G1 X15.00 Y-15.00 F4800 ;Linear move with extrusion
;preExtrude:0.20
M106 ;Fans to full speed
G1 Z.200 F420 ;Linear move with extrusion
;structure:pre-extrude
G1 X15.00 Y-15.00 F4800 ;Linear move with extrusion
G1 X15.00 Y15.00 E4.3504 F1200 ;Linear move with extrusion
G1 X-15.00 Y15.00 E8.7009 ;Linear move with extrusion

...skipping ~4400 move (G0, G1, etc.) commands...

M107 ;Fan off
G1 E298.4412 F1500 ;Linear move with extrusion
G1 Z10.100 F420 ;Linear move with extrusion
G1 X17.55 Y.09 F6000 ;Linear move with extrusion
;end gcode
M104 S0 T0 ;Turn hotend off
M140 S0 T0 ;Turn bed off
G162 Z F1800 ;Home axes to maximum
G28 X Y ;Auto Home
M132 X Y A B ;Loads the axis offset of the current home position from the EEPROM and waits for the buffer to empty
M652 ;Undocumented
G91 ;Relative Positioning
M18 ;Disable steppers

Some of these commands were not found in the Marlin documentation, so I referenced this page for those. This pointed me to other resources, like the RepRap G-code reference.

Here is the g-code generated by Cura, with my comments:

M140 S50 ;Set Bed Temperature to 50
M105 ;Report Temperatures
M190 S50 ;Wait for Bed Temperature
M104 S222 ;Set Hotend 0 Temperature to 222
M105 ;Report Temperatures
M109 S222 ;Wait for Hotend Temperature
M82 ;E Absolute - seems to be an alternative absolute positioning mode
;Start Gcode

...repeated commands from above from G28 to M651 omitted...
...these come from printer configuration in Cura...

;End Start
G92 E0 ;Set the current position of one or more axes.
G92 E0 ;Set the current position of one or more axes.
G1 F1500 E-5 ; Linear move with extrusion
;LAYER_COUNT:55
;LAYER:0
M107 ;Fan off (???)
G0 F800 X6.168 Y9.228 Z0.3 ;Linear move without extrusion
;TYPE:SKIRT

...skipping ~270 move commands...

;TIME_ELAPSED:57.592396
;LAYER:1
M106 S255 ;Only now are fans turned on
;TYPE:SKIRT

...skipping ~5200 move commands...
M140 S0 ;Turn Bed off
M107 ;Fan off
;end gcode

...repeated commands from above from M104 to M18 omitted...
...these come from printer configuration in Cura...

M82 ;absolute extrusion mode
M104 S0 ;Turn bed off
;End of Gcode

Here are the differences that I noticed:

Missing from Cura g-code:
- M118 X17.55 Y15.00 Z10.10 T0 ;Send text to serial
- M104 S0 T1 ;Set Hotend 1 Temperature to 0
- G90 ;Absolute Positioning
- M108 T0 ;Break and Continue
New commands in Cura g-code:
- Commands for retrieving and waiting for components to reach certain temperatures, like M105, M190, and M109
- M82 ;E Absolute - I suspect this is a cause of the g-code being rejected.
- G92 E0 ;Set the current position of one or more axes.
Other notes:
- The fan is turned off for the first layer. Maybe this is to improve bed adhesion? I wonder if this is causing the first few layers to be smooshed.

Smooshed first layer

Using this information, I want to try to more closely replicate the g-code in the .gx file. I got it to match up as cleanly as I could, and loaded it into my printer. It prints just fine, but it’s still smooshed, causing the first few layers to bulge out.

So, I started checking the z-offset on the printer itself. Annoyingly, changing this setting seemed to do nothing. Because of this, I resorted to simply changing the z-offset when slicing. This resulted in the same level of print quality that I was getting with FlashPrint. Here’s an example of one such successful print, a quantity marker die that I designed:

Quantity marker die for MTG

Conversion script

I wrote a script to perform this conversion. Simply run main.py FILENAME.gcode, and a gx file will be created in the same directory with the same name as the .gcode file. Thanks for reading. I hope someone facing the same issue I was finds this useful.