Safety considerations using software based controller?

Hi,

I’m build a rather large and powerfull machine and a couple of safety considerations “scare” me a bit. Thought i’d post here and see what you guys think. Maybe some of you have found good solutions.

First of: personal safety. How do you wire e-stops to servo drives? Do the “e stop signal” go through software to actual stop moving parts? What is something in the software fails(hang, unexpected exit, OS reboot etc), then e-stops dont work, isn’t this an issue? Isn’t “professional machines” using seperate safety logic to prevents this exact issue? I see that eg. Bechoff have dedicated yellow “safety modules”, i guess this is for this exact reason?

Second; machine safety: my machine is powerfull and running a axis motor going too far will break something(snap bolts, break bearing housings, run linear rails off-track, crash into housing etc). To avoid this i’m pretty sure i’m going to add limit switches(not to be confused with homing switches!) to all axis. But as with personal safety, how do i make these switches robust against software errors? I’m configuring LinuxCNC so there is a pretty good chance i’m going to make a mistake somewhere and then cause a major crash of one of the axis. So how do prevent this? Again, i’m thinking in terms of seperate safety logic maybe? How have you wired and configured limit switches? What are your considerations to prevent yourself from destroying your machine?

I was hoping to start a discussion about how to do these kinda safety implementations correctly together with LinuxCNC. I’m currently trying to find a good solution for my build and any input are greatly appreciated!

/Thomas

Hi,

No, don't leave software in control of the e-stop.

I'm using a hardware-only e-stop circuit with a safety relay that controls duplicated contactors that control the power to the servo drives. A status signal from the safety relay is connected to an input to LinuxCNC to directly control LinuxCNC's e-stop status. This means that if an e-stop is triggered and LinuxCNC is still running correctly, it will disable and stop the servos immediately, just before they lose power.

There is also a relay in the (dual, short-monitored) e-stop chain that is controlled by LinuxCNC, so that I can signal an estop from LinuxCNC if needed. So LinuxCNC needs to be running to be able to exit e-stop, but LinuxCNC cannot exit e-stop by itself. Disabling the e-stop requires resetting the e-stop chain (resetting the e-stop button(s) and any other e-stop conditions) and then pushing a physical button connected to the safety relay. (I'm also using this LinuxCNC controlled relay in the e-stop chain to force a minimum of 15 second power off time of the servo drives, as specified in their manual.)

The safety relay also has monitoring inputs connected to the contactors' auxilliary gates to ensure that both contactors have cut out (i.e. that they aren't welded) before it allows exiting the e-stop state.


Limit switches are wired directly to the overtravel inputs on the servo drives (as well as to LinuxCNC). So again, a software malfunction or configuration error will not allow the servos to overrun.

arvidb wrote:

I'm using a hardware-only e-stop circuit with a safety relay that controls duplicated contactors that control the power to the servo drives.  [...]

The safety relay also has monitoring inputs connected to the contactors' auxilliary gates to ensure that both contactors have cut out (i.e. that they aren't welded) before it allows exiting the e-stop state.

Sounds very interesting! You mention "safety relay", is this specific hardware or is it just something you designed using regular relays?

Regarding your input on limitswitches triggering functions inside your motordrivers is interesting! I'll have to look into if my drivers support this aswell, its a good solution which doesn't "depend on software" to work...

Thanks for your input!

/Thomas

It's specific hardware. I use an ABB/Jokab RT9 , I guess the modern equivalent would be something like the ABB Sentry SSR10 .

If your drives doesn't have overtravel inputs, then at least they should have some kind of enable (or disable) input which you could wire to the limit switches (together with a manual override for jogging off the limit).

Expanding on Arvidb's nice explanation...

A 'safety' relay has something called force-guided contacts.  In theory, if the contacts are welded together the coil has enough strength to tear welded contacts apart - thus breaking the circuit and hopefully de-engergizing something appropriately.

Modern safety relays can get rather complicated.  A quick internet search and download some datasheets from various mfgr's and you'll quickly see why they're complicated and fairly expensive.  At some point, it's cheaper to get a safey-rated PLC and use that to manage the e-stop or safety system(s).

Regarding the limit switches & drives and so forth, most drives from bigger-name vendors have limit switch/sensor inputs directly on the drives.  The scheme is that the main controller tells the drive to home, and the drive manages the homing routine and reports back to the controller when complete - and then monitors the switch for an overtravel event.

The complication is that LCNC's built-in homing routine is based around LCNC monitoring the switches and the drives are 'dumb', for lack of a better term.  Some folks on the forum (obviously Arvidb is one of them) have figured out how to have both the drives and LCNC monitor the switch.

Or have just the drives monitor the switch and report to LCNC.  Not sure how that all works, but I'm sure once you get further along folks here can help out.

spumco wrote:

The complication is that LCNC's built-in homing routine is based around LCNC monitoring the switches and the drives are 'dumb', for lack of a better term.  Some folks on the forum (obviously Arvidb is one of them) have figured out how to have both the drives and LCNC monitor the switch.

I guess the only advantage of wiring them to LinuxCNC as well is that you get a clear error message describing what happened, instead of just a following error, on hitting a limit. Edit: Oh, and as you say, one can use the limit switches for homing as well then. Although I have some problems with EtherCAT drives erroring out because LinuxCNC tries to continue the motion beyond the limit switch during deceleration while homing, which makes the drive error out. Still need to look into that...

I have some old (90's) Yaskawa drives - these cannot report overtravel status to LinuxCNC, so I just split the signals from the switches to both the drives and the Mesa card. On the other hand modern EtherCAT drives can report pretty much anything back to LinuxCNC, so there the signal goes to the drive only and LinuxCNC can monitor the status registers in the drive to know what's happening.