instructions for using gxwriter as standalone py script?

[merlinlcb]

i see that there was a recent change to the gx.py script stating it made the script useable for other applications, im currently trying to use this for post processing gcode made by prusaslicer, but i cant seem to get gx.py to even work, it will not allow me to use the script on my already made gcode, so im wondering, what am i doing wrong? p.s. sorry if i shouldnt have put this in as an issue, but i didnt see anywhere else to put it

[ronoaldo]

Hi @merlinlcb - thanks for reaching out! I don't have any community setup so here is a good place to discuss.

The script hasn't a documentation/help text so the message is confusing. I have added some help text to the script, and this should clarify a bit how it is expected to work:

ronoaldo@jupiter $ ./gx.py 
Usage: gx.py COMMAND FILE

Where COMMAND can be:
    wrap    will add a basic GX header to the provided GCODE and print the result to stdout.
            Example: ./gx.py wrap testdata/cube.gcode > /tmp/cube.gx

    info    will print info from the GX header.
            Example: ./gx.py info testdata/cube.gx

ronoaldo@jupiter $ ./gx.py info testdata/cube.gx 
File: testdata/cube.gx
Print time: 525 s
Layer height: 0.18 mm
Perimeter shells: 2
Bed temperature: 0 C
Right extruder temp.: 220 C
Left extruder temp.: 0 C
Right extruder filament usage: 756 mm
Left extruder filament usage: 0 mm

ronoaldo@jupiter $ ./gx.py wrap testdata/cube.gcode > /tmp/cube.gx

ronoaldo@jupiter $ ./gx.py info /tmp/cube.gx
File: /tmp/cube.gx
Print time: 761 s
Layer height: 0.15 mm
Perimeter shells: 0
Bed temperature: 0 C
Right extruder temp.: 0 C
Left extruder temp.: 0 C
Right extruder filament usage: 0 mm
Left extruder filament usage: 0 mm

[Santoshsomi]

@ronoaldo Thanks for making this, i did work for me, but when i try to print, finder says, file import error.
Have you faced such problem? im able to print very small files like marvin, cube.

[ronoaldo]

@Santoshsomi - sorry for the delay in my reply!

This is interesting... I am using the plugin from Cura and I print without errors - even printed a small toy for my kid last week using cura 5 and the version 2.0 of m plugin from the Marketplace.

One thing that did happened to me in the early stages and that I do on the Plugin part of the code is to ensure the image is gray scale. If the image has colors, it may embed the '\n' or '\r' characters; for proper importing in the Finder, the image preview must be in a single line in the xgcode header comment.

[Santoshsomi]

well, even from the script from yours converts into gx, but the gcode has to be specifically to be in cura generated one? what if i use other slicer? i know the time, layer height gets mismatched but i seems like im getting file import error.
Does finder check header and footer while its trying to print?

[merlinlcb]

@Santoshsomi - sorry for the delay in my reply!

This is interesting... I am using the plugin from Cura and I print without errors - even printed a small toy for my kid last week using cura 5 and the version 2.0 of m plugin from the Marketplace.

One thing that did happened to me in the early stages and that I do on the Plugin part of the code is to ensure the image is gray scale. If the image has colors, it may embed the '\n' or '\r' characters; for proper importing in the Finder, the image preview must be in a single line in the xgcode header comment.

I've been experimenting with stripping all the features out of the script besides the wrap function in attempts to make this compatible with the export to gcode on prusaslicer/superslicer.

if we remove all the functions and have a copy of the script that does not expect arguments and just automatically assumes you want to wrap them the export SHOULD work seemlessly with other slicers, I could not however get my botched version of the script to work as I believe, before it's saved, the gcode file from prusaslicer/superslicer are a different format when using their export to gcode function.

I haven't doven into their source code yet but it should not be a hard thing to make work with alittle tweaking, one thing to note, I'd built a prusaslicer/superslicer config bundle for a voxel lab variant of the finder that also uses gx and when using prusaslicer/superslicer it was VERY difficult to fine tune first layer settings because the settings from the propietary slicer didn't actually work when made identically in superslicer/prusaslicer

[Santoshsomi]

Hmm, because we are trying to add this finder into our slicer c6.fabheads.com , (you should try and see. Cool cloud based software).

It would be great if you can support this slicer also. I was able to print small cubes but benchy it failed.

[eskeyaar]

@Santoshsomi - sorry for the delay in my reply!
This is interesting... I am using the plugin from Cura and I print without errors - even printed a small toy for my kid last week using cura 5 and the version 2.0 of m plugin from the Marketplace.
One thing that did happened to me in the early stages and that I do on the Plugin part of the code is to ensure the image is gray scale. If the image has colors, it may embed the '\n' or '\r' characters; for proper importing in the Finder, the image preview must be in a single line in the xgcode header comment.

I've been experimenting with stripping all the features out of the script besides the wrap function in attempts to make this compatible with the export to gcode on prusaslicer/superslicer.

if we remove all the functions and have a copy of the script that does not expect arguments and just automatically assumes you want to wrap them the export SHOULD work seemlessly with other slicers, I could not however get my botched version of the script to work as I believe, before it's saved, the gcode file from prusaslicer/superslicer are a different format when using their export to gcode function.

I haven't doven into their source code yet but it should not be a hard thing to make work with alittle tweaking, one thing to note, I'd built a prusaslicer/superslicer config bundle for a voxel lab variant of the finder that also uses gx and when using prusaslicer/superslicer it was VERY difficult to fine tune first layer settings because the settings from the propietary slicer didn't actually work when made identically in superslicer/prusaslicer

@ronoaldo
Anything for this? i want this standalone script to work with our own slicer. Any lead will be appreciated.

[ronoaldo]

Hi @eskeyaar yeah, there are some interesting things we can do. Most of the code on the file gx.py is "standalone python" that could be integrated elsewhere.

The usage of this python module is as follows: you initialize a GX() object. You feed it some metadata and then you "encode" it to generate the header + original gcode.

The refactor I imagine here that would be useful is to have the metadata available in the original gcode itself parsed in this module; part of this is done by the Cura plugin interface and could easily be done in the module itself!

Information such as estimated print time makes the Finder work better with this showing a more interesting progress bar.

How do you plan to integrate with other slicer? As a subproccess call or as a plugin?

[ronoaldo]

Some references:

The part that "parses" the Cura metadata and extracts the data. Could be generalized by parsing the GCode commands:

https://github.com/ronoaldo/FlashforgeFinderIntegration/blob/master/plugins/GXWriter/GXWriter.py#L90

The python module that "encodes" and "decodes" the xgcode binary header format:

https://github.com/ronoaldo/FlashforgeFinderIntegration/blob/master/plugins/GXWriter/gx.py