Over the last few weeks I’ve been on a journey trying to build skeuomorphic controls in Ignition that mimic as close as possible to the outlines of the physical controls that are supplied to me in the drawings from a client. The idea is to completely mimic local operator control panels, so that PLC code testing can be performed using the controls that an operator would see in real life. Without such a resource you are left to forcing bits in the PLC to simulate when an operator pushes a physical button.
And as to why not test with the real machinery? Well in my case I am building large shipping port container cranes that are typically 100+ meters high to start with. The electrical design work is being done in country A, the physical construction and wiring is being done in country B, I’m working in one part of country C (and my colleagues work in another part) and the end customer could be anywhere globally in any country that has a container port - and the crane is delivered directly to them.
So I took the electrical drawings and made canonical versions of each different type of control, and made them fully customizable via parameter settings. I just instance them via embedded views, set the needed parameters and hook up the tags, and I have fully working operator controls that the end customer would immediatley recognize.
(Note that a lot of what I am doing involves momentary buttons that set/clear tags in the PLC depending on the mouse press. In my case this is a reasonable thing to do as I am doing testing/simulation only with these controls. Making momentary controls in any HMI system is fraught with danger, and doing so is not recommend!)
So here is a dump of my canonical controls:
This can be mitigated by using the same protocols and techniques that PLC vendors use for wiring real buttons and switches via ethernet remote I/O. You can make Ignition look like such remote I/O with a suitable module (ahem), allowing the training and testing to occur with unmodified PLC code and I/O configuration.
These look great! If you’re willing, they’d potentially make good Exchange resources. Or you could put the raw SVGs up on Github.
I’ll see about that after the talk I’m having tomorrow. I did this work in part to stretch my design skills, but also because I know my client has this genuine need. So up until now it is unpaid work. But if I get compensated for doing the design work, releasing it becomes a different conversation.
We are shifting to ProfiNet for remote I/O (except for the EGD based I/O that is still hanging around), so unless you have a full ProfiNet simulator that can suck down the same GSMDL files as we use for our PLCs, then I’m afraid we are stuck with modified PLC code.
But I still see the controls that use a maintained state being simulated in the PLC, because while the PLC may keep running all the time, it’s likely that the panel simulation HMI will only be spun up when needed (like I do, keeping it on a VM), so remembering that state becomes more complex (EG saving/recovering state data from an SQLite DB. It’s doable, but makes things a lot more complex)
Sigh. My condolences. (IMNSHO, that’s not a wise decision.)
Not going to happen. For both technical and commercial reasons:
ProfiNet I/O uses bare Ethernet frames with a custom protocol ID. Not router friendly. Not OS friendly in the common case (Windows blocks it for any but signed drivers) and absolutely not Java-friendly. By contrast, EtherNet/IP uses TCP and UDP (both accessible directly in java), and is perfectly happy to run on commodity hardware. Routable, too.
Siemens is inordinately proud of their intellectual property, to where casual/niche implementations are utterly out of financial reach. By contrast, an EtherNet/IP vendor pays $600 for an ID code, and $600 per year for the specification.
Memory tags, anyone? Also, an Ignition VM simulating a hardware panel will simply appear to be turned off when the VM is shut down. Any decent PLC programmer will include module status in their logic–status that I/O protocols provide by default.
You should ask my colleague about his efforts to get a PN/PN coupler running. PN isn’t our decision, we just run with what hardware we are given. And nobody tested this PN/PN coupler with Emerson PLCs before they specified it for the current job.
Are memory tags backed by by any sort of offline storage? You search for “Memory Tag” in the 8.1 documentation and you get nothing explaining what a memory tag actually is, or what properties/behavior it actually has.
The real PLC code is checking the ProfiNet status of the physical I/O. Given that I’m injecting simulated inputs into the PLC after the ProfiNet I/O scan, and can’t simulate the actual I/O we are using, for the sake of testing I’m streamlining the process and not doing anything that is not critical.
Yes. Their state is saved in the internal DB and restored on startup.
Oh, I understand. That’s one reason ProfiNet is a lame choice. My EtherNet/IP module can emulate pretty much any EtherNet/IP device out there.
If only I knew where that was defined in the documentation!
I’ll also rationalize my choice of saving the state information in the PLC by saying that given the way I designed the interface in the PLC to receive commands to go to state 1 or go to state 2 etc, the local panel simulation can be run from within the PLC simulation code itself without a need of an external HMI. Layering the HMI on tope of the simulation is just the icing in the cake!
Huh. I looked where I thought it would be and found nada. Looked some more and found nada.
Ought to be here:
@nminchin The Memory Tag page has now been updated to reflect that they are retained. The speed that the update was made will make for a good talking point tomorrow!
The state of memory tags are stored inside the gateway’s internal database. This allows the tag and its value to be retained across gateway restarts.
5 posts were split to a new topic: User Manual Changelog