nanaxpuzzle.blogg.se

1. #HOW TO TEST SCREEN WITH CITECT HOW TO#
2. #HOW TO TEST SCREEN WITH CITECT SERIAL#
3. #HOW TO TEST SCREEN WITH CITECT FULL#
4. #HOW TO TEST SCREEN WITH CITECT CODE#

High performance HMI is about effective information presentation. 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). It may be more of a positive first impression thing which has its own value in OEM equipment.

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. 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. 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. 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. A certain amount of this can be standardized in RSLogix AOIs, but there are always unique cases that require their own unique logic.ĭynamic 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. We then use those bits to show the diagnostic information in the HMI. 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. If issue y may be caused by issue x, the HMI shouldn’t show even show issue y until issue x is resolved. Otherwise they’ll commonly spend a bunch of time trying to resolve fault/interlock y when the root issue is fault/interlock x. 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). 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.

#HOW TO TEST SCREEN WITH CITECT FULL#

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). 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. The more details we can give them in the HMI, the less they’ll call us for support!

Knowing why something won’t run is important to operators. Has anyone realize the idea in you software? What’s the way you do?

It’s great idea, but not the simplest way, I reckon. 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. I am currently working on a client Citect system, it’s using a predefined excel workbook for each devices (valve, pumps). It’s not just limited to Interlocks, but also permissive, unit healthy signals or any signal which is concluded from other conditions. 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.

#HOW TO TEST SCREEN WITH CITECT CODE#

#HOW TO TEST SCREEN WITH CITECT SERIAL#

The condition could be combination of serial or parallel connections. 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.

#HOW TO TEST SCREEN WITH CITECT HOW TO#

Since 10 years ago, I was questioned by end clients (internal/external) about how to detail the trigger conditions of interlock/permissives.