You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I use X3GWriter to export from Cura 3.3.1, the printer does the following, in order:
neglects to heat bed
heats nozzle normally
Moves bed upwards very slowly for a few CM, then quickly the rest of the way up
Moves bed downwards very slowly
I watched it move the bed downwards at a snail's pace for three minutes before giving up
However, if I export from Cura to GCODE, open that GCODE in MatterControl 1.7.5 (another slicer), and export it to X3G using that slicer's GPX integration, the file prints normally.
I've dug into the Cura logs, and into MatterControl's source code, to extract the exact way each is using GPX.
X3GWriter uses GPX 2.6.0, and executes the following:
gpx.exe -c configFile inputFile outputFile
MatterControl uses GPX 1.3, and executes the following:
gpx.exe -p -m r2 inputFile outputFile
I've attached the contents of the config file that X3GWriter is using, the GCODE generated by Cura, and both X3GWriter's and MatterControl's X3G outputs. The last three are zipped in X3GWriter_Comparison.zip. config.txt X3GWriter_Comparison.zip
The text was updated successfully, but these errors were encountered:
X3GWriter version [4.]1.1.1 may fix this for you, but only if your printer provides a metadata entry to indicate what flavour of X3G we should write. If you have a machine definition (.def.json file) for your printer, you can add this line to the metadata section:
"machine_x3g_variant": "r2",
If you don't have a machine definition, you can alternatively also put that metadata in your machine instance. To do this you would go to Help -> Show configuration folder. Find the machine_instances folder there and there should be a file with a name that you recognise as your printer. In that file, add these lines:
[metadata]
machine_x3g_variant = r2
If there is already a [metadata] section, just put the second line under there.
The intent of this is that the designer of the printer definition can set this metadata entry for you and you wouldn't need to worry about it. However with printer definitions being sparse and far between, some manual work is needed.
If the machine_x3g_variant metadata entry is set, I expect X3GWriter to call GPX with the following parameters:
gpx.exe -p -m r2 inputFile outputFile
Or if the g-code flavour in Cura is set to Makerbot:
gpx.exe -g -p -m r2 inputFile outputFile
So that would do what you need. Let me know if [4.]1.1.1 fixes this for you. You can download it from the releases here on Github or in the toolbox if you have Cura 3.4.
If I use X3GWriter to export from Cura 3.3.1, the printer does the following, in order:
I watched it move the bed downwards at a snail's pace for three minutes before giving up
However, if I export from Cura to GCODE, open that GCODE in MatterControl 1.7.5 (another slicer), and export it to X3G using that slicer's GPX integration, the file prints normally.
I've dug into the Cura logs, and into MatterControl's source code, to extract the exact way each is using GPX.
X3GWriter uses GPX 2.6.0, and executes the following:
gpx.exe -c configFile inputFile outputFile
MatterControl uses GPX 1.3, and executes the following:
gpx.exe -p -m r2 inputFile outputFile
I've attached the contents of the config file that X3GWriter is using, the GCODE generated by Cura, and both X3GWriter's and MatterControl's X3G outputs. The last three are zipped in X3GWriter_Comparison.zip.
config.txt
X3GWriter_Comparison.zip
The text was updated successfully, but these errors were encountered: