After Firmware update from 3.4.5 to 3.5.2 my printer crashes

[Chrashem]

@Phaedrux
For sure!
I set up the logging. What movements or commands should I do with the logging on?

What do you want to see?

For the crash situation I have the problem, that I have to cut the power supply immediately I recognised, that the printer is out of control. I don't know if the logging will work under these conditions.

[Chrashem]

@Phaedrux @droftarts

At the moment I'm at home and I can run some tests for you with the logging. Can you tell me which movements do you want to see with the additional logging?

How can I share the log? Should I copy the text?

[Phaedrux]

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.

[Chrashem]

@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

[Phaedrux]

@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?

[Phaedrux]

@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?

[Chrashem]

@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.

[chrishamm]

@Phaedrux i'm pretty sure this is an issue in the firmware so probably one for @dc42. Unfortunately, my machine which has independent Z drives isn't operational at this point so I can't attempt to reproduce it at the moment.

[cosmowave]

@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.g

I 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	

[Chrashem]

@cosmowave

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.

[dc42]

@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.

[Chrashem]

@dc42

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.

[dc42]

@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?