Duet Stops mid print
-
This is happening in 2.04 and 2.05r2
-
This duet2 pause or lockup issue does not happen on all prints, and prints it does occur, it doesnt happen on the same spot during the print (if I reprint the same gcode file over a few times). But might occur on the same spot different layer of I can get it started again using the pause/recovery feature of the printer. Yes pause data gets recorded but doesn't move to x0y0 as it does when I normally press that button...
-
@BlueDust said in Duet Stops mid print:
201901MosaicKeychain2 test.maf.gcode
Are you using a pallete2?
-
@Phaedrux
Sorry for the delay in my response. I am getting frustrated with this issue and then my PC's NIC decided to die. Eh, it was 7 years old. Built a new PC over the weekend, and I should be able to get back to playing with this, this week.
I have a Palette2 but use it in accessory mode and haven't test connected mode using an RPi. I prefer accessory mode as I lose the Duet2 features/control in connected mode. But I am planning on testing connected mode if this isn't resolved soon.
This problem happens when using the Palette2 gcode or not, and not on every print. I have been printing small D&D characters (S3D to Duet2, no Palette2) and some print OK and others do not. The Gcode file I shared was also sliced in S3d and then updated for color in Chroma. I shared it was because it was the most recent file with the problem. I can share another D&D model with the issue too... But only tried that one once so far.The issue "appears" that if a gcode file works, it just works, but if it's bad, it's bad most (haven't tested enough) if not everytime I try to print that same gcode. Early on with this problem, I created the same Gcode file 3 times before the object would print.
The odd part is, that if the problem occurs, it appears to stop on the same spot each time (pause reset printer, resume) just a different (appears) random layer. But if I print it again using the same Gcode file, that spot moves to a different spot. It's weird and I am actually trying to print around this problem so I haven't tested this more then a few times for consistency on the same Gcode (the one I shared). -
@Phaedrux
I just re read what I wrote on my last message. I wrote it on my phone and need to stop doing that... It would appear I need English lessons from my 8 year old daughter.Let me know if you have any other ideas or things I can look at. I tried to upload another gcode file that also had this issue but it was too big, even after trying to ZIP it.
Thanks for your help.
-
@BlueDust said in Duet Stops mid print:
Hiccups: 1623052
I just noticed that you have an insanely high number of hiccups being reported in that last M122.
Hiccups: 14280857
Even higher before that.
Can you post your config.g again? Are you using microstepping values higher than x16?
Can you use dropbox or something to share the gcode file?
-
Looking at your config from one of your older posts https://forum.duet3d.com/topic/12941/auto-bed-leveling-went-bad?_=1576682639924
I see that you're indeed using x256 microsteps for all axis and extruder. This will greatly limit your maximum speed before the step pulse generator is overwhelmed and hiccups occur.
For best results it's recommended to use x16 microstepping with interpolation to x256 enabled. This reduces the load on the CPU and still allows the drivers to use x256 microstepping for the motors.
-
@Phaedrux
I have had this configuration since I first setup the Duet2 last year.
M350 X256 Y256 Z256 I0 ; Configure microstepping without interpolation
M350 E16 I1 ; Configure microstepping with interpolationDid something change in the 2.04+ ( I haven't tried older versions when testing this issue) to make this now cause an issue and the problem mentioned. Or are you saying what I have is not proper config (and causing errors... er Hiccups) and should be fixed. Possibly contributing to this problem.
As always. Thanks!
-
@BlueDust said in Duet Stops mid print:
should be fixed. Possibly contributing to this problem.
Yes. It's not recommended to use x256 microstepping for all axis. It will likely result in high hiccup counts which may result in unexpected behaviour. I'm not sure if something changed in recent firmwares to make the lockup issue more prevalent, or if it has something to do with the Pallette 2 and the way it uses ping/pong pulses of the extruder that could be causing some issues.
Regardless, you'll likely see better behaviour by using x16 microstepping with x256 interpolation.
-
OK...
Trying to setup x16 w/Interpolation...Should x16 with I be enabled for all axis? Are you saying that Z can be x256, but the rest should be X16 w/ i?
I just setup x16 with Interpolation for all axis and am just asking to confirm best practice on what should or shouldn't be x16i or x256.
Thanks!
-
@BlueDust Iād go with all on x16i.
Ian
-
I am now getting a higher pitch squeal on the Z axis when moving at speed. Other axis are also slightly louder, but haven't printed anything yet... Just getting setup to do so...
Is there a way to stop this sound other than slowing it down to a crawl?hmmm...
I don't think I enabled Silent Step or anything. Its been awhile since I setup the initial config to remember all the details... Something to look into...Fun, that 3 letter word with "u" in the middle.
-
M350 X16 Y16 Z16 E16 I1And adjust the M92 steps per mm accordingly.
Just as an aside to make testing alternative microstepping easier, if you set the microstepping to x16 first and then set the steps per mm accordingly for x16, you can then change the microstepping on a later line and the firmware will automatically calculate the steps per mm for you.
example:
M350 X16 Y16 Z16 E16 I1 M92 X80 Y80 Z400 E410 M350 E256That would leave the XYZ using x16i and set the extruder as x256 and you wouldn't need to alter the M92 at all.
This should make it easier to experiment.
-
@BlueDust said in Duet Stops mid print:
getting a higher pitch squeal on the Z axis when moving at speed
What are the commands you are using? Did you remember to recalculate your steps per mm?
-
That step trick is pretty NEAT! Good Show!
That would leave the XYZ using x16i and set the extruder as x256 and you wouldn't need to alter the M92 at all.
This should make it easier to experiment.
Old Settings
M350 X256 Y256 Z256 I0
M350 E16 I1
M92 X2560 Y2560 Z12800 E819.8589Current Settings
M350 X16 Y16 Z16 I1
M350 E16 I1 ; I know I can turn this into one M350 line now.... just haven't yet.
M92 X160 Y160 Z800 E819.8589 -
@BlueDust said in Duet Stops mid print:
when moving at speed
Does it seem to be moving faster than before? With such a high hiccup count it likely wasn't ever actually reaching the full requested speed. You may need to revise your speed assumptions?
Is the squeal coming from the motors?
-
Yes, it seems quicker now. Also, stall guard/sensorless homing seems to be working much better, but have only homed it 3 times so far since the changes....
I think it is is coming from the motors, but need to let the printer run a few minutes to confirm. About to start a small D&D character as a test print I have printed a few times last week (that worked each time I attempted it). Its small so the printer will not get up to any real speeds but should be an easy baseline as it was a recent print.
Thanks!
-
Blue is from last week before x16i and Silver is after. Same code. Very close to the same time too. But as it's small, not able to get up to speed.
Just to make sure it's clear. The issue with my printer stopping was first noticed on a non Palette2 print. I tried many times only using S3d when printing on the Duet2 and having this problem. I shared the Palette2 gcode file as it occured on the same file many times/attempts.
Trying to print that same Palette2 gcode file I shared, right now and it has already gotten past the first time/layer the Duet2 would stop. If it prints another 15 layers without issue, I expect it to finish properly.
Hiccups currently say 0
Thanks! -
-
Glad it's sorted.
