6XD external driver error signal handling
-
@curieos as far as I know, driver events are internal only. I believe you'll need to use triggers instead to generate a pause
-
@curieos I'm only just starting to play with the 6XD, but triggering the 6XD local drivers' "ERR" pins certainly does seem to raise an event. I get an Event Notification popup: "Driver 0.1 Error: Exernal driver error". I've yet to try actually doing anything with this event, but I assume it would run the macro if I had one.
Remember the 6XD does have an external driver error selection jumper for pull-up vs pull-down. Also, are you sure the external drivers themselves actually triggered an error? From what you describe it sounds like they may have just happily continued on.
-
@Maestro I'm not positive they did trigger an error. I believe an error light on the motors came on, but it was a week or two ago when this happened, and I'm not exactly trying to stall out the motors on a regular basis.
I know about the jumper for the error signal, and I believe I have that hooked up correctly as well. The motors we are using are modified Leadshine motors from A3DP. We have them hooked up in a slightly funky configuration, the control signals are common +5v, and the error+ from the motor is hooked up to error in on the board, and error- is hooked up to ground. The jumper is set to pull down. The intended configuration is common 5V for every signal, but this machine had 6 conductors run for signalling, so I decided to use them all.
-
@curieos I can claim only a quick glance at the Leadshine manual you linked, but it sounds like your alarm/error circuit is mis-wired. The Leadshine's alarm circuit is just an optocoupled throughput. So if one alarm lead is hooked to the 6XD error pin and the other alarm lead goes to ground, you have no signal/voltage on that circuit. You need your 5V to the alarm+, and the alarm- going to the 6XD error pin.
-
@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.
-
@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.
-
@Maestro Ah, should I have the jumper set to pull up then? And in the opposite config, the jumper should be pulled down?
-
@curieos Yes, with your existing wiring you should be pull-up. My example above would be pull-down.
-
@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?
-
@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?
-
@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.
-
@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 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. -
@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 @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.
-
@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.
-
@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.
-
@curieos Check with external drivers on, but alarm wiring disconnected from the Duet. Resistance should either be very high or very low.
-
@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).
-
@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.