Anyone still has this issue? Was there a resolution? I might have something similar but I'm still testing.

How about you @jatmn?

@t3p3tony I noticed the D's as well and the fact that that parameter is not documented on the wiki. The reason I left it in there is because I copied/modified a g-code script (created by cura) I got from OP. I believe they are silently ignored by the Duet.

After some more testing we can confirm that just tool changes work. MoveTC10_test_2.gcode contains basically only toolchanges and that was reported working without issue.

So I figured somewhere between script 2 and script 1 lies an issue in the g-code commands.

My next step was to slowly remove more and more gcode starting from script 1 and see at what point it started working.
MoveTC10_test_3.gcode -> not working
MoveTC10_test_4.gcode -> not working
MoveTC10_test_5.gcode -> not working
MoveTC10_test_6.gcode -> reported not working but slower. Only after 1,5 runs of the script did the offset become to large for a tool change to fail. (normally failure is reported after ~8 changes)

EDIT: At this point I don't really know how to advice/test anyfurter. Since we can almost certainly rule out mechanical issues, since script 2 works without issue. But anything more that just tool changes does give issue ¯_(ツ)_/¯

Here are the free/pre scripts for T0, they are identical for T1

; tfree0.g ; called when tool 0 is freed ;Drop the bed G91 G1 Z4 F1000 G90 ;Purge nozzle ;M98 P"purge.g" ;Move In G53 G1 X282 Y10 F10000 ;Magnet 100 prozent M106 P10 S1 M106 P11 S1 ;brush cooler M106 P0 S1 ;touch G53 G1 X282.1 Y-86.4 ;Open Coupler M98 P"/macros/Coupler - Unlock" ;fan off M106 P2 S1 ;Move Out G53 G1 X282 Y10 F7000 ;magnet 50 prozent M106 P10 S0.5 M106 P11 S0.5 ; tpre0.g ; called before tool 0 is selected ;Unlock Coupler M98 P"/macros/Coupler - Unlock" ;brush cooler M106 P0 S0 ;Move in G1 X282.1 Y10 F10000 ;Collect G1 X282.1 Y-86.7 F4000 ;Close Coupler M98 P"/macros/Coupler - Lock" ;Magnet 0 prozent M106 P10 S0 M106 P11 S0 ;WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! ;if you are using non-standard length hotends ensure the bed is lowered enough BEFORE undocking the tool! G91 G1 Z0 F400 G90 ;Move Out G1 X282.1 Y-35 F7000

ps I have no idea why the formum gives them different styling.

@phaedrux You were right, it finished - took 5110 seconds 😄

@juliann please can you post the M122 once the issue occurs. I see driver 2 is one of the Z axis motors so its unlikely to be moving wiring causing the issue but can you check that you can't recreate the issue by moving the wiring around. Also something to check would be to switch the motors in driver 1 and driver 2 at the Duet end, update your config to match, and see if the issue moves with the motor or stays with the driver.

@rushmere3d
Thanks for the info... I didn't want to mount these into the printer if they had issues and needed replacing.

@hampusåström said in duet 3 mini 5+ short to ground reported by driver 1:

I bought the Duet3mini5+ from E3D Online 1 juni 2021

Thanks for the updated M122 showing the short to ground error after trying to initiate movement.

Please send an email to warranty@duet3d.com and CC your reseller. Include a link to this forum thread and the details of your original purchase. You'll receive a reply with a form to fill out.

ok thanks a lot.
Richard

@aviationguy ok thanks please email warranty@duet3d.com

@rjenkinsgb I believe this is because you opened the post and then the OP deleted it.

@pcr

Thanks! I actually got this working, and its been great since I posted. But will take a look at your solution 🙂

@to-mac There's a monster thread (280 posts) that lead to tracking this bug down. Link to @dc42's explanation: https://forum.duet3d.com/post/226954

Ian

@t3p3tony thank you. I bought a replacement and nothing else was damaged.

@x30n see https://duet3d.dozuki.com/Wiki/Input_shaping which is linked at the end of the accelerometer wiki page.

Ian

@fcwilt said in Trigger file not working as expected.:

You sure?

Not 100% about the S0, but sure that it works now.
I guess that your "G4 250" makes the de bouncing here. And the behavior is consistent.
The 2nd press of the switch will not do anything when I press the switch fast enough. (Below 250ms)
With the finally final settings is that gone:

if fans[5].actualValue == 1 M106 P5 S0 G4 P25 ; Wait 25ms else M106 P5 S255 G4 P25 ; Wait 25ms G4 P10 ; Wait 10ms

It is not easy to press the button in 35ms after the first press.

I guess that something in the live configuration was mixed up and and have forgotten to reboot to verify the config.

Cheers, Chriss

@phaedrux I solved it by moving the Duet away from the power supply. It was an EMI problem, I think ....

I've tried to connect a NPN sensor (LJ12A3-4-Z/BX), with the signal line on Z_PROBE_IN (and using an external power supply) the behavior is the same:

My code:

; Z-Probe M558 P5 I1 H2 T7000 R0.3 F360 ; digital mode, NO/NC, delay, speed, not used as axis endstop G31 X0 Y0 Z-0.45 P25 ; X Y Z offsets. P=debounce interval (The debounce interval in ms smoothes the signal) M557 X15:375 Y20:320 S30 ; define mesh grid

and when I send G30 command the probe works well (the led is correctly activated when a metallic surface is near the sensor) but the bed doesn't stop.

I'm going crazy with these configurations

But by completely changing the type of sensor, it makes me think that the problem is on the board.

Edit:
my last test was to connect the sensor directly to the scehda, to avoid interference on the cables, but nothing, it doesn't work. The stop sign is completely ignored.

@jay_s_uk you where right...my bad

Thanks for testing and verifying that it works correctly in 3.4b6

@o_lampe
Great😂