Cura merging 3 different stl's from different instances
Cura Version
5.4.0
Operating System
Windows 11
Printer
Anycubic Mega S
Reproduction steps
Imported an object into cura and saved gcode to an SD card. Cleared build plate imported another object into cura and saved gcode to the same SD card. Printed those 2 files, no problem. Computer has been rebooted more than once in the last 2 days, deleted the other 2 gcodes from SD card. Imported another object into cura and saved gcode.
Actual results
First 2 gcodes printed perfectly, no problems 3rd gcode printed until layer 7, then moved the Z up a few mm and tried to print in mid-air. I checked the gcode in pronterface and saw that layer 7 starts a previous object from a completely different instance, and layer 44 starts another object again.
Expected results
That's happened to me a few times, like once every couple weeks. This is just the first time I remembered to save the gcode
Add your .zip and screenshots here ⬇️
It's extremely unlikely that Cura would be retaining detail from old sessions - particularly following reboots. To me this sounds more like SD card corruption.
The first transition occurs on line 84,995 where two X coordinates are present on the same line: 10,800 and a more reasonable 122.871. Given the X coordinates leading up to this my instinct is that the 10,800 should be broken up into "10" (the start of a hundred-and-something coordinate) and "800" (the end of an F parameter). If Cura were merging old data it would still generate valid GCode.
The second transition is much, much more obvious - and more broken. Line 126,207 features a large number (221 in all) of NUL characters (characters that have no on-screen equivalent) before finally ending in "4 Y88.23". So not only is it pointing to data in the wrong location on the drive, part of that data is (at least for the purposes of GCode) completely invalid. Again this points to the card rather than Cura - while it's not impossible for it to generate "garbage" output in the case of a bug I can't say that I've ever seen anyone bring it up (and it would get brought up I can assure you).
A third transition occurs on line 126,287. It actually jumps to the very start of yet another file, complete with Cura's automatically generated starting codes. Unlike the others, however, this is an oddly clean break, which seems to occur exactly on a line feed - though that could easily enough be coincidence.
If nothing else I'd be formatting that SD card - preferably with a full (ie Not "quick") format. But ideally I'd take it out of service until its integrity can be verified. That it occurs "every couple weeks" would lead me to suspect that either the allocation table is crossing faulty data or, if you're removing files after printing them, it just takes a little while for it to reach the same affected NAND again.
Yes, this is a classic example of a corrupt SD card. Cura asks the operating system to write the gcode to the SD card. The OpSys doesn't check the memory sectors on the card, it simply writes the file. If the end of the gcode file gets written to a corrupt memory sector, the file starts correctly but there is no "End of File" marker. Then you write another file to the SD card. This time the OpSys writes the beginning of the file to the corrupt sector but the file continues into a good memory sector. Although this file ends correctly, it is missing it's "Start of File" marker.
So the printer merrily prints the first file but never sees an end so it happily continues into the second file which doesn't have a start, but does have proper ending. You end up with a print that has one model on top of another.
I'll go ahead and remove the bug label from this. Let us know if you feel that is premature.
This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.