Plugin seems to default to R1(?) settings and does not seem to create and use the temp .ini file

[UnmannedCam]

Hi!

I know github has certain etiquette and formatting which I'm not entirely privy to, please forgive my formatting and general lack of understanding in this regard, and in the inner workings of Cura, I created an account just to report this to the best of my ability to see if I can help others here :)

I'm reviving an old R2X - essentially it's been converted to a R2H with a single e3d v6 hotend. One of the goals was to swap to Cura as a slicer, so this plugin is perfect.

I noticed that the commonly reported fix for oversized prints to change the machine instances definition to include "machine_x3g_variant = r2h" (as otherwise you'll be using r1 steps) wasn't working for me - it seemed Cura was replacing the file every time it was loaded (I'm using 4.6, it looks like this doesn't happen for everyone using 4.6?), so I turned to modifying X3GWriter.py to hard-code the machine type there instead.

Originally, I was doing this by changing line 34:

"machine = self.gpx_machine()" , to:
"machine = r2h #self.gpx_machine()"

which was working well until I had a need to calibrate steps per mm for this specific machine due to the drastic extruder and hotend changes I've made. I noticed from other reported issues that it should be possible to use the "Printer Settings" plugin to change these values, Of course, to do this I'd need to remove the hardcoded "r2h" and restore line 34 to "machine = self.gpx_machine()".

This is where I noticed the issue - doing this, I would expect the plugin to not find the machine type as (to my knowledge) it's not defined in Cura, which would mean the plugin, from my interpretation, should default to using "None" machine type, which then would lead to using the Cura settings to create the temp .ini file with the parser at the end of the script.

This was not happening - instead, it seemed the script was managing to read a machine type from somewhere in Cura, as the printer settings within Cura were being ignored, and instead I was getting prints 6% larger, which to me implies that the script was reading the "r1" or some similar variant machine type from Cura, somewhere (perhaps as I'm using the default Makerbot Replicator profile in Cura, the plugin is reading this from somewhere I'm not aware of?).

The "fix" that is working for me was to essentially revert to type and hard code the machine type as "None". I've not yet verified that the script is now reading the settings from within Cura, as I've hard-coded the steps per mm adjustment I needed in the parser portion at the end of the script, though I assume it must be as I can slice without issue and all other settings have to be coming from somewhere?

I just wanted to report this as I hope it will help others in this situation, and to see if this is expected behaviour or a potential issue.

P.S. - unrelated, but Cura 4.6 seems to be as high as I can go without getting broken X3G files - not an issue for me as the higher versions at the moment seem to have an issue with long sweeping sections of prints such as benchy's bow coming out rough!

[tx0h]

hello there..

welcome to github.

good, that you ask right now! can you tell me where in cura 4.8 i do set cr1d (clone of replicator with dual head and heat bed). else, i would write a shell script to call my good old /usr/local/bin/gpx ;-).

i didn't touched my old printer a long time and in those years, when i used gpx from shell, always used r1d as argument.. cura changed a lot since the last years.

greetings

[Ghostkeeper]

If the definition file includes the machine_x3g_variant metadata info, it's expected to pass that on as the profile for GPX. Otherwise it's expected to create the temporary .ini file from the machine settings and pass that to GPX. So basically, if your printer's definition doesn't have that metadata, you'll be using Cura's defaults. Some of these defaults have existed in Cura for a very long time and were most likely set by Ultimaker according to what the early Ultimaker printers used (e.g. default acceleration and such). Others were added specifically for the X3GWriter because I argued it didn't hurt and they could in the future also be used for other printers (e.g. steps per mm). Those are indeed set for the R1 as I considered that to be the "default" one that most people had been using.

The machine_x3g_variant is only set in the definition metadata and as such it's not editable from Cura itself. It can only be edited in the .def.json files in Cura's resources.

I've had it on my mind to update GPX before the Cura 4.9 release, specifically to fix an issue with MacOS not linking to glib properly apparently which may be solved. I'll be sure to integrate any new features they have then.

I've heard before that users got broken X3G files with Cura 4.7+ but I don't know how that could happen since there aren't any new g-code commands in 4.7's output as far as I'm aware. GPX should deal with it just the same. I also don't even have a printer accepting X3G files myself so there's hardly anything I can do to verify what's going wrong. I can only really help through my experience with Cura. I kind of grandfathered into this project at some point and am sometimes at a loss as to how I can help :(

[Ghostkeeper]

I know github has certain etiquette and formatting which I'm not entirely privy to, please forgive my formatting and general lack of understanding in this regard, and in the inner workings of Cura, I created an account just to report this to the best of my ability to see if I can help others here :)

For smaller projects that don't get a lot of traffic, like this plug-in, there is really no etiquette aside from being respectful to each other. I appreciate that people take the time to report issues here and even more that other people help each other getting workarounds like what you wrote down. So thank you for taking the time to report it anyway!
For a bigger project like Cura itself it's literally a full time job to triage all the incoming tickets. I used to do most of that for Cura but since 2021 we actually hired someone specifically to handle all the issues. For those projects it's more important that you work according to their rules; which the templates will tell you about when you try to report an issue 😉