RatOS Post-Processing Introducing Errors in GCode (More like destroying good GCode)
I've recently run into issues with what seems like the RatOS post processor mangling GCode. For background, I sliced a model (actually had errors in a couple other earlier prints of different parts too) in PrusaSlicer 2.9.0 for my VCore4 IDEX with the 400 IDEX machine selected in PrusaSlicer. When I upload it to the printer to print, at some point the printer errors out during the print saying some ridiculous move out of range error: "Move out of range: 1882.736 206.573 4.148 [2567.194]"
That X movement is of course impossible. Knowing I was already running into issues earlier with a model I directly uploaded to RatOS from PrusaSlicer, I had opted to export the GCode from PrusaSlicer first and then uploaded to RatOS using the webUI. It turns out, the RatOS post processing seems to damage the GCode, introducing syntax errors and whatnot (posted the screenshot of some examples). I have no clue how that happens...
I've attached both the pre and post processed files in case anybody is able to discern something... debug zip is also attached in a later comment
I am on: PrusaSlicer 2.9.0, RatOS v2.1.0-RC3-26-g33980992
23 Replies
I just uploaded the same PreProcess file a few times to RatOS and it looks like the RatOS postprocessor seems to process the same original file differently...
Each time, I cleared out the original PreProcess file, uploaded the preprocess file, and then hit print so that RatOS would post process the file. Then I would download the file through SFTP, rinse and repeat. I would rename the downloaded file as "...PostProcess_roundX", where X is each iteration of this process.
Round 1 was called just "camHolder_PostProcess" above.
Round 2 seems to be very close to the pre process file, and doesnt look like it has any errors.
Round 3 same deal as 2
Round 4 a bunch of error and differences from the preprocess file. It also differs in its errors from Round 1.
adding debug zip file
attaching another run, round 5, which again is post processed differently from all the other files...
@miklschmidt and @Helge Keck
yeah, this looks like a ratos bug. i just post processed it with my external post processor and there is no issue
weird bug, the post processor shouldnt do anything at this position
would you please share the 3mf file from it
Can you try this in PS 2.8.0 instead?
2.9.0 support was added to the supported list because people reported it was working, i'm assuming you have an edge case here
And yes @lingo124 please include a .3mf of the project that causes the post-processor to produce invalid output.
The fact that it's random makes it seem like a filesystem corruption issue, what pi and sd card are you running this on?
I am running it on a 1GB Pi4 with a Sandisk Extreme Pro 128GB Solid State Flash Drive (I assumed short of an actual SSD, a flash drive with a SSD controller was the best choice). That’s a good point about corruption. Would this test make sense to discern if it is a file system issue: Clear gcode on RatOS, upload file, download file, start print to have the file post processed, and then download file again. i repeat this a few times and if the pre processed file is consistent while the post processed file changes, then it would be less likely to be a FS problem?
Attaching 3mf file
Interesting... I just ran the above process and it seems like the gcode file after uploading to RatOS (appended with "preprocess"), is different from the original file (appended with "original") and it does contain a bunch of errors. All the errors are different between the 3 upload download cycles I did. Furthermore, it seems like the pre and post process files for each run are very consistent, where RatOS makes minimal changes to the files, and does not introduce errors. It is confusing to me why the upload process seems to generate so many errors and consistently (each of the pre-process files i retrieved using SFTP all had errors), while the post processed files matched their preprocessed files with no additional errors. If there was a filesystem error, I would expect the upload process to introduce errors (which now it seems like it does), but the post processing should also introduce more errors, as the file is being edited and saved (but it doesnt seem to introduce any more errors).
Not sure about my above thoughts, but in the meantime I'm going to try to copy the USB over to a Sandisk Industrial microSD card and give that a shot and see what happens...
Ive included all the files I used for testing today.
This makes me think that it's the moonraker processing that screws it over.
Yeah this is really strange and subtle..
are you uploading from PS or do you manually upload it through mainsail?
The last test I did (earlier today downloading the preprocess files and comparing them) I uploaded through Mainsail, but usually I upload files through PS. It seems like both methods generate errors during the upload process.
For reference, these are the versions of packages I have right now.
Is there a way/command to trigger the post processing without actually commanding a print to start?
Ssh in and run
ratos postprocess
the path to the gcode file would be something like
~/printer_data/gcodes/mygcodefile.gcode
So, for example ratos postprocess ~/printer_data/gcodes/mygcodefile.gcode ./testoutput.gcodeGot it.
So I copied the boot USB drive directly to a microSD card and booted off the microSD. Same behavior on file upload. Now I’m trying to flash a fresh copy of RatOS onto the microSD to test out a clean install. Currently stuck updating RatOS since updating RatOS first seems to cause the RatOS config to become “invalid”… Will report back after I get the fresh microSD up and running and see what happens with file uploads.
Yeah you need to follow the instructions carefully, doing anything out of order will cause moonraker to mess up the files.
1. The machine will reboot after the wifi setup. 2. Connect your control device (computer, tablet, or smartphone) to the same Wi-Fi network as your V-Core 4. 3. Enter the hostname (e.g., myvc4.local) in your web browser. 4. Navigate to 'Machine' (8) in the left-side menu. 5. Locate the update window and refresh it (9); options may take some time to appear. 6. Update RatOS packages by clicking the Update button (10) to prepare for third-party software changes. Wait for the installation to complete, mainsail will reinitialize when successful. Refresh the webpage (press f5) 7. Update the 'RatOS-Configurator' packages (11). Wait for the installation to complete, mainsail will reinitialize when successful. Refresh the webpage (press f5) 8. Click 'Update All Components' (12) at the bottom of the updater panel. Wait for the installation to complete, mainsail will reinitialize when successful. Refresh the webpage (press f5)
Yup I’ve been following the guide (that’s how I setup the USB drive originally) so I’m pretty certain there are no issues with the original install. It’s so odd that when trying to install it last night, sometimes after a fresh install configurator is already shown as “invalid”, even before doing any updating. I wonder if it’s the computer or what. The original install i created using balena on a windows computer but last night when trying to flash the microSD i was using balena on a mac (seems like balena on mac can’t handle xz files properly so I had to extract the img file and then write it). also tried 2 different cards and they both exhibited this weird behavior. the last time i tried to flash the image before going to sleep, almost all the packages came up as invalid immediately after first boot. it’s weird, i was assuming that balena had validated the flash so i wouldn’t get different behavior each time. ¯\_(ツ)_/¯
waiting on the arrival of a new microsd just to make sure. Also to note, I did check the checksum of the xz file and it was fine.
That normally happens because of network issues (check your moonraker.log). Refresh the update manager again.