Interlock conditions to the HMI

Hi all,
I like to know any ideas/best way (most efficient, simplest to maintain/update) to transfer the interlock conditions up to the HMI. We use a Siemens 315-2DP with an OPC server to our 3rd party GUI interface. Sorry for the long post, but I don't quite know how to word this succinctly.

On our machine, we have a lot of interlocks on the power sources, motor movement, robot, etc. Any one interlock may have a number of criteria to satisfy it.

for example: to allow part elevator movement ...
A Robot_Homed
A Robot_Not_InShaft
A Elevator_Homed
A Door_Closed
= Elevator_Move_Intlk
Some are more complicated - they may involve a time delay or number comparisons.

The OPC transfers the interlock result as part of a status word on the device in question (the status word includes device actual state - on/off, fault exists, last HMI request,etc)
However it does not contain the reason why the interlock may not be satisfied. The OPC gets a lot of the various conditions separately as part of statusing other items on the GUI (the GUI shows location of the robot, etc) but it doesn't get all conditions for every interlock.

We maintain the interlock condition list as an Excel file but this only allows the operator to check what all the reasons are and not which one is actually causing it to be off.

To show the interlock conditons dynamically on the GUI, I can think of a couple ways but all of the involve a lot of work so I'm trying to figure out which way to go.

1. Make sure all the bits (and in some cases ints or words) in the condtions are transfered separately via OPC and on the GUI bring all the bits together and recreate the intlk condition string. Basically I'm recreating the PLC code in the GUI and creating another place to maintain the intlks.

2. In the PLC where the interlock is ascertained, also transfer the condition bits into a separate word/doubleword, then tranfer just the word up. Show the word as a bit array on the GUI using a text file listing what the bits are and how they are used in the condition. This would keep it all together for the OPC and the GUI but would double the interlock code.
A Robot_Homed
=Elev_Intk_Stat1
A Robot_Not_InShaft
=Elev_Intk_Stat2
A Elevator_Homed
=Elev_Intk_Stat3
A Door_Closed
=Elev_Intk_Stat4

A Robot_Homed
A Robot_Not_InShaft
A Elevator_Homed
A Door_Closed
= Elevator_Move_Intlk

Any other ideas, thoughts?
Thanks!

Tasirius said:

Any other ideas, thoughts?
Thanks!

Click to expand...

My idea is to just do it in the PLC, that is what they do best, and let the HMI be what it does best a Human Machine Interface, not a controller.

I think #2 would be easier to implement. It would be a lot easier if the original programmer of the logic had worked with that objective in mind.

How capable is your HMI in dealing with an SQL database? You could use a field that "ties" all relevant conditions to each interlock. You would then need to pass status bits via OPC, but the "logic" lies in the database table. The more complicated ones with delays and multiple comparisons should already exist in the PLC - the HMI just uses the resultant bit. This would go with your option #1.

It's hard to say what is easier/better between #1 and 2. As Steve mentioned, it depends on how the PLC is programmed plus your HMI capabilities. If the PLC program is conducive to just adding labels - go with #2!

WOW, I miss read that one, sorry - it was a "L O o o n n g g" day!
Relaxing now, sipping a glass of Chianti.

If you use #1 then you will need to make sure that if anything outside the PC stops a drive that the PC is aware of this and will not allow equipment to restart without warning.
eg. Some time ago a I had to modify and old DOS based bin fill system. The front end was a SCADA that used a programmin language similar to Seimens S5 STL. The original programmer had written all interlocking etc in SCADA , the PLC was basically just an interface to outside world. Proble was if the SCADA failed and then someone pulled a safety lanyard the equipment would stop (so far so good) but when the lanyard was reset the converyor would restart without warning. So my vote is with RussB

Hi all,
Thanks for the replies. Some more things to think about.

To clarify a bit more: the PLC is handling the interlocks. The reproduction on the HMI is just for statusing so the operator can figure out why he can't get the robot moving, etc. Sometimes its pretty obvious but a few of the conditions are not and there are always new operators. The company likes to crosstrain.

Yes it would have been nice if the original programmer had thought of this and designed something in from the start. If you were starting from scratch and wanted to include all the interlock reasons in the GUI, would you use one of these approaches or design the interlock somewhat different? Maybe have the interlock result be a number instead of a bit so that it includes the reason?

Thanks

I've seen a nice simple way of doing this, I will try to explain it. Each function has a screen that displays the interlocks in a graphical fashion. It's just a line with green or red circles on it. At the end of the line is the output to the device, let's say it is a hydraulic pump motor.

If there are four permissives for the pump motor there would be four circles on the line, with a circle for the output to the pump at the far right, end of the line. If a permissive is on (satisfied) the circle for it is green, red if the permissive is off. When the pump does not run they can go to the screen and see what permissives are off or on.

For mapping to the HMI the permissives in the PLC could be mapped to bits in a word for contiguous data transfer.

I realize this may not be as full-featured as you were asking but I've seen screens with 50 red circles and its very easy for an operator to "see" what is keeping the function from completing. The down side is if a permissive in the PLC logic is added or removed you must also modify the HMI screen, but I don't know a way around that. The up side is its very simple to construct a permissive screen and it conveys the information perfectly.

Yes, an idea would be to map each bit to a bit in a word (well, multiple words, since it seems like a relatively large system) and transfer those words, with something on the HMI to act on each individual bit, whether it's an image, or however else you want it to work. Basically this is a combination of both 1 and 2. You have a single interlock bit, but you also have a bunch of words, where each bit in the word represents a specific permissive required, and the HMI can deal with that data.

If you did it that way, there should be lots of ways of representing what's wrong, since each possible combination of failures would map to it's own numeric value. For instance, if you had 5 permissives, and #1, #3 and #5 were not right, you'd have a 5 bit number of 10101, or 21, stored in a word. If only #2 and #4 failed, you'd get 01010, or 10. (those numbers are reading binary from left to right, with 2⁰ being on the left, rather than the right)

If you wanted to minimize future changes in the hmi and tags in the hmi you could use the interlock states to set a text string in the plc. That is after your permissive rung have a set of rungs with the opposite of each interlock to load a string the hmi then reads and displays this string. Yes I know it would only display one fault at a time but they can be organized hierarchically.

I have used this before, but i did implement in function block which made the code much neater. 1 large AND block for the permissive with a not off each input enabling move instructions to load the string

Another advantage of the text method is it really self documents the plc code.

Not sure what your using or how many conditions you have. We use Iconics Genesis. When you hover the mouse on equipment that is down, a pop up box lists all the critical I/O with the status bit so you can immediately see if it's a photo eye jammed, motor fault, safety pull, etc. There is one file in each PLC5 that is just for the HMI bits.
There is also a scrollable fault list at the bottom that lists faults as they occur and removes them as they are cleared. The items at fault also flash in red on the display. If your HMI allows scripts you could enable a message box on mouse hover.