6XD external driver error signal handling

curieos

@Maestro It says it can sink or source 5-24V, this means it doesn't supply the 5-24V? Tbh, I'm not much of an EE, so I assumed this meant it would work either way.

Maestro

@curieos That just means it doesn't care where it's switching in relation to voltage, it doesn't mean it sources its own voltage. Think of the alarm pins as two sides of a switch/relay that's either open or closed; that's all it's doing.

curieos

@Maestro Ah, should I have the jumper set to pull up then? And in the opposite config, the jumper should be pulled down?

Maestro

@curieos Yes, with your existing wiring you should be pull-up. My example above would be pull-down.

curieos

@Maestro Well thanks, I got that changed and I think it's working. One issue I'm noticing is it's complaining about the unused driver headers erroring out on boot. Any chance you know how to get RRF to ignore this?

Maestro

@curieos Well, now hold on a minute... Before you go trying to ignore faults, is the alarm circuit on your drivers normally open or normally closed?

curieos

@Maestro I'm not sure about that one, the Leadshine sheet doesn't seem to say, at least not in a form I can locate and parse. The guide we have from A3DP just says:

If you connect the ALM terminals back to the corresponding pins on the 6XD, you can use
RRF’s event system to respond to error events from the drives. See the Event docs to get
started.

The error I see pop up is just for the final unused driver (2.5, we have a second 6XD, CAN address 2). There's no message in the log to say which other drives have errors.

Maestro

@curieos I ask because if they're normally open (which is what I've been assuming) I don't see any reason for an unused driver header to throw an error fault while the others don't; in the absence of a fault, error pins would all be at pull-up/pull-down voltage regardless of whether it's connected to an external driver or not. If it's not in documentation, you could check normally-open vs normally-closed with a multimeter.

curieos

@curieos I created the driver-error/stall/warning macros in the sys folder to try to get more info on what drivers are erroring, but it doesn't seem to be running the macro. I just did a simple one that echos the event properties (like the example on the events page: echo "Driver error from driver: "^{param.B}^"."^{param.D}^" : "^{param.P}^" ,"^{param.S}), but it's still outputting the default error that doesn't log to the console.

curieos

@Maestro The notes for the alternate wiring (which is what we are using for the error signal) says:

As another option, Robbie suggests using 10k pull-up resistors between signal lines and +5V to
invert the signaling. Wire the now-high signals to +PUL, +DIR, +EN, and +ALM. Wire -PUL, -
DIR, -EN, and -ALM to 6XD GND.

So I assume this is how things are supposed to be? I do agree it is weird that the unused headers are erroring. I was hoping the macro would give me more info.

curieos

@curieos @Maestro For clarity on my config, this machine is running with two 6XDs and a tool board breakout with two toolboards, with the primary 6XD operating in SBC mode with a Pi 4. I can't see anything that would suggest this configuration would cause any weirdness, but that's the full details in case this is a bug.

Maestro

@curieos I would suggest building from the level of being confident that the wiring is correct and as expected before moving to software. Some sense could be made of this if the alarm outputs are NC.

curieos

@Maestro Okay, would checking this on the motor with it powered on (but the signals disconnected) be better, or should I check with it hooked up to the 6XD? Tbh, optocouplers are a bit of black magic to me.

Maestro

@curieos Check with external drivers on, but alarm wiring disconnected from the Duet. Resistance should either be very high or very low.

curieos

@Maestro Okay, I tested two ways. The motor starts out at around 17-18Mohm when it's not errored, and moves to around .8Mohm when errored, which I believe means it's NO?

I also verified the error macro works by overpowering the Y gantry. Both motors error out and run the error macro. I'm not sure why driver 2.5 (unused) shows an error, but I did notice driver 2.2 (the one I was testing) also errors when I have it unplugged at the start in the same way (as in, it doesn't run driver-error.g).

Maestro

@curieos Yes, alarms look to be NO. Which means your wiring should work, and it now does, so that's a good sanity-check passed.

So, not sure why the drivers throw an error when unused. Even while open, there are components--albeit high-resistance--in the external drivers' alarm circuit, so maybe these are doing something to startup transients to make the used drivers happier at startup... I dunno. I suppose it's also possible that it's tripping an error due to sensing something--or lack of something--on pins other than the error pin. Perhaps someone with better background can chime in.

curieos

@Maestro Thanks for your help on this! Hopefully someone has an explanation for the issue I'm having. I'm wondering if it has to do with the somewhat funky setup we have. When I get back from lunch, I might try unplugging one of the motors on the primary 6XD and checking if it does the same error on boot.

dc42

@curieos if the driver error event is coming from an unused driver on the 6XD board that is running in expansion mode, and the error outputs from your external drivers are NC, then I can see why that would happen. The simplest fix would be for you to put a wire jumper between the Error and Ground pins on that unused output connector on the 6XD.

curieos

@dc42 Do I need to hookup a resistor across those pins, or is a straight jump fine?

dc42

@curieos a wire is fine. I have created this Github issue https://github.com/Duet3D/RepRapFirmware/issues/896.

dc42 created this issue in Duet3D/RepRapFirmware

6XD external driver error signal handling

open When 6XD is used in expansion mode, unused drivers raise driver error events #896