-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
instructions for using gxwriter as standalone py script? #16
Comments
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 |
@ronoaldo Thanks for making this, i did work for me, but when i try to print, finder says, file import error. |
@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. |
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. |
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 |
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. |
@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? |
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 |
subprocess call. |
The machine can print a regula g-code file. This special header allows for the image preview functionality to work, as well as the print progress bar. Both need this special header, but that is not a mandatory feature. In other words, you can uninstall the GXWritter plugin and still use the Finder without issues as far as I remember. |
Thanks for he upload! I don't expect Simplify to be able to open that file. Perhaps you can open it with the Flashprint software as well for testing? I'll try your file in both as well as on my printer. My finder needs a nozzle replacement and I'm lazy on that replacement but I'll test it out soon (TM). |
The start gcode macros in recent versions of Cura format the print temperature as a floating point. Other temperature commands in the gcode don't have such behavior. On Finder (version 1?) with the more recent firmware, this causes the temperature to be the fixed to start at 185C, which appears to be the "default start temperature" or some rounding error when reading the floating point temperature. This commit fixes that by parsing the 'M104 SXXX' commands, and changing the temperature by converting it to integer. This also allows the temperature to be embedded to the .gx file header. I took the opportunity to move the parsing commands into the gx.py script, as a way to potentially easy the proccess to make this a standalone script that can potentially be used by other slicers/software. Fixes #21 Related to #2 and #16
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
The text was updated successfully, but these errors were encountered: