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

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

[oliof]

@o_lampe you can buy the drivers directly from them, choose the driver as the purchase option on https://www.formbot3d.com/products/troodon-mother-board-and-touch-screen

[oliof]

@o_lampe please note that these are not stepstick compatible drivers! So they won't fit onto a BTT MOT board. You'll need to spin your own bigfoot compatible board or wire them up directly.