HMI Interlocks question (opinions wanted!)

[Merriman]

Hi all,

I'm currently programming several touch screen panels and I was wondering how detailed you get will the interlocks section (if applicable)?

As an example, one of my conveyors has 6 start permission bits and 2 run permission bits. 6 of these 8 bits are actually internal M-coils with their own start and run permissions. And so on, and so on. If I actually express the permissions in terms of only inputs and outputs, they become quite complicated. I want to be thorough, but at the same time I don't want the screen to be so complicated no one can read it.

I'm currently playing with the idea of restricting the screen to just the 'top' 8 permission bits and adding a touch animation. Touching description for one of the interlocks would make a text box pop up. This box would describe the permission bit and what - if its an M-coil - controls it. I could even make rungs of ladder logic pop up, if I get really ambitious.

Any comments/suggestions/other ideas/ridicule?

 

[SimonGoldsworthy]

My currrent solution for HMI (currently a PC) help messages is to use an FB with 1 action request input(typically a pushbutton),8 interlock inputs, 8 help bit in_outs and 1 action output. If all the interlock bits are true, then the action output will follow the action request. If any of the interlocks are false, the output will not energise and the help bits associated with the interlock bits come on for a time period (typically 10 secs) giving a context sensitive help message indicating why the particular action will not occur. If more than 8 interlocks are required, I just put more calls to the block and then 'or' the action outputs together to drive the Q that does the work.

 

[rdrast]

I'm not entirely sure which way you are looking at this... From an operator point of view, or a maintenance point of view.

For an operator, I normally use an open interlock to trigger a pop up window, with all possible reasons that the request can't be completed, defaulting to a dark grey color, and I highlight the ones that are actually preventing the request by changing their text to red.

The sequence from the operator as an example is either:
A) they press a start button, and something starts, OR
B) they press a start button, and a pop-up appears with the open interlocks highlighted, descriptive enough so they can correct the problem.

I only highlight the 'nearby' problems; that is, if a downstream system is required to be running, I say that. Then if there is a problem when they try to start the downstream system, a different message box pops up with different highlights.