Pre-processing will cause firmware restart
After a hiatus of a couple of months I updated to latest 2.1 & fluid and re-calibrated my printer. All of that is working just fine and the printer worked before without issues as well.
However, when trying to start a printer I get the following error
Error: !! Post-processing failed: Unexpected error
Error: G-code could not be processed
Valid slicer identification was not found.
Tried old version of Orca and Super Slicer - as well as an updated version of both. Even a clean install of the latest prusa slicer is throwing the error.
The shape is just a simple 1 layer 150x30mm block
Did something change in the latest RatOS 2.1 versions that I need to configure or include in my printer.cfg? Couldn't find anything in the file or in the github config documentation but maybe I missed something.
34 Replies
How are you trying to start the print? What have you put in your
Start G-code in the slicers?
https://os.ratrig.com/docs/slicers/I've tried a couple of different Start G-Code and the result is always the same failure state. Print started either as a direct upload from the slicer or a manual export & upload
For PS and SS I've tried the defautl profile, as well as what is on the os.ratrig.com website.
This used to work for SS:
G90
G21
SET_GCODE_VARIABLE MACRO="RatOS" variable="relative_extrusion" VALUE="True"
START_PRINT EXTRUDER_TEMP={first_layer_temperature[0]} EXTRUDER_OTHER_LAYER_TEMP={temperature[0]} BED_TEMP=[first_layer_bed_temperature] CHAMBER_TEMP=[chamber_temperature] TOTAL_LAYER_COUNT={total_layer_count} X0={first_layer_print_min[0]} Y0={first_layer_print_min[1]} X1={first_layer_print_max[0]} Y1={first_layer_print_max[1]}
As did this for Orca:
START_PRINT EXTRUDER_TEMP={first_layer_temperature[0]},{first_layer_temperature[1]} EXTRUDER_OTHER_LAYER_TEMP={nozzle_temperature[0]},{nozzle_temperature[1]} BED_TEMP=[bed_temperature_initial_layer_single] INITIAL_TOOL={initial_tool} TOTAL_LAYER_COUNT={total_layer_count} X0={adaptive_bed_mesh_min[0]} Y0={adaptive_bed_mesh_min[1]} X1={adaptive_bed_mesh_max[0]} Y1={adaptive_bed_mesh_max[1]}
Just tried some old files that printed succesfully in the past and same problem.
can you try with a small gcode file and report back
Smallest I could think of - 30x30x0.2 box created in latest version of super slicer.
Logs attached.
and it didnt worked?
Nope - instantly crashed
It goes into 'pre-processing' and then the crash
please enable debug mode with
ENABLE_DEBUG, then reproduce the error and share the console output
also, please configure your slicer according to this documentation
https://github.com/HelgeKeck/RatOS/blob/documentation_v2.1/site/docs/slicers.md
make sure all the gcode fields are correct and then try againDid a clean install of Prusaslicer, double checked the config from the documentation. Result is still a crash
10:20:28
$ ENABLE_DEBUG
10:20:28
RatOS | DEBUG: Debugging enabled.
10:21:18
Post-processing started
Processing Shape-Box_PLA_QUALITY_0.20mm_Nozzle_0.4_VC3_54s.gcode (0.05 mb)...
10:21:20
// Klipper state: Shutdown
10:21:21
File opened:Shape-Box_PLA_QUALITY_0.20mm_Nozzle_0.4_VC3_54s.gcode Size:0
10:21:21
File selected
10:21:21
// Unhandled exception during run
// Once the underlying issue is corrected, use the
// "FIRMWARE_RESTART" command to reset the firmware, reload the
// config, and restart the host software.
// Printer is shutdown
10:21:21
!! Unhandled exception during run
10:21:21
// Unhandled exception during run
// Once the underlying issue is corrected, use the
// "FIRMWARE_RESTART" command to reset the firmware, reload the
// config, and restart the host software.
// Printer is shutdown
10:21:21
!! Unhandled exception during run
10:21:21
Done printing file
ahh, is the new processore already online @tg73?
please have a look
@miklschmidt
Should only be in dev afaik.
but hsi error message suggests he is on the new code
@Heretic_Infidel are you on the development branch?
Could be - This install is still from the release of RC1. Software update is of the opinion that I am
ratos-configurator
v0.0.0-349-gfdaac5e6-inferred
Repo not on offical remote/branch, expected: origin/v2.1.x-deployment, detected: origin/dev-deployment
yes then you are using our internal development branch,we are working on the post processor atm with a big update
try to update everthing and try again
Ah - thought that might have been the case. Let me try and update. Otherwise I can always roll back to the official branch
The specific issue you are seeing was fixed yesterday. We break things in the dev branch, do not use for production machines. If you go back to the regular branch you should delete all gcode files from the printer to avoid potential problems.
Normally only devs and beta testers use the dev branch.
actually there are a handfull of users in the wild that are on dev branches
as you can see
It's unfortunate when they don't realise, eg if they switched months ago for some temporary reason, and didn't switch back.
i know a slution, we can add a warning message to the ratrig welcome message
It's a hobby machine and was onthe dev for the 2.1 before the summer. THen moved house and never had any problems before. But it works now.
When I have some time i\ll do the rollback to the normal
Thank you for the help either way. A warning message might indeed be good reminder for those who don't print daily 😄
You cannot be on the development branch without explicitly checking it out yourself (it's quite a few steps, not something you do automatically/accidentally), there is no official image with development branches already set. Did you do this yourself, and if so why? If not, who did?
It's a hobby machine and was onthe dev for the 2.1 before the summer.Ah. The problem is the development branch moved to a monorepo structure, so you can't roll back without a significant song and dance, since the configuration no longer exists on your pi as a separate repository. Reflashing is most likely the easiest way forward.
Tried looking up what I did but couldn't find it anymore in the ratos-development pinned posts. At the time what I did was follow the guide to move to the branch that allowed for th use of 2.1 - RC1 and have been following that branch since.
RC1 never required running the dev branch so i assume it was even earlier than that.
All good though, explains how you got there 👍
That was my thinking as well - just start from a blank slate. Have had to rebuild my printer anyway so already happy it is up and running and calibrated. Reflashing and copy-pasting my config back and re-doing some calibration work is easy enough
Instructions for moving to dev always come with big fat warnings that stuff will break and that you should never run it permanently
are there any major problems or backwards compatibility issues that I should keep in mind?
we could need another eye on the new branch though
No should be good. The dev branch are mostly infrastructure things and the new post processor.
yeah we need more testers
I'm fine sticking to the current branch - nothing time critical if something breaks
happy to test
then by all means, stick with it at least until we've merged the new post processor 🙂
Cool - will do that. Saves me some time ˆˆ
Thanks for helping out! 🙂
no worries - happy to. Something to give back to the amazing stuff you all develop.