Skip to main content
Submitted by jeremychoate on Tue, 04/04/2017 - 12:05

Hello everyone,

Just wanted to share some lessons learned from my experience with the Electronic Lock Out functionality of the DMC=41x3 controller that I am using for the project on which I'm currently working.

[b]How I'm Using It[/b]

First, it would be useful to give some background. I have an e-stop pushbutton that is being monitored by a safety relay module. The safety relay module's two safety outputs provide coil power to two (for redundancy) safety relays with force-guided contacts. Through the normally closed contacts of these safety relays, I am sourcing 24VDC to the ELO inputs of my DMC-41x3 (44-pin I/O pin 5). I have 0VDC wired to INCOM0 (44-pin I/O pin 17), making the ELO inputs Active High.

So, when I press the e-stop, the safety relay module opens its safety outputs, killing coil power to the safety relays. The normally-closed contacts of the safety relays then source 24VDC to the ELO pin(s) of the DMC-41x3.

[b]ELO Active Input Status in Watch Window[/b]

Contrary to what I first believed, the ELO Active tags (TA3AD and TA3EH) are not ON when there is voltage applied to the ELO pins and OFF when voltage is removed. When the ELO condition is tripped, the ELO Active tags latch until a Motor Off (MO) instruction is followed by a Servo Here (SH) instruction, or the controller is reset. This misunderstanding caused me a bit of grief in my code, which I will explain, next.

[b]The #AMPERR Automatic Subroutine[/b]

As documented in the literature, when the ELO is tripped, the code drops into the #AMPERR automatic subroutine (assuming you placed it in the program). The first thing that you MUST realize about this is that [b]the ELO Active condition will not trip for a particular amplifier unless that amplifier has at least one motor under servo control.[/b] Don't make the mistake that I made. While debugging my code, I simply wrote stubs for my various subroutines that contained only debug statements (MG instructions) and contained no motion instructions. I did this just to verify program flow and communications with the PLC but became frustrated when my ELO functionality would not work. This is because I had no motors under servo control when I pressed the e-stop.

In the previous section, I mentioned that the ELO Active condition latches when tripped, and that it caused me a bit of grief in my #AMPERR routine. See the following code:

[font=Courier]#AMPERR
MO
#ERLOOP
WT 2
JP #ERLOOP, _TA3=3
SH
RE[/font]

This is a simple version of my code, but when the ELO condition is tripped, the routine issues the motor off command (MO) to all axes. Then, it drops into a waiting loop where it spins as long as _TA3 (Tell Amp Status Byte 3) = 3, meaning that the ELO Active tags for both amplifiers in my controller had a value of '1'. It was my thought that once I removed voltage to the ELO pins, Amp Status Byte 3 would change to '0', and the code would exit the loop, re-enabling servo control (SH), and return from the #AMPERR routine. This is not the case. In order for _TA3 to change to '0', the SH command must be issued. Since, I was doing this outside the loop, I created a Catch-22 for myself and could never escape the loop.

There are a few ways to escape the loop: first, one could bring 24VDC from the safety relay to one of the Digital Input pins on the controller and use the condition of the input as an escape condition. When the safety circuit is reset, the loop is exited. In the end, since I am communicating with my PLC via Modbus TCP, I simply left my Modbus communications thread running while the controller was in the #AMPERR routine and used a Modbus signal from the PLC as an escape condition.

[b]ELO Condition during Controller Power-Up

When power is lost and restored to the panel, the safety circuit, by design comes up in an OFF condition. As such, when the controller is powered up, it has voltage on the ELO input pins, already. The key thing to remember, however, is that the controller will not immediately drop into the #AMPERR subroutine; as mentioned before, there must be a motor under servo control for the ELO to be tripped. When the controller is powered up, it will run the #AUTO subroutine, as it would normally do, without the ELO condition present.

So, I ensured that I ran all my initialization logic and started my communications threads in my #AUTO routine, [b]BEFORE[/b] initializing any motion logic. Once I placed my motors under servo control (SH), thread 0 immediately dropped into the #AMPERR routine. Because I had performed all my initialization logic and started my communication threads, before placing motors under servo control, it allowed me to continue running non-motion related threads (such as my Modbus communication thread) even while the controller was in #AMPERR routine.

[b]Conclusion[/b]

The ELO function is a perfect way to isolate power to the motors during a safety stop condition...if you know the ins and outs of how to use it.

Comments 2

KushalP on 04/04/2017 - 15:34

Hi jeremychoate ,

Thank you for sharing your feedback, it will help others who may have a similar use for ELO.

stevenhung on 09/24/2018 - 15:44

Thanks Jeremy, this was a super helpful post. You saved me a lot of headache and searching for information.