Is it Possible to Enable Remote Ethernet Drive with MSG Command on MicroLogix 1100?

[Craig Chamberlin 1]

I was asked this question about three hours ago by someone who called in and I am having difficulty coming up with a method to actually do this. He would like to issue an enable (set a register on a remote Ethernet supported drive to on) using a Micrologix 1100 drive with built in Ethernet. I have attempted to open RSLogix 500 to duplicate a scenario in which this is possible but cannot seem to have any luck with it. I do not have an option to click a "communications" tab when creating the MSG block so I can specify the IP address of the drive. Could someone specify a document that may aid me in this? Or specify whether or not it is even possible? I would really appreciate it. I don't mind doing the leg work if someone can just point me in the right direction. Thanks in advance!

[Ken Roach 194]

Do you literally need to Enable the drive, or are you starting it, or are you trying to set a specific parameter ? What exact model of drive is it ? The MicroLogix 1100 can send CIP Generic explicit messages but you need to understand the EtherNet/IP and driver interface object model to use them. Some users try to implement a simple control mechanism over EtherNet/IP with MSG instructions in SLC and MicroLogix controllers; I always strenuously object and explain in detail why it's an unwise choice, but usually they end up doing it anyway.

[Sergei Troizky 26]

Could you please explain this in detail here? Or give a link if you did so before? Edited 23 Dec 2010 by Sergei Troizky

[b_carlton 61]

We set operating parameters via communication (MSG if needed) but enable motion by hard contact. There is always the backup of the EStop circuit which either shuts down all power to the drive, if there is no 'Safe Off' circuitry, or disables the 'Safe Off' if there is.

[paulengr 44]

Assuming we're talking about a Powerflex drive, you can't really do an enable from a processor that can't do connected CIP which is what you'd need to pull this off (aka "Ethernet IO"). At best, you can probably send explicit "start" and "stop" commands or use the speed reference as a "fake stop" (if speed = 0, drive shuts off if you set the minimum speed on the drive above this). However, there is a huge problem with this. Normally you'd want some sort of feedback system where the drive could recognize when the communication connection is broken and fault, shut down, or otherwise take action to eliminate the problem. In this case there is no such animal, so any communication failures although they might be detectable at the PLC side of things go unnoticed at the drive side. If communication fails for any reason, the drive probably will never see the "stop" command. The better way to do what you are suggesting is simply to hard wire one output of the PLC to the enable input of the drive, or wire it in "series" if you insist that the "hard wired E-Stop" is somehow "more reliable". In this case I'm advocating simple hard wired control for stop purposes simply because in this particular case, it's probably more reliable than the communication system being suggested. If the PLC supports Ethernet IO however (Logix 5000-based PLC's), the situation changes quite a bit. In this case the drive and the PLC are continuously broadcasting messages to each other. The drive and the PLC use this active stream of packets to detect (and react to) communication failures. Keep in mind that an E-Stop is when you are expecting human performance to handle a failure. Here's some documentation on the "HEART" method for determining human error probability. It's not necessarily the "best" method out there but it's fast, simple, approachable, and not much worse than any other method. http://www.laas.fr/IFIPWG/Workshops&Meetings/46/05-Harrison.pdf Under the best of "E-Stop" conditions, human error probability is 55% by the HEART method. If there is emotional stress, increase it by 1.3. Since E-Stops generally result in equipment damage and/or loss of production, this is counter to standard training, so multiply the error rate by 6. Unfamiliarity increases it by a factor of 17. Very short time available to make the decision increases the failure probability by a factor of 11. So...pretty quickly the chance of handling the situation correctly drops from roughly worse than blind luck to no chance at all. Second, when comparing "soft" stops to "hard wired" stops, there are two concerns here. First, there's the concept of "layers of protection". For instance if I have a true "emergency stop" system or set of interlocks that fire independently of the PLC, this provides me with an independent safety system. I can take credit for the idea that the control system is programmed not to allow the situation to happen, and even if that fails, there's a secondary safety system which can activate and prevent catastrophy (assuming it's not an operator pulling the switch). So this may be one reason when the "hard wired" system may be desirable. The second reason is that there's a belief out there that somehow a PLC is never as reliable as a hard wired relay. Well, the reason that PLC's have almost entirely replaced relay systems is because they are so much more reliable. In the end though we still usually have an output relay whether it's "hard wired" or a PLC, and that's where the system weakness is.

[BobLfoot 302]

Paul the document/presentation you linked goes about six layers of sophistication over my poor farmboy education, but I can get the jist that Human Failure needs to be included in the Design Analysis and Failure Analysis stages of equipment engineering. I also am coming to like your point more and more and I may be paraphrasing and oversimplifying it but "a human activated emergency stop is the worst case last resort for system protection".