@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

I found the single 5V pwm output limiting, plus to get the most precise control, an analog 5v fed to the CPAP blower driver board is most accurate. Tried a few ways to do that and settled on this board https://www.amazon.com/dp/B079BH3SHX?psc=1&ref=ppx_yo2ov_dt_b_product_details -- it's powered by 24v, will take the pwm output of a regular fan output and create a clean 0-5v analog output. If you run it at 100-200hz you can get the low end to be around .5v, and that's as slow as the CPAP blower can go. I can go the full spectrum and have perfect output control. Not sure of another source for these boards, but I will use them for duet and for klipper configs since they're simple and the best part is the fan control is super accurate.

@T3P3Tony i did a few more tests with the bench PSU, i current limited the fan, and it just drops RPM, doesn't do anything else. Even on powerup it ramps up with < 300 mA and maxes out at 600. I suspect with the amount of airflow it produces i will never run it at full throttle.

@T3P3Tony so how would this manifest with the tool board -- can I use it with the toolboard or no? I've tested it on the bench and it never peaks above even 650ma even at startup.

Question regarding 12v reg on the Tool Board.
I have a fan which is rated at 12V 1A, I was planning to run it of an external DC-DC converter, but when I ran it on a bench supply it pulls .6a at max RPM. So it looks like the rating is wrong. That's the part cooling fan, the hotend fan is < .1a -- so if I'm trusting the bench PSU -- I'm under 800ma. Is this OK to run directly of the toolboard? What should I look for if it starts pulling more current than toolboard likes?

@dc42 hopefully you know what changes made it work now.

@dc42 I installed 3.5 beta 2. The problem appears to have been fixed.

@dc42 I did the full test during lunch. Can confirm now I am on the 2.4 bootloader.
Here is the gcode

G28
G32
T0
G1 X300 Y300 F20000
T3
G1 X300 Y300 F20000
G28 A
G1 X300 Y300 F20000

Last line is where A doesn't go to 300 it makes a little squeak and says it went there. Note A in all cases in DWC shows home position -34.7, even when it's being operated by T3.
3.4.5 didn't work for me, I went backwards in order 3.4.4, 3.4.2, 3.4.0 -- power cycling after each complete flash. Only 3.4.0 worked and the last gcode line moved the toolhead to X300.
I tried upgrading from 3.4.0 to 3.4.2 -- and same result, last line didn't work. I reverted to 3.4.0. And it works again.

here is homea.g in case it's remotely helpful
G91
G1 A-700 F6000 H1
G1 A3 F500 H2
G1 A-10 F300 H1
G1 A0.2 F3000 H2
G90

here are tool definitions
M563 P0 D0 H1 F0 ; Define tool 0 to use extruder drive 0 and heater 1
M563 P1 D1 H2 X4 F2
M563 P2 D2 H3 Y3 X5 F4
M563 P3 D3 H4 Y3 X6 F6

note this is only a problem with A axis, UVW which represent my other mapped axis do not have this issue -- so in the gcode above I can replace T3 with T1 or T2 and replace A with U V or W and the last line will work fine.

@dc42 yes bootloader is 2.3 -- I expected that it would get updated during the various firmware updates I preformed, didn't even occur to check. Will update now and try latest firmware

@T3P3Tony sorry it took me a while to test, but the problem persists with the updated 3.4.5
Command is switch to tool 4 --
T3
issue G1
G1 X300 Y300 -- toolhead goes to the correct location
G28 A -- home the assigned X
toolhead homes -- this is not the issue
G1 X300 Y300 -- toolhead doesn't come back to X300 -- this is the problem

PS I downgraded to 3.4.4 -- Same issue.
I kept going back -- I ended up going back to 3.4.0 until the problem went away

@dc42 I finally got around to re-testing this. I downgraded to 3.4.2 (that was the major release I found quickly with all the web archives)
The problem went away, I was re-calibrating the machine and switching to 9mm belts and to mechanical switches to replace optical switches (my own experiment trying to find repeatable calibration, unrelated to the issue), so took a while to test again. The calibration process is adjusting UVWA axis home positions to match XY coordinate space. Now all is put back together. Am on 3.4.2 -- all works fine. I did a couple of rounds of homing A and then re-issuing G1 command with X Y coordinate for the toolhead A is mapped to, and it works properly. My config is duet3 6HC, 2 EXP3HC, and 4 toolboards. A axis is on the 1st expansion board. W axis is on the 2nd expansion board, 3.4.5 had no issue with UVW axis, but had a problem with A axis. 3.4.2 works fine now.