While is printing... do Home X or Y. Without touching anything!
this is really rare. Everything work super but WHILE is printing (maybe 2 or 3 hours after) and NOBODY touch nothing the printer do Home X or Home Y, aleatory.
After do this, continue printing... Maybe 3-4 mm after do again...
Maybe happen several times and always continue printing...
New board Duet Ethernet v1.04c with 3.0firm and DWC2.0.7. With PanelDue7i
I check the hiccups and the 95%times was 0, another times values like 2, 5 or 10. No more.
The consoles of PanelDue not say nothing interesting.
littlehobbyshop last edited by
@FBG Can you share the gcode file that this happened on.
Not is with the same code, you can use as you want, is indifferent.
timothyz last edited by
Are you running a 12V power supply? If so, my guess is that your voltage is dropping too low, causing the duet to trigger a pause, re-home, then restarting your print. This is the only logical explanation.
I use 24V and i think that is fine
Moreover, i don't have resurrection configured
SIam last edited by
if this happen can you post the result of M122 and your config.g
Do you by any chance have motor stall detection enabled (M915 in config.g), with "rehome on stall" selected in the R parameter?
Here are some other possibilities:
- Does your slicer have an option to re-home axes every N layers, so the G28 commands are in the print file?
- We've had instances of noise on the PanelDue wires causing spurious commands to be executed before, although I've never heard of that including homing commands. To guard against this, checksumming for commands received from PanelDue is enabled by default; but it could have been disabled by a M575 command.
deckingman last edited by
@FBG Does it actually run homex or homey, or is it that the print head moves towards X min or Y min? What I mean is, does it move all the way to touch the switch, back off a few mm, then repeat like a true homing macro, or does the print head simply do a random move towards the axis minimum? I've seen the latter case happen when the firmware was at the prototype stage and gcode files were being corrupted during the upload process and CRC error checking was not present. But never with later firmware. Do you have CRC error checking enabled in DWC and do you get any errors when uploading gcode files?
- M575 not is write in the config or GCode program
You are right, not do home.
The real movement is go to Xmin and Ymin, also do Max..
Never i see error CRC
By the way, this morning i change the SDCard to a new card brand Sandisk.
For the moment all seem correct and i run same gcodes than before!
Can be this the problem?