6XD external driver error signal handling
-
@curieos a wire is fine. I have created this Github issue https://github.com/Duet3D/RepRapFirmware/issues/896.
-
@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.
-
@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.
-
@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?
-
@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...
-
@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?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@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.
-
@dc42 I did some quick tests and see what you indicate. With 4+ drive alarms closed at startup, all drives are treated as NC. In the middle case of 3-closed 3-open, it prefers NC, and applies NC to all drives.
Not to pile on, but an additional use case for logic selection is mis-matched drivers. I'm currently bench-testing with two NC-alarm drivers, but the final machine will have an additional four external drives. These drives haven't been selected yet, but they definitely won't match the first two, and could end up being NO-alarms. A global logic selection would at least allow selection of which drives you want the alarms to work straightforwardly on. A per-driver selection would be configuration nirvana!
-
@Maestro I created https://github.com/Duet3D/RepRapFirmware/issues/898.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
undefined p8blr referenced this topic
-
@dc42 Sorry for reviving an old post but I am curious if this feature was added in the latest firmware release?
Thanks!
-
@p8blr this has not been implemented yet.
-
@T3P3Tony Because of this limitation, I don't think the HLFB (high level feedback) signal from Teknic servo motors can be used as an error signal to the duet. The way Teknic handles it, the HLFB pin will conduct (Active-High) when the servo is enabled and not in a shutdown state, but the servo will not be enabled on startup. Because of this, the current firmware will assume Active-Low on startup, and when the servo is enabled, it will trigger a driver-error event.
For Teknic servos (very popularly paired with Duet hardware) the error pin should only be observed when the printer is sending an enable signal and attempting to send move commands.
Are there any solutions in the meantime? I need a way to protect a large printer from potentially damaging itself.
-
@p8blr could you wrie some conditional gcode.logic to handle this in the event macro? So only trigger an event if the driver is enabled?
-
@T3P3Tony Yep, that's what I ended up doing. I spoke with Teknic support and expressed interested in the HLFB wire potentially signaling errors rather than enabled status and they filed my feature request. For now this is my solution: https://forum.duet3d.com/post/346434
