Updating to Cura 4.7 broke something

[7s3]

I've been using Cura 4.6 on Windows 10 with X3Gwriter for printing with my Replicator 2.
To get it working, I had to edit the machine instance config [metadata] section by adding 'machine_x3g_variant = r2'

After upgrading to 4.7, this line was stripped from my config files, causing all my new X3Gs to not even be selectable on the printer. After adding this line back in, it allows me to press print, but it heats up and nothing happens.

Any ideas what's wrong? Here's my current config file:

[general]
version = 4
name = MakerBotReplicator #2
id = MakerBotReplicator #2

[metadata]
group_id = 1f4b7576-099e-4475-95d1-5f4e867ad293
setting_version = 15
machine_x3g_variant = r2
type = machine

[containers]
0 = MakerBotReplicator #2_user #2
1 = makerbotreplicator_current_profile
2 = empty_intent
3 = draft
4 = empty_material
5 = empty_variant
6 = MakerBotReplicator #2_settings #2
7 = makerbotreplicator

I also noticed that 'setting_version' changed from 13 to 15, but I'm not sure if that makes a difference.

[Ghostkeeper]

The setting_version changes with pretty much every Cura release. It's to indicate that something changed in the settings list such that old profiles need to be interpreted differently. For instance, between version 13 and 15 the simplification algorithm was corrected so that Maximum Deviation is now actually correctly indicating how much deviation may be taken from the path (previously it was only allowing half of the deviation that the user indicated), and to achieve the same result Cura will then change any existing profiles that override this setting. It's also in this file since sometimes we change the file names of profiles and the list of profiles down in the [containers] header needs to be updated.

These version upgrades don't touch machine_x3g_variant since it's something specific to this plug-in and hasn't changed. It's not really a danger for this plug-in.

I have no idea how the metadata got reset. Cura reads in all entries from this header and stores them in memory. And then saves those same entries again if something changes in the printer (e.g. a different name). They are not erased, not even by a version upgrade. One thing that could have happened maybe was that 4.7.0 had a bug in it that it would not interpret = symbols properly in the values of the INI file, which corrupted the file. Maybe that could've happened if you had a custom profile with an = symbol in it? I'd expect that to get escaped though. This bug is fixed in 4.7.1 so it shouldn't happen again.

This plug-in simply reads machine_x3g_variant from the metadata of the global stack. Usually this would fall back to the metadata of the definition (in your case makerbotreplicator.def.json) but if you override that in the global stack that's fine too. It didn't really change as far as I know.

One thing I could try is to see if there's any difference between Cura 4.6 and 4.7 if the g-code is the same.

What you could do yourself is to try loading up a g-code saved with Cura 4.6, and re-saving that in Cura to an X3G file. Try printing that. If that fails too it's almost certainly something wrong here in this plug-in. But if the g-code from 4.6 succeeds even though it got converted to X3G in 4.7, then the problem with that the printer doesn't print could just be something that changed with Cura itself, or the start g-code or something.

[7s3]

Just opened my STL in 4.6 and exported both G-code and X3G.

• The X3G prints fine
• The G-code converted to X3G using 4.7 does not work.

Importing my STL in 4.7 and exporting X3G also does not print.

[7s3]

Just tried exporting G-code with 4.7 and then using an external tool, GPX to convert it to X3G.
This one printed with no issues so I guess it's a plugin problem.

GPX output below. I think the M92 errors can be ignored...I've always had an M92 command in my startup G-code and Makerbot doesn't support this. Hasn't caused any issues

C:/Users/rm1/AppData/Local/GpxUi/app-2.5.2/gpx.exe -v C:/Users/rm1/Desktop/M_C-Duct-Mini v2.gcode C:/Users/rm1/Google Drive/Oct9Duct.x3g

Loading config: C:\Users\rm1\AppData\Local\GpxUi\app-2.5.2\gpx.ini
Ignoring duplicate machine definition: -m r2

Loaded config: C:\Users\rm1\AppData\Local\GpxUi\app-2.5.2\gpx.ini
Reading from: C:/Users/rm1/Desktop/M_C-Duct-Mini v2.gcode

Writing to: C:/Users/rm1/Google Drive/Oct9Duct.x3g

(line 18) Syntax warning: unsupported mcode command 'M92'

(line 23) warning G92 emulation unable to determine all coordinates to set via x3g:140 set extended position
current position defined as X:0.00 Y:0.00 Z:-5.00 A:0.00 B:0.00
(line 29300) Semantic warning: M140 cannot select non-existant heated build platform

(line 18) Syntax warning: unsupported mcode command 'M92'

(line 23) warning G92 emulation unable to determine all coordinates to set via x3g:140 set extended position
current position defined as X:0.00 Y:0.00 Z:-5.00 A:0.00 B:0.00
(line 29300) Semantic warning: M140 cannot select non-existant heated build platform

Extrusion length: 1.930 metres

Estimated print time: 48 minutes 46 seconds

X3G output filesize: 882014 bytes

GPX finished with code = 0x0.```