Vivedino Troodon Board (non-working w/RRF >=3.1).

o_lampe

@oliof I can't say anything about the FW-issues, but i compared the 2660 PCB with the original Duet2. I noticed, there are far more "vias" on the Duet around the 4 output tracks (A1-B2) and the tracks are much wider. The Duet also has more vias below the chip to transfer heat to the PCB backside.
Could you post a picture of an empty driver-socket? I'm missing a big capacitor on the driver to stabilize VMot.

gloomyandy

@oliof Are you still getting an error saying:
"motor phase A may be disconnected reported by driver(s) 0"
If you are can you run m122 when that error is being reported. I would expect the motor status to report:
"open-load-A"
or something similar. In your original post it looked like it was reporting the error over and over once it happened was that the case or was it reporting it only when you did a move?

droftarts

@oliof is it because it identifies as Duet+DueX5, rather than Duet+DueX2, so it’s not disabling the extra non-existent drivers? How did it identify on old FW versions? There’s definitely a hardware difference between the real boards. See https://duet3d.dozuki.com/Wiki/Duex2_and_Duex5_Features#Section_Using_a_DueX5_with_External_drivers

I’d guess you’d have to look at the Troodon schematic next to the DueX schematic to work out what’s different.

Ian

jay_s_uk

@droftarts it doesn't include the Drivers 2, 4 and 9, which are Z, E1 and E6 so it really is a duet+duex5 rather than a duet+duex2

oliof

@gloomyandy yes and the M122 is from when I got the error. And yes, it does repeat reporting the error.

oliof

@o_lampe .

Yes, the cooling setup is different, but please remember: The hardware is proven to work, it worked fine with RRF until 3.0 and it continues to work well with either older RRF versions or Klipper. The design may not be ideal, but it's solid and functional.

oliof

@droftarts it always identifies as a Duet+DuetX5, and as you can see in my config.g, the missing drivers are disabled so they don't report an error. I have not heard back from Formbot3D but if I am not mistaken there's a weeklong holiday so I picked an unfortunate time to expect a speedy answer.

oliof

@o_lampe @droftarts one of the easiest discernible differences is that SG_TEST is not connected, i.e. stallguard pin is floating. Since people elsewhere were theorizing the floating stallguard may be a problem, I bridged SG_TEST to the neighboring GND pin (which I confirmed to be going on the GND rail with a multimeter, I also checked my solder attempt and it's got continuity from SG_TEST to VNegative).

Unfortunately no change.

oliof

To make it clear @gloomyandy: While I get the phase mismatch error in the console, the driver does not report open load state in M122. That is what you were looking for?

gloomyandy

@oliof I was expecting to see it in the m122 output, but there is a lot of "filtering" going on for this condition (motor, current, step speed, must be reported constantly over time), so it's hard to be sure. I've had a good luck at the changes since V3.0 and I can't see anything obvious that would result in what you are seeing.

oliof

@gloomyandy I've been spelunking in Platform.cpp and the TMC2660 driver code (in vimdiff between 3.0 and 3.1.0), and nothing jumps immediately out at me that would explain this behavior. There are some changes about the setting and resetting of status bits that may be related, but my C++ knowledge is likely not good enough to see the subtlety that likely causes this failure. Best guess is, it's something about the changed driver initialization, maybe even the missing 10 millisecond pause that's still in 3.0 but was dropped in 3.1 ... I may just add that back, recompile and see if it helps.

dc42

@oliof where in the code was this 10ms pause?

oliof

@dc42 it's possible I've been confused by vimdiff's output, I will need to re-check what I saw last night ... When I'm back home later today. Sorry for the confusion; I am still trying to understand what's going on...

oliof

@dc42 microseconds, not milliseconds -- sorry for the mixup. In src/Movement/StepperDrivers/TMC2660.cpp; line 1030 in the 3.0 release. The whole driver bringup has been significantly changed between 3.0 and 3.1. My gut says it's a likely candidate to dig into since the failure happens on first move attempt.

dc42

@oliof I suspect the problem may be caused by the code in the new driver that checks the microstep position and adjusts it to be zero before it enables the driver. This code should be disabled for drivers that have been disabled. I will look at implementing than in the next 3.4beta.

oliof

@dc42 I do have a Duet2Wifi with a blown driver (E0, so driver 3 IIRC). I never upgraded that board to RRF3, and had packed it away to send for repairs. I hadnot gotten around to sending this board out, so I was able to do a comparison with the Troodon board.

In the simple test bench setup with one stepper connected to driver 0 (X), this board does not exhibit the same failure mode as the Troodon board. In fact, it just works without any complaints.

Of course this might be because there actually are traces and resistors on the board for this driver (or the driver is only partially broken instead of completely missing), so the behavior of the overall board could very well be different.

Since I noticed you got the change landed already, I'll see that I get my build environment up and running again for a (hopefully) quick build and feedback cycle.

oliof

@dc42 looks like my build environment was in good enough shape that I could build the latest 3.4-dev checkout -- and I can confirm the issue is resolved. I now get a move out of the motor without errors.

o_lampe

@oliof I tried to find their TMC2660 drivers sold separately, but computer says NO
Would be cool to add them as driver 10+11 to a Duet2. For now we can only use external drivers without SPI on the CONN_LCD pins.

jay_s_uk

@o_lampe won't these do? https://www.digikey.co.uk/en/products/detail/trinamic-motion-control-gmbh/TMC2660-BOB/8037672

o_lampe

@jay_s_uk Theoretically yes, but are they built for 24/7 stress? They aren't exactly cheap either...