@dc42 so we're back the i2c mess. I looked through some other posts regarding i2c -- and I saw some related to not running wires next to or along the ribbon connecting the 2 boards...agh...that's the change that I did make when I added extra cable chains, I changed some wiring paths inside the enclosure. God help me, i2c with duet+duex5 is so glitchy. I re-routed cables around the ribbon, best I could, it's kinda tricky now that the case isn't really designed to do that, but -- OK, I found ways. I just started a print -- same one that failed 2 times yesterday before somehow magically working to completion overnight. Well I am running it now, and all loop times are low -- 3-4ms -- it's early in the print, but that looks promising. So it's not just the heavy grounding wire, but the ribbon needs to be clear of anything -- that might appear to be the issue here -- not defective hardware, or cold solder or firmware -- but cross talk on that ribbon. I'm using some insulated ribbons for my PC -- PCIEX extension ribbons -- they're expensive -- about $30 per, but they have a lot of protection against this kind of cross talk, shielding and such, is that something that is worth considering -- I am going to design a new case to split the duet and duex5 apart from each other the way it's now -- they're one on top of each other (as I believe it's intended) but that leads to some odd wiring runs that make it very difficult to avoid the ribbon.
I will do a triple head print later tonight -- see if that works without a reboot -- so far too far into this duplication print with very low loop times to consider a possible failure.

@dc42 my machine has 2 gantries with 2 independent heads on each. So as I called before a quad. 2 of the tools can be fully independent of each other, z is shared. If there is a way to synch z moves, this would be a cool project.

you adjust your min and max, you have them incorrect for the bed geometry -- keep adjusting them until your center is actually center. G10 is for doing a nozzle offset, which only makes sense for a 2+ extruder machine

I noticed toolchange behavior changed at some point, and am not sure why. Now after postX.g runs z is restored automatically. I don't want it to do that, it doesn't make sense for an IDEX (or more -- I have 4 independent tools) to do that. I lower the bed 0.6mm when I park a tool, and I want it to stay lowered when the new tool comes back to xy position, I have my slicer set to move xy to correct position then adjust z, so I don't want duet to restore Z -- I see this code -- my only option is to comment it out.

		// Restore the original Z axis user position, so that different tool Z offsets work even if the first move after the tool change doesn't have a Z coordinate
		// Only do this if we are running as an FDM printer, because it's not appropriate for CNC machines.
		if (machineType == MachineType::fff)
		{
			currentUserPosition[Z_AXIS] = toolChangeRestorePoint.moveCoords[Z_AXIS];
		}

@dc42 genuine Molex shells and pins have worked and I have not had a single blown connector since switching to them, and have done a lot of calibration routines and started doing test prints again. I also have switched a couple of other steppers to use molex shells -- next time I have to service the controller I'll switch them all. Shame that the stock ones have this issue.

@bberger i think I found the issue. Part mechanical, part software. One of the upgrades I did was move the extruder really close to the hotend -- so the bowden tube is now maybe 25 mm tall, so my previous .02 pressure advance was basically messing up and not extruding where it should be. I tried .01 -- seems better, at least it's not - not extruding, where it should be. The other bit was my extruder sherpa mini which I rebuilt, started had a problem in the MJF glass nylon parts -- replaced with printed ABS body, and like night and day, not perfect, not yet -- I think the stepper got a bit damaged in the process, so needs to be swapped to, and I'll swap all the internal bmg gears to be safe, i think the nylon gear got a bit worn out, but looks like it there was an issue of binding maybe in repeated retractions, and the gears would slip, so the big nylon gear needs to go -- seems the mjf body is not stiff enough or some other property. Pretty sure after I replace all the extruder parts, it will be printing perfectly.

There is nothing I can do in the macros, as based on the code the z position is stored before the macro is executed and z is restored after the other macro is executed...since I have my other tweaks to the firmware that I make to ad additional steppers, I build my own firmware, so I commented this code out. E3d tool changer is not the only multi tool configuration, but even that, s3d issues a specific instruction after the too change to set z, nothing tricky about that, only tricky part is to move it to target XY prior to moving it to z, the key in tool change operations is to restore z AFTER xy is moved to where the next printing operation will happen. I am not sure how firmware can handle it, but my idea was to have gcode which saves z and gcode which restores it, so it can be added in the slicer or macros.

@bot yes. dc42 helped me add 2 more. It's not in the official firmware because is 2 extra ops which would normally not be used by anyone else with a duet 2. It has worked for the last 3+ years perfectly fine. There is a way to reuse the pt100 pins for on duet and duex5. Same way that the LCD pins are being reused for 2 extra steppers.

@dc42 I installed a 14 gauge ground wire -- while at it also did the VIN wire. Both are 1/2 the length they were before, couldn't get shorter than this now. I left the 16 gauge(it was 16 not 18 before) going to the PSU, it's coupled in a ferrule together with a very short 14 gauge jumper to duex5. The printer itself with everything on never pulls more than 200w, since my I'm using an AC bed, 16 gauge wire has not been an issue for 24v DC power.

Now the main question is, how do I test the i2c bus for reliability. Under normal conditions it takes a long time for me to start seeing timeouts, is there a test routine, something that would send a bunch of data on i2c which you would expect to produce some errors if the wiring was at issue (I don't mind running some custom firmware to bang on the i2c bus).

Thanks again.

@3dmntbighker thanks for reprap.htm idea, that worked on my pixel

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

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

@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 yes M569 P5 R1 or in my case M569 P0.5 R1 shows no response -- I had the same issue reproduced on driver 3 also, I tried M569 P3 R1 and M569 P0.3 R1 -- no response. Tried on rc1 and rc3, no response.

@dc42 I had run 100s of hours on rc1. I had zero issues, i.e only thing i changed was add szp and that is connected to a toolboard, and basically proceeded to print another set of long prints and the issues started. Also issues started gradually. First it could go 15 hrs before there was a problem, then 5, then 3, then 1. Rc3 was updated just yesterday. Also when the problem occurs, it says it's 2 amps, but I can move the carriage by hand and the stepper skips, if I power cycle, it reports 2 amps again, and now the carriage would have belts slip before the stepper skips. Also the current problem on the main board only and expansion boards go in an out of idle and maintain current. I.e 2 amps is 2 amps. I reproduced it, i have 1 carriage on main board, one on expansion, both say 2 amps, 1 i can move by hand, one i cant. Hence why the main board seemed sus. I guess if the problem re-occurs with the 1.02 version of hardware (i am switching all to 48v capable) then we can hunt for idle or current issue as it connect to firmware. I have a big project coming up, we'll see. Board is of warranty, seems something not isolated to 1 driver is malfunctioning.

PS. If for whatever reason you want to investigate the main board, I won't be re-selling it, so it would go to e-waste, so if you want to cover shipping to UK, you can have it. All my expansion boards are perfectly functional, so I will try to sell them - since I'm switching to 1.02 versions to use 40-48v everywhere.

@dc42 idle is 50% hasn't changed in 7 years I've had this printer. When the issue occurs. Restart cant even fix the current. Manually sending m906 isn't reflected in actual current. It seemed like now 2 drivers are pulling all current down. I was checking during the print yesterday and left over current was holding correctly. I ran 100s of hours with this config and Firmware. Only recent change was addition of szp. Nothing changed in drive config (until I had to stop using 2 of the drivers on the main board) Firmware reboot + reinstall would expect to restore any current settings, all the timeouts don't inspire confidence. Problems are only on the main board all expansions and toolboards are fine. Timeouts and current issues are main board only. Certainly looks like it's dying one driver at a time.

Lots of timeouts.
Driver 0: standstill, SG min 0, mspos 216, reads 51266, writes 3696 timeouts 364
Driver 1: standstill, SG min 0, mspos 72, reads 51266, writes 3696 timeouts 364
Driver 2: ok, SG min 0, mspos 600, reads 51266, writes 3696 timeouts 364
Driver 3: standstill, SG min n/a, mspos 8, reads 51277, writes 3685 timeouts 364
Driver 4: standstill, SG min 0, mspos 936, reads 51266, writes 3696 timeouts 364
Driver 5: standstill, SG min n/a, mspos 8, reads 51277, writes 3685 timeouts 364
Phase step loop runtime (us): min=0, max=192, frequency (Hz): min=492, max=46875

And this is when the issue isn't happening
Updated the firmware to latest rc3, didn't help.

Reproduced the problem on 2 drivers now and other drivers show reduced current when the problem occurs. The drivers which are faulty drop current down 1 amp -- and the steppers I'm using need more than that to move.

Ordered a new board, clearly this one is not long for this world. Gonna get this print done, and will replace it over the weekend. Considering moving to SBC mode as well during the swap.
Will also be switching to 40-48v (need to do the math which is best for my steppers)

@dc42 I figured it out -- the current sent to the stepper falls DRASTICALLY. This is reproducible even on drivers which are acting normally. I am running ldo nema 17s on X carriage steppers. I noticed all of a sudden one of the carriages can't home. It's trying, but it feels like it's basically running with a fraction of the current -- same behavior if I were to set the current to 0.5 or less. I tried M569 commands nothing is printed. I notice driver 2 is working fine, but when given 2 amps, the carriage is rather easy to move. So I gave it 2.5 these LDOs max is 2.8, I've run them at 2.5 on my voron. Even at 2.5 the stepper can be moved by hand with a bit more force. I then powercycled the machine, and 2.5 is now stepper is rock solid. This feels like the board driver current reg is failing? or Something of that ilk.

@dc42 Same thing happened on another driver. So Looks like the board is failing
M569 P0.3 R1 produces nothing

5/22/2025, 2:11:42 PM M569 P0.3
Drive 3 runs forwards, active high 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 296

Power cycled
M569 P0.0
Drive 0 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 200

Current was specified as 2000 in both cases -- something is messing up the current