What happens to gcode files with CRC errors?
-
I could be way off the mark here but I tried to print a newly uploaded gcode file which resulted in the printer causing what could be be described as mayhem and carnage before I hit my big red emergency stop button. I had selected the file to upload and walked away from the machine before the upload completed (so I didn't see any error messages that might have appeared). Long story short but I deleted the file and uploaded it a second time without making any changes to that file, and it printed fine - (well the hot end moved around like it should but that's another story).
So the question is, if a gcode file is uploaded and that process results in the file getting corrupted with crc errors reported, does that file still get saved to the SD card? If so, can that behaviour be changed so that either the file is not saved to the SD card, or it is somehow marked as a corrupted file?
-
As the file is uploaded over TCP there really shouldn't be any errors as it main job is to ensure error detection and retransmissions as needed among other things.
Thats not to say problems can't occur elsewhere between A and B, would be interesting to have the corrupted file to compare to the original.
-
@bearer said in What happens to gcode files with CRC errors?:
As the file is uploaded over TCP there really shouldn't be any errors as it main job is to ensure error detection and retransmissions as needed among other things.
Thats not to say problems can't occur elsewhere between A and B, would be interesting to have the corrupted file to compare to the original.
I do occasionally get CRC errors on the ancient laptop that I have in my garage. In the early days, it used to happen a lot when uploading new firmware files but that was in the very early pre-beta days of RRF3/Duet 3. However, this is mostly fixed and if I happen to be standing in front of the laptop, whenever I upload a file, if there are CRC errors, I get to see them.
But back to my original question - what happens to a corrupted file if I turn my back and don't see the CRC errors as they occur? Is that file still saved to the SD card and if it is, can that behaviour be changed so there is some way of knowing that the file one is about to print may result in mayhem and carnage?
Edit. I maybe should say that I'm running stand alone, the printer is hard wired via Ethernet, the laptop is connecting wirelessly. But while that might explain the reason for files occasionally getting corrupted, it has no bearing on the question of what happens to said corrupted files.
-
I assume you are uploading via DWC? If so then this is what happens:
- During upload the new file data is written to a temporary file
- At the end of the upload the CRC is checked
- If there is no error any existing file with the same name is deleted and the newly uploaded file is renamed to the correct name
- If there was an error then the temporary file is deleted (and any previously exiting version is left unchanged).
You can see the code that does most of this here: https://github.com/Duet3D/RepRapFirmware/blob/v3.02-dev/src/Networking/UploadingNetworkResponder.cpp#L79
So it doesn't look to me like there is any way that a file with a detected CRC error caused your problem. Having said that CRC checks are not totally foolproof. Also the CRC check is only performed on the data before it is to be written to the file, it does not read the data back from the SD card, so if there is problem with the SD card the CRC check will not detect that.
-
@deckingman I had some super weird shit happening that was cause of the dead SD card, I wrote about it on the forum... the SD card was reporting everything is ok but when RRF tried to read back the data all hell broke loose
@bearer tcp/ip error checking is very rudimentary and far from bulletproof, the additional error checking is always required. For e.g. in the early mysql replication, the biggest issue to break replication was broken packages that tcp would pass trough but were actually full of #%$^@ so until we implemented additional crc check the only way to run replication safely was to run it trough SSL where ssl would do additional error checking or run it trough some secure vpn channel where vpn channel would do second layer error checking
-
@gloomyandy Thanks for the explanation. If that is indeed what happens, then, as you say, the problem must be elsewhere. The second attempt after deleting and re-uploading the file must have been pure coincidence. I'll bung another SD card it and see what happens.
-
@deckingman another test to do is to download the offending file back to your PC and then use a file comparison software to see if they are identical.
I use the comparison plugin for notepad++ but there are lots of different comparison programs out there.
-
@gloomyandy said in What happens to gcode files with CRC errors?:
I assume you are uploading via DWC? If so then this is what happens:
- During upload the new file data is written to a temporary file
- At the end of the upload the CRC is checked
- If there is no error any existing file with the same name is deleted and the newly uploaded file is renamed to the correct name
- If there was an error then the temporary file is deleted (and any previously exiting version is left unchanged).
Just to be clear, this is the behaviour in RRF 2.05, 2.05.1, and RRF3 3.0 and later. Earlier versions of RRF did not upload to a temporary file.
-
Unfortunately, I deleted the file and uploaded it again, so I have no way of knowing if it was indeed corrupted or whether something else caused the printer to misbehave.
@T3P3Tony - Thanks - I'll bear in mind the file comparison thing.
@dc42 - Thanks. I guess that explains why there were issues in the very early days way back in mid 2019 and that they are now fixed (I'm running 3.1.1.)
-
@arhi said in What happens to gcode files with CRC errors?:
@bearer tcp/ip error checking is very rudimentary and far from bulletproof, the additional error checking is always required.
interesting, guess I'm used to most things having the added benefit of TLS then. the only corrupt file issue I've had I can remember is recently a firmware failed with a CRC error that had to be recovered by uBoot and serial download but no idea where the error was introduced.
