MSG block machine interlock ideas

In our plant, we have a lot of issues with IO from one machine to another getting corrupted and failing. I put forth the idea to have the permissive signals (downstream running signals) to be communicated over ethernet instead of relying on this constant downtime problem. So they approved a test line to incorporate this idea and see how it operates. Now let me start by saying the safety circuit and associated interlocks are not part of this. it's just the single wire interlocks that over the years were put in place to tell one machine what's running and what's not ahead of it.

I've almost completed my work and was wondering if anyone else has done something like this and what others' thoughts are on this. I'm taking precautions where possible by having timeouts on both ends of each PLC-PLC comm end.

All message blocks are on data change triggers and repeat if no data change timers as triggers to continuously check for connection and turn off machine if loss of connection. All message blocks are write blocks and all receiving PLC's look at an always on bit in the date file, upon seeing it they unlatch that bit and reset a check timer.

Anyway, if you have any other questions on my setup or want to offer insights let me know. Thanks for an awesome forum.

bump

You need to provide us with much more details. What processors, versions, etc. How are they wired now and to be in the future.

Oh I see. Sorry about that. All of them are either 5/05 processors, Controllogix processors, or Compact processors and all of them are interconnected via a ring type roof network with cat 5 cabling. I am currently messaging them explicitly with message blocks that send data out every 10 seconds or if anything in the data I'm monitoring changes. The receiving plc has a timeout bit/latch rung that tests to make sure a bit resets every 10 seconds to make sure it's data is being refreshed. That's basically how I have it.

How is the I/O being corrupted? How are the signals being transferred now? Are you using MSGs now BEFORE Ethernet. I'm confused as what your system architecture is now.

The IO is all hardwired from one machines output card/relay to another machines input card/relay. This travels through conduit and other media types through a heavily washdown environment. There was no ethernet comms like what I'm suggesting before. This is a new concept for everyone here at the plant. Since ethernet has a bunch of troubleshooting tools and stuff that can pinpoint almost exactly where a problem is occurring, and it rarely fails if properly setup, I thought it would be interesting to see if we can control all these hardwired interlocks through an ethernet channel instead of hardwire.

They fail mainly due to fuses being blown or corrosion on the connection points. It's rarely the PLC input/output cards that are the culprit. It's also being looked at to possibly do away with the massive bundle of wires that current systems use to communicate. As long as the safeties are not over ethernet, obviously, i really don't have a problem with the idea.

That's why I posted on here to see if anyone else had experience doing this and/or have any pointers that I neglected to see or overlooked altogether.

So these signals are all digital signals? Any analog? What voltages? What do you mean by corrupted? Noise issues?

Right now they are digital. Simple flags telling the upstream machines whether or not the machine (VFD) is actively running at speed or not. When I started programming this conversion over to ethernet, I'm allowing room to pass along more information if needed in the future. I'm thinking simple universal 8 bit fault codes that could be displayed for operators for machines that aren't actively being watched. Stuff like that.

As far as corrupted goes. Basically any type of failure that inhibits that digital signal from being received by the upstream machine. Whether it be a bad relay, broken wire, shorted wire blowing a dc supply fuse, stuck output/input on PLC card, etc. More or less physical disruptions on a digital on/off signal. Mostly they are 24VDC signals but we do have a couple of 110VAC interlocks out here. But all of them are strictly on/off signals.

I do what you propose a lot as I prefer to interlock with comms Vs hardwire because with hardwiring you have to mark panels as fed from a different location and you can have live voltage present with the disconnect off.

Also it must be run with orange wire to make it know that it's fed from a source outside that cabinet but with comms only interlocking you don't have to do this and it's much safer for your maintenance and repair team.

I make demarcation pages in the prints to explain what funtions are interlocked from another line or piece of equipment.

If all you stuff is on one flat network of the same subnet then it will be fairly easy but if you have other network layouts which is very common it can get more involved with layer 3 switch and VLAN routing,etc.

To me it's worth it YMMV.

Thanks plc kid. That's what i was looking for with this post. Yes we have one big network (plant plcs and hmi's only, no IT stuff) all on the same subnet so it is fairly easy. And i also concur with the hassle associated with different color wires, live voltage considerations, even arc flash prevention. Thanks for your input on this.

Anyone else have any insight, tips and best known practices, etc on this subject?

When it comes to interlocking via Ethernet I always try and have a standard block of data. Speed, Current State, etc. This way I know what I am looking for at each machine. The problem that comes in alot of time is that stuff gets added and people for forget. Also I like to create a Master/Slave setup so All of the line PLCs report to one main PLC (basic concept behind SCADA) so I only have to look in one place for data and programming becomes more transparent.

I have been in plants where the data went from PLC to PLC in a daisy chain setup and it was a nightmare to troubleshoot.

Using ethernet makes this a breeze and remote troubleshooting lots easier.

If you have Control/Compact Logic PLCs then you can use Produced Consumed Tags instead of Messaging which in my opinion is much easier. The SLCs will require messaging (another reason to go to only one PLC).

Thanks for your response. I agree with the daisy chain response you had. I send my machine running/not running status' and other information to a central plc and that one in turn sends messages back out to enable or disable starting of equipment. Each piece of equipment has a local/remote switch on them. Right now the hard wire setup is the same way. All hardwires go to a central plc which then sends outputs either through local IO or remote IO via devicenet to enable or disable the machines to start. All i'm doing different is to relay that master data file all the way to the beginning of the line for display on a local operator HMI so they know what's going on at the other end of the plant. I figured since i was doing that with the information, why can't i run the interlocks the same way and forgo the hardwire interlock which tends to fail. As an added bonus i can check whether a connection is active or not by a logical check every 10 seconds whereas a hardwire connection could fail and then fail to stop a machine if downstream equipment should stop (which has already happened a couple of times).

I really need to learn how to separate paragraphs. lol. Sorry for jumbling all that together. Wrote it pretty fast.