After Firmware update from 3.4.5 to 3.5.2 my printer crashes
-
Can you reliably make the printer crash with certain movements? We just want to see if anything comes up in the logging.
Another thing to test would be to setup in standalone mode without the SBC and see if the issue remains.
-
@Phaedrux
Today I run the test and I have the logging of it.2024_08_23_Logging_Error_G32.txt
Just an additional Information:
To be sure that I got no crash but don't have to cut the power supply, I raised the dive height and lowered the feed rate to generate some time to react.Unfortunately the error is a bit different. Normally the bed crashed against the printhead, but with this configuration I didn't get a crash, but I got a strange feedback:
Here are the steps which I did in the test:
- 16:02 - Restart the Machine
- 16:02 - Home all Axis
- 16:05 - G32 to level the Bed --> Successful -->Leadscrew adjustments made: 0.152 0.166 0.166, points used 3, (mean, deviation) before (0.161, 0.006) after (-0.000, 0.000)
See here (answer is late because the movement took some time in reason of the low feed rate):
Aug 23 16:09:52 Duet3 DuetControlServer[7125]: [debug] HTTP: Finished code G30 P2 X275 Y12 Z-99999 S3 ;probe near a leadscrew and calibrate 3 motors => Leadscrew adjustments made: 0.152 0.166 0.166, points used 3, (mean, deviation) before (0.161, 0.006) after (-0.000, 0.000)
- 16:10 simulation of a job
- 16:11 G32 to level the Bed again --> Error happened
Aug 23 16:16:12 Duet3 DuetControlServer[7125]: [debug] HTTP: Finished code G30 P2 X275 Y12 Z-99999 S3 ;probe near a leadscrew and calibrate 3 motors => Error: Some computed corrections exceed configured limit of 5.00mm: -14.332 -14.352 -14.354
-
@Chrashem said in After Firmware update from 3.4.5 to 3.5.2 my printer crashes:
Error: Some computed corrections exceed configured limit of 5.00mm: -14.332 -14.352 -14.354
This error is due to the requested corrections being more than you have allowed in config.g.
Now the question is, is this actually a correct amount of correction? And if not, why?
If you alter the correction limit from 5mm to 15mm, does the correction actually take place? Is it always a similar amount?
-
@Chrashem said in After Firmware update from 3.4.5 to 3.5.2 my printer crashes:
2024_08_23_Logging_Error_G32.txt
@chrishamm Can you take a look through these DCS logs?
-
@Phaedrux said in After Firmware update from 3.4.5 to 3.5.2 my printer crashes:
This error is due to the requested corrections being more than you have allowed in config.g.
Now the question is, is this actually a correct amount of correction? And if not, why?
This is absolutely not the correct amount of correction. I tried to showed this with the first bed levelling before the simulation! I can do hundreds of bed levellings and they are okay. After each step the corrections are getting smaller and the bed is perfectly levelled.
If I do one simulation and I do a G32 the software tells me this high amounts. Yesterday I tried three times the G32 after a simulation and every time I get this high amounts which are higher than the allowed limit. So in general you can think that the bed is not levelled. BUT if I do after this a homing of the axes and try again a levelling, the results are very small (like the ones without the simulation).
If you alter the correction limit from 5mm to 15mm, does the correction actually take place? Is it always a similar amount?
To be honest, I don't like to try it. Because the bed is so near to the printer head, it would crash!
After a simulation it feels like the software have lost internally the height of the bed. Because if I lower the dive height of the probe, I get after the simulation the behaviour that the printer just pushes the bed against the printhead without take notice of the probe and the axis limits. The printer pushes the bed against the bearings of the z axis and their housings are going to break.
So in my opinion there is something wrong after a simulation. And it doesn't matter which part I simulate. I can print these parts without an issue.
-
-
@Chrashem
A help to prevent from damage could be to reduce your motor currents during probing, if your hardware allows it.
I do that on my delta.
I cache the current in a variable before reducing it. After probing, i set the current back like in at was in config.gI use the following code in bed.g before the probing starts:
; cache actual stepper currents, set lower current for probing var Xcurrent = move.axes[0].current ; cache X stepper current var Ycurrent = move.axes[1].current ; cache Y stepper current var Zcurrent = move.axes[2].current ; cache Z stepper current M906 X400 Y400 Z400 ; less motor current for probing ... ... ... M906 X{var.Xcurrent} Y{var.Ycurrent} Z{var.Zcurrent} ; set motorcurrent back to value before probing
-
This is a really good point! Thank you! I will adapt this to my code! And I think I will also adapt this to all of my homing files.
-
@Chrashem it sounds to me that the Z position may not be getting restored correctly after running a simulation. Until I can fix this, a workaround may be to home Z at the start of your bed.g file.
-
thx for your message! You're right, and i do a full homing if do a simulation. Maybe it's helpful for you, but I also figured out, that I can also run into this issue if I abort a print. It's not only restricted to the simulation.
-
@Chrashem I find that very odd. I frequently abort prints on a CoreXY machine and I have never encountered this issue. Neither has anyone else reported it. So I suspect that something is wrong more generally with your Z axis. Some suggestions:
-
Have you tried reverting to the older firmware, to make sure this isn't a hardware or configuration issue that happened to coincide with the firmware update?
-
Are you sure that you haven't inadvertently set the Z max speed or acceleration too high, or the motor current too low?
-