Dead driver or dying board?

dc42

@kazolar ~~why are you using the R1 parameter with M569? That parameter is for use with external drivers, and should not produce a response.~~

OK, my bad, I made a mistake in my post. The command to use is M569.2 not M569.

kazolar

@dc42 ok, I plugged the 2nd carriage into driver 3 -- it's set for 2 amps, but I can move it by hand easily
This is what I have in config
M906 Y1600:1600 U1600:1600 X2000 V2000 W2000 A2000 Z2000:2000:2000:2000 E750:750:750:750 I50 ; set motor currents (mA) and motor idle factor in per cent
5/23/2025, 1:18:38 PM M569 P0.3

Drive 3 runs forwards, active low enable, timing fast, mode spreadCycle, ccr 0x10024, toff 4, tblank 2, thigh 200 (375.0 mm/sec), gs=39, iRun=31, iHold=21, current=990.234, hstart/hend/hdec 2/0/0, pos 232
It didn't apply -- it was ignored. When I had V mapped to driver 0, it was reporting 2 amps.

5/23/2025, 1:19:19 PM M906 V2000
5/23/2025, 1:19:26 PM M906 P0.3
Drive 3 runs forwards, active low enable, timing fast, mode spreadCycle, ccr 0x10024, toff 4, tblank 2, thigh 200 (375.0 mm/sec), gs=79, iRun=31, iHold=21, current=2005.859, hstart/hend/hdec 2/0/0, pos 232

5/23/2025, 2:06:08 PM M569.2 P0.3 R1
Register 0x01 value 0x00000005

M569.2 P0.3 R1 V7

M569.2 P0.3 R1
Register 0x01 value 0x00000000

I'll try to reproduce it, but it requires a print of some sort, I'll try doing a number of test cycles with V axis mapped to driver 3

dc42

@kazolar thanks. This really doesn't sound like an issue with the stepper driver chip to me, which is why I'd prefer to identify the cause and rule out (or otherwise) a firmware issue.

dc42

@kazolar motors are not powered initially when you power up the system. if you enable the Y driver using M17 Y does the motor become hard to turn?

jay_s_uk

@kazolar said in Dead driver or dying board?:

M906 Y1600:1600 U1600:1600 X2000 V2000 W2000 A2000 Z2000:2000:2000:2000 E750:750:750:750 I50 ; set motor currents (mA) and motor idle factor in per cent

This line is wrong. You can't set a drive current per motor on an axis, only on extruders.

This would be the correct line to use

M906 Y1600 U1600 X2000 V2000 W2000 A2000 Z2000 E750:750:750:750 I50 ; set motor currents (mA) and motor idle factor in per cent

dc42

@kazolar it's as @jay_s_uk says; however the extra values you provided in the M906 command should be ignored and the first value provided should be used for all motors on that axis.

kazolar

@dc42 ok, all being the same -- Z wasn't ever the problem, and extra prams are ignored -- the issue was easier reproduce on my secondary X carriage (V axis) in this case there is no risk of damage to the machine -- carriage just doesn't home properly -- but as per usual it doesn't want to reproduce now. I'll keep trying today -- but gonna run out of time. New boards are coming tomorrow, so if the problem re-appears, I'll update the post.

kazolar

@dc42 just wondering. Is it possible that M906 implementation has changed and the impact is only on the main board, not the expansion boards, so my extra params are screwing up current assignments? Hence setting current on the expansion boards is working fine, but main board -- it's not, or at least not correctly (timeouts in triple digits on the main board are still unexplained though)

dc42

@kazolar I've just checked, and in standalone mode additional M906 parameters are still ignored.

Are you certain that power to the Duet is stable? It's not unknown for PSUs to become intermittent so that the output voltage drops momentarily. It's also possible for the VIN screw terminals or the crimp connections to the fork terminals to become loose. If the VIN to the Duet drops below about 10.5V then the stepper driver chips lose their programming and their ability to communicate (which would explain the large number of timeouts). RRF attempts to re-program them to the correct parameters when power is back to normal, but it's possible that this isn't 100% reliable. The M122 report for the main board includes the minimum VIN voltage seen since the last time that M122 was run, so I suggest you check this if the issue happens again.

kazolar

@dc42 my voltage is 24.5 -- doesn't vary, my power runs are short and using 16awg wire, the PSU I have been using is rock solid rated at 600w, using no more than 200w, so that is not an issue.
A little update, I've installed the new board in SBC mode and upon migrating config, some entries which were fine in standalone (screen console and dwc never had them as problems) showed up as errors now
M350 -- I had defined Y16:16 U16:16 -- it didn't like that -- I suspect that has to do with M906 definition prior -- it appears that version 3.6 is not as forgiving for these type of entries -- though why is it an error in SBC mode and seemingly ok in standalone.
Also one of my homing routines had a line like this
G1 V 700 F6000 H1 --
on standalone that was OK, in fact it ran and homed the axis perfectly fine -- in SBC mode it didn't like the space between V and 700.
I'm now leaning away from a dead/dying driver (since 2 drivers randomly dying and after m906 change at least one of them seemed to be fine, and more toward some randomness to how config is read and accepted -- SBC mode with 1.02 main board my not so perfect config was forced to be fixed, standalone -- screen console never had any errors about these entries.