Defining interlocks for the non-programmer

alexplcguy

Member
Join Date
Dec 2021
Location
Georgia
Posts
2
Non-PLC guys asking me to explain all the interlocks of my system in a document. Problem is for this system its a little complicated (OR conditions, seal-in conditions, etc)... From my perspective the easiest way to understand it is to learn to read ladder logic. However, I was hoping someone had a better answer. A way I can graphically and verbally describe a system with many many interlocks.
 
Easy
Just do screenshots and put them in a word document with short explanations
Bam
Done
 
What languages (english? fortran? javascript? etc?) do these non-PLS guys speak?


Traffic lights.
 
Last edited:
Non-PLC guys asking me to explain all the interlocks of my system in a document. Problem is for this system its a little complicated (OR conditions, seal-in conditions, etc)... From my perspective the easiest way to understand it is to learn to read ladder logic. However, I was hoping someone had a better answer. A way I can graphically and verbally describe a system with many many interlocks.

Can you make a simpler program?

Honestly, it should be pretty clear if a motor can operate, or a tank to fill (valves), or heating element.

K-mapping comes to mind but... if you over do it, it can make stuff harder to read later. https://en.wikipedia.org/wiki/Karnaugh_map

edit - I should add that interlocks to me are absolute reasons a device can't operate. So, outside of when it actually does operate from a recipe. If they want to know when it'll start/stop then you want a sequence chart.
 
To me, "interlocks" are different than "permissives". To my mind an interlock would be tied to a related machine, and a permissive is local to the home machine. For example, the cup filling machine has a lot of permissives such as temp, surge levels, ect. before a cup is filled. It is also interlocked with the case packer that loads the filled cups into boxes. The case packer has its own set of permissives before it will cycle, and is interlocked to the case closer. The case closer is interlocked to the palletizer, and so on. Before you spend a lot of time on this, I would see if you can get them to explain what they mean by "interlocks"
 
Do you mean it is not already done via comments in the code?

Can you post the most complicated interlock you have?
 
Last edited:
To me, "interlocks" are different than "permissives". To my mind an interlock would be tied to a related machine, and a permissive is local to the home machine. For example, the cup filling machine has a lot of permissives such as temp, surge levels, ect. before a cup is filled. It is also interlocked with the case packer that loads the filled cups into boxes. The case packer has its own set of permissives before it will cycle, and is interlocked to the case closer. The case closer is interlocked to the palletizer, and so on. Before you spend a lot of time on this, I would see if you can get them to explain what they mean by "interlocks"

Everything you said is bad programming to me.

I should know exactly why a system can't work. If a system can't work in a recipe thats another issue.

Cup in sensor view or hand... who cares, they are hacking the system.
 
Everything you said is bad programming to me.

I should know exactly why a system can't work. If a system can't work in a recipe thats another issue.

Cup in sensor view or hand... who cares, they are hacking the system.


My comment was more to the possible mindset of the non technical people asking for the details of all the interlocks. With any luck at all not a single one of those people will ever have access to the program where they can read the comments.

As for the quality of the programming I deal with day in and day out, let's just say, Rube Goldberg would be
impressed.



Bubba.
 
An alternative to describing the interlocks (or permissives, whatever you choose to call them) in a document is to provide a page on your HMI that shows the status of each of those interlocks.
At my plant we have a color coding scheme on some of our machines' HMIs. A motor colored violet means that it is not allowed to run because of interlocks. If it is red, then the motor is allowed to run but it is not being commanded to. Green means it is running. On the devices with many interlock conditions, we create a button that the operator can press that brings up the list of interlocks with indicators next to the text. Green means it is good, red means that the interlock is not on.
 
With any luck at all not a single one of those people will ever have access to the program where they can read the comments.

Of course. And it should not be left to luck.

What I'm saying though, is that if the interlocks are complex, then for the sake of debugging three months from now when the model of the entire process in not readily accessible in OP's head, it is an absolute necessity that there should be a description in the code of why, from the process standpoint, a device is either permitted to either run/[be 1/on/True/...], or not. That being the case, the content of the requested document is already written.

And +1 for the HMI post.
 
An alternative to describing the interlocks (or permissives, whatever you choose to call them) in a document is to provide a page on your HMI that shows the status of each of those interlocks.
At my plant we have a color coding scheme on some of our machines' HMIs. A motor colored violet means that it is not allowed to run because of interlocks. If it is red, then the motor is allowed to run but it is not being commanded to. Green means it is running. On the devices with many interlock conditions, we create a button that the operator can press that brings up the list of interlocks with indicators next to the text. Green means it is good, red means that the interlock is not on.

This here.

If we do an HMI - we always post an interlocks screen. I also always have all of the I/O on screens - with descriptions - so you can quickly see if an I/O point is on or off.

I see this neglected often when outside contractors build panels for us.

On another subject - all interlocks (in my experience) should be dry contacts and have a simple description.

For example: System Ready, System Running, System Fault, etc. You don't have to explain all of the And/Or conditions that means the system is running - only that it is.
 
I guess my interlocks are pretty simple, even if long at times. I use ints and each bit is a condition. Compare the int value with configured value for interlock OK.

As others have said, a pop-up with the interlocks and their description is more useful to the operators and maintenance than actually understanding the logic. A short string of text is all they should need. IME if a short one line piece of text couldn't describe the interlock, it needed to be re-evaluated on my end.
 

Similar Topics

Hi Everyone, I have a somewhat silly question. I've primarily programmed with Beckhoff PLCs in the past. In those, we can assign the string TRUE...
Replies
8
Views
2,257
Hello all. I am working on a project where there are 7 vents which have a cooling function with a S7-1200 station and a KTP Basic panel (1st.gen)...
Replies
6
Views
2,560
Hi guys, I asked this question on the Codesys website and didn't have much success with it. I'm looking at a way of defining arrays for real...
Replies
8
Views
5,479
hi to everyone, we are using ISaGRAF for programming our PLC. The problem is that we want to change the IO boards of the computer that we use...
Replies
0
Views
1,876
Hi I'm trying to define a string array using Citects SCADA package and I've got an error that I can't shift. I've defined a variable of the...
Replies
10
Views
13,078
Back
Top Bottom