Here is the story:
Since 10 years ago, I was questioned by end clients (internal/external) about how to detail the trigger conditions of interlock/permissives. For example, the heater is interlocked by a serial of conditions, like, tank level low, flow switch off, downstream valve open, or perhaps even the interlocks from other units. The condition could be combination of serial or parallel connections. Usually, I will just display one label on the HMI/SCADA screen to indicate interlock is Active when it’s triggered, but the operator wants to know more about which condition is triggering the interlock
With the old SCADA/HMI software, it’s difficult/troublesome to detail the conditions, so I always so “No, ready the manual”. But I am not sure, with Ignition, whether it can be done in a easier way?
Ways that I can think of are:
Define the logic in PLC code and Ignition visualizes the logic on Ignition screen in a way of charts or predefined describable words.
Define a pattern in PLC, but no specific logic for each interlock. Then predefine a table from Ignition, so the process engineer can enter the interlock condition from Ignition screen, and the condition will automatically generate the logic in PLC.
It’s not just limited to Interlocks, but also permissive, unit healthy signals or any signal which is concluded from other conditions.
I am currently working on a client Citect system, it’s using a predefined excel workbook for each devices (valve, pumps). In the workbook, it has a sheet for the interlocks, once the engineer enters the interlock condition detail in this excel sheet, it will then show up the interlock status and description on the Citect device faceplate, also the operator can click on the interlock to navigate to the place whether the interlock condition is triggered. It’s great idea, but not the simplest way, I reckon.
Has anyone realize the idea in you software? What’s the way you do?
Knowing why something won’t run is important to operators. The more details we can give them in the HMI, the less they’ll call us for support!
Ideally, HMI signals to operator the specific interlock(s) that aren’t met when they are trying to run something that is prevented by interlocks. I prefer showing them only the relevant issues to showing them the logic–or even a full list of interlocks (including the ones that are met). For example, if E-Stopped I/O power is off and E-Stopped I/O power is taken from I/O power that isn’t E-Stopped and is also off, the fault/notification for E-Stopped I/O power off is only shown if we’re not also showing a fault for regular I/O power off. The idea is to shown them the specific issue(s) they should address first, and hide the dependent issues that may be resolved by resolving the first issue(s). Otherwise they’ll commonly spend a bunch of time trying to resolve fault/interlock y when the root issue is fault/interlock x. If issue y may be caused by issue x, the HMI shouldn’t show even show issue y until issue x is resolved.
I’d be interested in a better way, but at this point we put the logic in the PLC for these conditions and map it to bits. We then use those bits to show the diagnostic information in the HMI. A certain amount of this can be standardized in RSLogix AOIs, but there are always unique cases that require their own unique logic.
How do you deal with the various type of interlock bits and description to be displayed on SCADA screen?
Do you enter them manually for each condition while you are configure the faceplates or do you generate a standard table so you can allow the process/commissioning engineer to enter them when the HMI/SCADA is running? If you enter the description/tags while HMI/SCADA is running, do you have some scripting at the background running to look for specific tag in PLC as per the tag addresses you entered from SCADA screen.
I always want to add more details to the SCADA screen so the end user can better understand the software. But just like another general request, the dynamic piping function (displaying pipe color in different way when there’s flow/no flow going through it), I haven’t figure out a generic/simpler way of doing it of 100% correctness, so I prefer not to do it at current stage until I figure out a way to standardize the coding for this function.
I'm fairly confident the answer to this is no. However, someone really ambitious could probably write one to interpret an L5K file and display it graphically. It sounds cool, and I'd enjoy the challenge if it was going to be useful, but I wouldn't have a use for it.
Although there are exceptions, I've found the typical operator knows nothing about PLC code. And this includes some really good operators. Instead of showing them PLC code, the goal is to present them with the information they need/want to maximize productivity in an intuitive way that doesn't require explanation. Although not a perfect analogy, think something between a P&ID, a good mobile app, and a video game. Done well, this is more work to program, but less work to train and operate.
Yes, doing this can be a bit of a pain. I'll typically represent pipes with simple lines and then overlay those with lines in another colour that are hidden except when material is flowing. It's reasonably quick and effective in showing at a glance what is flowing and what isn't--at least for things that flow in only one direction.
When the client wants it, it's a little more work to make really cool looking 3D piping with "bubbles" moving through it to show flow. My kids loved those projects (and they get positive feedback from most people who see them), but I'm not sure they really help operators. It may be more of a positive first impression thing which has its own value in OEM equipment. As a counterpoint, there's value to the high performance HMI theory, though I think the initial take on it I saw years ago was a little bit oversimplified (perhaps to make it more accessible). High performance HMI is about effective information presentation. That overlaps with good graphic design. With a deeper understanding of the latter, high performance HMI doesn't have to be ugly or eye-straining.
We developed a standardized way to present this information in a previous SCADA package and duplicated it in Ignition. It is manually entered when programmed. Each logical piece of equipment such as a feeder, or a group of transfer conveyors, gets a DINT of bits we use as many as required--and even a second DINT on rare occasion--to set related fault messages from PLC code. In the HMI, we had a text file for each group listing bits and descriptions and a template that pulled these in for display and matched them up with the bits in the DINT tag linked to the template. We replaced this with datasets in Ignition, with additional columns for additional translations. I've considered making these runtime editable. When the DINT is not zero, the group name lights up in a "faults" sidebar. Tap on that and you see the descriptions for all non-zero bits lit up. We've added additional functionality over time, and it works well. However, we've been moving towards showing fault tags (more like the high performance HMI idea) right next to the affected device/equipment that show when there's a fault and show more details on mouseover/tap. It's more intuitive as it's visually tied to the affected device, rather than tied by a name.
However you do it, it's work to do well, but if you have a standardized system to display it you save a lot of time and reduce errors.
I like the Citect project that I am working on at the moment. The software was built about 15 years ago, and it’s really programmed well that it presents a lot of detail information, like each interlock/permissive and unit healthy check conditions. You can also click on each condition description to navigate to the actual device faceplate. Also it developed a graphic to display the sequence like the FBD in Ignition. But the downside is it take a lot of effort to build the structure/programming procedure and it’s quite a steep learning curve for the other programmer to understand and modify the code (tons of scripting running at the background).
The new PlantPAX library is going this way, I reckon, like when you open the device faceplate you can choose to allow operator to navigate the the interlock/permissive subpage and type in the description yourself.
But the PlantPAX is too complicated, never like it since it was launched years ago.
That’s why I am thinking what’s the better way that Ignition can do with its better scripting functions and software structure.
If any of these were dependant on each other, the PLC logic would show only the parent fault when both were active. For example let's say Device X is a pump without which there's no flow. In this case, the flow switch off fault/message bit would only be set if the flow switch is off AND the pump is running.
Yes, Citect was a really cool package years ago. Last I checked there hadn't been a lot of significant development since Schneider bought it and I'd hate to go back to it from Ignition.
You raise a lot of good points. I come from an operations background and always try to design from an operator's perspective, rather than an engineer's. It generally means more work programming and less work operating... I guess I like punishment given which end of that I work on now.
With any new feature, I seek standardization as it really cuts down on development time in the long run. Presently, I can't think of a more effective way to show interlock type information than simple text descriptions telling the operator in a few words what I'd tell them if they called me asking why it wouldn't run. This isn't too painful to implement in the HMI if you have a standard template to display the information so all you have to do is type in the lines for each condition and link it to a PLC tag that connects them to the logic behind the conditions. A lot of the PLC logic ends up in standardized AOIs, so the actual unique stuff isn't too excessive.
Ignition is vendor neutral as far as PLC's are concerned so the control system design such as ladder logic/FBD of PLC's is out side of its scope as it varies from PLC to PLC. Though its possible to represent the logic diagrams on vision/perspective screens and animate them based on status of IO tags in OPC such as contact status, timers, flipflops etc. Additional tags may have to be defined for internal logical conditions in PLCs, to be able to see intermediate conditions such as permissives etc., if the effort is going to be worth the trouble.
I guess the PLC vendors may offer some tools that let you visualize the logic for debugging or trouble shooting in online mode, but I guess they may work only in local mode when connected locally to the PLC on a serial/Ethernet port.
The code in a Logix PLC is compiled to a proprietary form that varies by version. Only Rockwell would be able to do this. And did, actually–I remember an ActiveX that could be dropped into a Windows-based UI to show a single rung of logic to the user, animated live like in RSLogix. I never saw it deployed–operators just aren’t the target audience for actual ladder logic.
It was once possible to do this with RSLadder and RSView. And I found it quite useful but I have not seen a similar product since.
I often represent interlocks on a screen with more details in the mouseover text for those who want more detail. The screen is far too busy to represent every conditional bit individually. I’m interested to see what others may be doing.
The dynamic piping is another task I would to work on.
There are many projects I saw people doing the dynamic piping. It is all done in a way of test/fail/correct to eventually make it 100% working, but it is just for that project, you will have to start over again for new projects. I would prefer a way to use algorithm. It will be great if there is a standardized guideline or premade pipe that I just need to dumbly copy paste it with some simple configuration to make the flow path 100% correctly.
I tried to build a guideline myself many years ago, here is some thoughts to start with:
pump starts, flow starts
vlv open, flow path open
if feed pump suc pressure low, flow stop
if feed tank level (Source) low, flow stop
if divert valve changes position, flow changes flowpath.
flow is from higher pressure to lower pressure.
gravity works in its own way.
dead end stops flow.
backpressure can invert normal process flowpath.
I tried to use the above requirements to make a AOI, but still it is not 100% correct for any scenarios.
It will be great if anyone can share your experience on this issue.
I use a similar approach to the display of sequence information (sequence steps, run preconditions, engineering parameters), however I pull this info directly from our FDs that are written in a standardised way as to allow me to extract the information from them and import it into Ignition e.g. creating tags and populating string values and PLC addresses etc. I could also extract this from the PLC code itself, however it would be more effort as i'd need to manually export the routines to ASCI format first.
Either way is still semi-automatic, but still much faster than hand typing each one.
Yes, it is a much better and faster way of coding, once the procedure has been standardized.
I was using the similar way to populate the coding of the sequential model part (S88).
It all starts from a standardised FD with tables on detailed information on recipe, unit operation, operation, phase/steps, like the index, name, description, operation/step transition conditions and op/step transition result (what’s the next op/step to transit to). It is kind of like the RsBatch or ibatch system, but with more flexibility on the configuration of the steps from SCADA/HMI screen.
It took a couple of years to develop the system, with endless discussions with process engineers, but it eventually worked out pretty well.
The physical model of the S88 is all about the lib of CMs/EMs with faceplates/dynamos which I developed my own by utilizing some of good features from PlantPax and PCS7 with additional features for my particular process requirements.
The detailed interlocks display and dynamic piping feature that I mentioned above are the ones that I have been working since many years ago but haven’t yet standardized as part of my lib.
This requires some kind of standardisation for HMI convention by bodies like ISA or else each vendor will have his own Standard. But agreed that a genarilsed standardisation is difficult to define as it will run into 1000s of pages and will be difficult to implement as well by SIs.
I don’t feel that SCADA will ever be able to be standardised. There may be guidelines and frameworks that should be followed and used, but as far as the graphics are concerned, it’s like trying to standardise the look of houses; everyone will always have their own opinions on what looks good and what doesn’t. All houses may still follow the same design codes and building standards, but there will always be substantial differences in how they’re put together and finished.