6XD external driver error signal handling

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

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

Maestro

@dc42 said in 6XD external driver error signal handling:

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

I thought the same, but based on his multimeter test, his external driver error-outs seem to be NO.

Maestro

@dc42 I now believe there is a more general issue with NC alarm setup. I just did a little experimentation with my 6XD. I'm using drivers with NC alarms, single board, standalone mode, 3.4.6. Even with the drivers that are in use, it seems there is an issue with straightforward NC wiring.

Based on the documentation language for the error jumper:

Jumper in the "top"/Pull Down position applies a pull down resistor to the driver fault signals - an external driver must set the line high to indicate a fault. A jumper in the "bottom"/Pull Up position applies a pull up resistor to the driver fault signals - an external driver must set the line low to indicate a fault

So, when the alarm outputs are open, the error pin will always go to the resistor-pulled logic, which means they will always go to the un-faulted position. So, it's always wrong for NC setups, which need to trigger fault when we go to the resistor-pulled logic. Seems we need a logic inversion ability in firmware? Perhaps this exists, but I couldn't find it in documentation (also in this recent thread @T3P3Tony said no go, at least in reference to M569).

Tested:
With external alarm linking error pin and ground, jumper set to pull-up position, I get a fault on startup (alarm circuit is closed). When I trip/open the alarm, there is no error event raised. When I reset/close the alarm, an error event is raised.

With external alarm linking error pin and 5v, jumper set to pull-down, I get the same behaviour; fault event on startup, no fault when the circuit opens during an alarm, fault event raised on alarm reset as the circuit closes again.

These tests are exactly as expected based on documentation. If we had the ability to invert interpretation of these signals in firmware then it seems NC alarms could work fine without any fancy wiring.

curieos

@Maestro I'm not a guy.

To be honest, I'm not sure how much I can trust the multimeter readings I got. The meter we have is a bit sluggish to auto-range, and it was refusing to switch out of megaohm range until I switched it off and back on. The problem exists regardless, we should be able to configure the behavior of the error logic on the drives. I'm honestly unsure how NO and NC setups are supposed to work, is the firmware assuming the drives startup un-faulted and adjusts automatically?

Maestro

@curieos Apologies, made an unconscious assumption there.

Well, your alarm wiring is now working aside from the startup blip, which seems to indicate they're NO. Which matches with your multimeter readings. It doesn't seem you would have gotten the alarms to trigger in-use if they were NC. Unless you know something I don't about the firmware-side setup.

As far as how NC vs NO are supposed to work, it seems that the firmware currently knows nothing about NC/NO alarm status; I couldn't find anything about this in documentation. All the firmware knows is that if the error pin deviates from the jumper-pulled logic it's faulted. In both jumper positions, the driver must set the line to the opposite logic to trigger a fault. An NC alarm cannot directly set the line to something else when faulted, because then it's open-circuit and cannot affect the line; an NC alarm sets the line to something else when not faulted. The NC can be made to work with the current firmware (or my understanding of it), but the signal needs to be inverted in hardware.

It's not really a complicated circuit, but for some reason I'm finding it oddly brain-twisty. The possibility remains that I'm utterly wrong...

dc42

@Maestro the firmware measures the state of the.alarm inputs at power up and assumes that the majority are not signalling an alarm. That's how it determines whether the inputs are active low or active high. However, this will fail if the external drivers have NC alarm outputs but the drivers take a while to initialise and set the alarm outputs to closed. So we may need to add a configuration option to specify the signal polarity.

Does it work if you power up the external drivers before you power up the Duet?

Maestro

@dc42 I did also test with drivers already powered first, but I only had two drivers connected, so based on this majority-rules approach it wouldn't have decided on NC configuration anyway.

I'll test later and confirm whether I get the response you expect. Either way, I do think the ability to set this logic would be a significant improvement, both for the delay in driver boot-up, and for the added assurance that the firmware will not make an incorrect assumption if something goes screwy at startup.