Request: Support FlashForge .GX output format for G-Code
cme-linux opened this issue · comments
The FlashForge company distributes a closed-source slicer, FlashPrint, for their 3D printers. For printers that are equipped with a touchscreen, FlashPrint makes .GX files for download to the printer. These files are ordinary ASCII G-Code with a mostly binary header added. The header contains a preview bitmap and a few other things.
Please consider adding support for this file format in Slic3r. This would enable open-source software to send 3D models to the printer, allowing the model to be chosen graphically on the printer's touchscreen, using the preview bitmap.
I've done some reverse-engineering of the .GX format using a FlashForge Guider II printer.
The closest I've found to FlashForge support in open-source software is https://github.com/markwal/GPX which is available in Debian as the "gpx" package. (Code in that program may help with the requested improvement to Slic3r.)
GPX has a printer definition “fcp” which means FlashForge Creator Pro. The “fcp” printer definition is an alias for MakerBot Replicator 1 w/ dual extruder (known in GPX as “r1d”). The fcp/r1d type of 3D printer has the following notable differences vs. the Guider II:
- fcp/r1d has 2 extruders; Guider II has only 1 extruder.
- fcp/r1d has only a text screen; Guider II has a touchscreen that shows a preview picture.
I've uploaded http://www.mediafire.com/file/behrxm66nn3a6eb/Slic3r_GX.zip/file which has 4 sample files:
- An .STL given to FlashPrint.
- The output .GX file.
- The .BMP extracted from the .GX.
- The G-Code extracted from the .GX.
The 4 files might have some slight version mismatches. I don't think you could generate the .GX file from the .STL yourself anyway, without knowing the exact FlashPrint configuration, which isn't in the .ZIP. The .STL is included just so you can see what the model to be printed looks like.
In case anyone wants to download the .STL and use it for some other purpose: The .STL and its derivative files (.GX) are a work in progress for its own design project. It is not approved for distribution or modification except for this reverse-engineering. Since I haven't said what it's for, you won't want to use it anyway. An improved version of it may be released in the future under some open-source license.
To extract .BMP from .GX in Linux:
dd if=”file.gx” of=”file.bmp” skip=58 count=14454 iflag=skip_bytes,count_bytes
To extract G-Code from .GX in Linux:
dd if=”file.gx” of=”file.gcode” skip=14512 iflag=skip_bytes
All text in those 2 commandlines is literal except for the filenames- file.gx, file.bmp, file.gcode
Byte offsets in the .GX file, as stated in this feature request, are 0-based. All numbers are little-endian binary (2 or 4 bytes) unless specified to be ASCII plaintext.
Offsets through 0x1B seem to contain constant data:
- The string "xgcode 1.0" terminated with a newline & NUL.
- Then four 32-bit constants. (0, 58, 14512, 14512)
- 58 is a pointer to the start of the bitmap
- 14512 is a pointer to the start of the G-Code
Offsets 0x1C through 0x39 seem to contain the following variables. The first three are 4 bytes; the other ones are 2 bytes.
- 0x1C - print time in seconds, 4 bytes.
- 0x20 - filament usage in mm, 4 bytes.
- 0x24 - unused (zero), 4 bytes.
- 0x28 - unknown; the latest FlashPrint version (1.23.0) seems to put 0x0B here
- 0x2A - layer height, microns (for example, 180 means 0.18 mm)
- 0x2C - unknown; maybe unused (zero)
- 0x2E - number of perimeter shells
- 0x30 - print speed, mm/s
- 0x32 - platform temp, Celsius
- 0x34 - extruder temp, Celsius (on 2-extruder machines, this must be the right-side extruder)
- 0x36 - probably left-side extruder temp; on 1-extruder machines, this value is 0
- 0x38 - unknown; maybe unused (zero)
FlashForge software/firmware uses that data these ways:
- The printer itself uses only the preview bitmap & the 4-byte print duration.
- FlashPrint has a "Slice Parameters" window that uses the 4-byte duration & filament length numbers. The other data in the "Slice Parameters" window comes from parsing the comments at the start of the G-Code, not from the binary header fields:
(That means that Slic3r needs to generate these comments in the same format as FlashPrint.)
- Layer height in mm (not microns)
- Number of perimeter shells
- Fill density (percentage)
- Fill pattern (keywords I've seen are)
hexagontriangleline3dInfill
- Print speed
- Travel speed
- Extruder temp (1-extruder printers use the comment for
right_extruder) - Platform temp
After the header is the bitmap. This starts at offset 0x3A (decimal 58), ends @ offset 0x38AF. The next offset, 0x38B0 (decimal 14512), is the start of the G-code. The length of the bitmap is 0x3876 (decimal 14454) bytes.
The picture is in the ordinary .BMP format, uncompressed, 80 x 60 pixels (0x50 by 0x3C). Some of the following parameters would be taken care of automatically by a .BMP library, but I'll list these parameters anyway. The pixels start at byte offset 0x36 into the .BMP section of the .GX file. There are 256 shades of gray, written as 24-bit color, 3 bytes per pixel, all 3 bytes having the same value.
The .BMP pixels-per-meter values are set to 0x1274 which is 120 dpi. BMP files contain the pixel rows in bottom-to-top order.
The background is black and the 3D model is shown in an angled perspective view (lines parallel to the coordinate axes converge slightly into the distance).
It should be OK to state "ffslicer 1.23.0" in the version comment produced by Slic3r. A comment line could be added, after the ones read by FlashPrint's "Slice Parameters" window, that states that Slic3r made the file.
If I see a pull request, I will consider it. It would need to include its own feature level self-tests.
We, however, tend to not like supporting/enabling closed source systems. It isn't adding benefits for most of the people who would develop for Slic3r (I, for one, don't own a FF or a MakerBot Replicator), and reverse engineering a system that you don't own any working components for is painful at least.
The current recommended toolchain for people wanting to use Slic3r with MakerBot-derived printers is to use gpx as a post process step.
I thought of making this feature request in gpx, but would Slic3r have better access to the 3D model to render it to a 2D bitmap?
I've already done most of the reverse engineering (listed in my first submission to this GitHub issue), and I have access to the FF Guider II for validating any test builds of Slic3r or gpx that attempt to support the .GX file format.
Could a feature be added to Slic3r that just produces the bitmap? Then other code, either a pull request to Slic3r, or something in gpx, could make the complete .GX file.
Putting a preview of the model into the file sent to the printer is becoming more common. See https://www.raise3d.com/pro2/ under "Intuitive User Experience", the first & fourth screengrabs. Does Slic3r currently have any support for this? If not, would a .BMP be an easy beginning to this support?
Since the .GX format is so simple, is there anything preventing support for it from being added to open-source printers once it's supported in Slic3r or other open-source apps?
The FF Guider II in question is at a nonprofit organization. Output from Slic3r to this printer will be a big step toward integrating open-source software into this organization. So the suggested feature will definitely support/enable an open-source system for dozens of users. Output to this printer without the preview picture is possible, but will make users think open-source is a second-class citizen.
@cme-linux I am not saying "no", I am saying "I have little interest in maintaining this feature". Ergo, you would be the first point of contact for bug reports specific to this feature :).
Like when flashforge changes something and the code breaks.
I thought that, since Slic3r already displays the .STL on the 2D monitor, many of the needed libraries for bitmap rendering are already called by Slic3r. Whereas gpx doesn't seem to do this. So I thought it would be better to ask for preview-bitmap support in Slic3r than in gpx.
I will keep thinking about this and possibly work toward a pull request. I don't know yet. In any case, I will be grateful for any interest that others may show about this feature.
It's rendered in the GUI. There is an SVG export for slices.
Hi! I was trying to find a way to include the preview inside the .gx file for my finder as well. The description you provided sounds amazing.
I can try making a small tool for that this way: given a .g (gcode) and a .stl input file, generate a .gx output file as a post-processing script. Once that is done, I can try to integrate the algorithm as either a slic3r plugin or as part of it's core and let the project owners evaluate if this is a good thing or not.
Hello, I just thought I'd add to this discussion that many monoprice printers utilize this .gx file format as well. I would personally find it helpful if any tool other than the proprietary FlashPrint software could export a gx file.
...
- 0x1C - print time in seconds, 4 bytes.
- 0x20 - filament usage in mm, 4 bytes.
- 0x24 - unused (zero), 4 bytes.
- 0x28 - unknown; the latest FlashPrint version (1.23.0) seems to put 0x0B here
- 0x2A - layer height, microns (for example, 180 means 0.18 mm)
- 0x2C - unknown; maybe unused (zero)
- 0x2E - number of perimeter shells
- 0x30 - print speed, mm/s
- 0x32 - platform temp, Celsius
- 0x34 - extruder temp, Celsius (on 2-extruder machines, this must be the right-side extruder)
- 0x36 - probably left-side extruder temp; on 1-extruder machines, this value is 0
- 0x38 - unknown; maybe unused (zero)
...
Adding to this list, I can say that there are some for the left extruder too (I have a Creator 3)
- 0x24-0x27 is left extruder filament usage in mm (4 bytes)
- 0x28-0x29 seems to be the multi-extruder type (mirror / duplicate / none). It made it 0x0b when it was none, and 0x1b when it was duplicating (The printer is an IDEX one)
- 0x36-0x37 is left extruder temperature (Celsius) (2 bytes)
I tried just pasting a colour bitmap that I made in the bitmap position when editing a gx but unfortunately the printer did not like it.
I'm probably going to be able to write a Cura plugin to write into this format, I got a starting point from another similar plugin that does just that but for another printer. Can the code in Python be ported to Slic3r?
Experimental Cura plugin is here. I can't test it because my FlashForge is behaving Oddly but if the code is working I would love to port it do Slic3r too. It was faster to prototype for Cura as I'm using it more often.
I guess I'm into something here. I managed to load a Cura generated file with the proper header and got the printer to recognize a placeholder image as well as the file print time. 🦸 I can make a version of it that acts as a post-processing script so it could be used as a Slic3r post-processing.
Is it possible for the post-processing script to get an image from the print bed? That would make the script pretty sweat.
OK, I got a working prototype here Ultimaker/Cura#7829 (comment)
@cme-linux I'm not sure you want this for Slic3r yet, but I invite you to try out the Cura prototype as well, may be useful for you. I can work on the python script (gx.py) so that it can be used as a standalone Python program for post-processing, but image will be a dummy one, or at most, some text over image based on some gcode metadata.
Hello, I just thought I'd add to this discussion that many monoprice printers utilize this
.gxfile format as well. I would personally find it helpful if any tool other than the proprietary FlashPrint software could export agxfile.
I got a working prototype for Cura software that can output the .gx files. Combined with a Gnome thumbnailer it seems to be pretty cool now:
You can install the GXWriter plugin and test with your monoprice, the header is binary compatible with the one output by Flashprint.
I'll give it a shot this weekend, and let you know how it goes
any luck in getting Slic3r version working ? I've got a Flashforge Guider IIs and would love to have a .gx export support in Slic3r
Thank you all so much for your endeavors! I recently bought an MP voxel and was disappointed to learn that I was so limited in my slicing options - especially when it came to infill patterns. I had been manually copy/pasting the gcode created by cura into the proper portion of a .gx file, which worked - but I lost all the advantages of the lcd during the prints. I set out to do exactly what you guys did so I could un-tether from the flashforge software entirely. Before I made it here, I found this printer defintion - which worked , and this, which lets you print over wifi without Flashforge. Unfortunately I was still losing out on the preview and countdown timer. Now (thanks to you), not only can I cut out the more tedious bits of my workflow - I also get my preview icon and time remaining on my prints back.
Excuse me, I think it would be useful to add more file formats. I use a printer that only supports .g & .gx. Then I'd like to tell you that x3g's would probably be the first step, if you number the lines somehow I think you can rename to .g. gx's are very similar to g's also.
https://community.ultimaker.com/topic/33291-can-cura-be-used-to-generate-the-g-or-gx-file/
Sorry, forgot to read the guidelines. I think it is needed because a lot of 3d printers use gx and g files only.
also the printer I use is FlashForge Adventurer 3.
All in all, I love Slic3r
The particular format of xgcode from Flashforge is supported by the plugin I published to the Markeplace. It is available in the renamed repository here: https://github.com/ronoaldo/FlashforgeFinderIntegration and also available in from the Marketplace here https://marketplace.ultimaker.com/app/cura/plugins/Ronoaldo/GXWriter