Hi All
I might be involved in some project where conveyor is involved which falls into category of real time control. Obviously in this case if we don’t process signals fast enough and on time it will not work. This is different to batch control where we process things periodically and processing on time is not critical.
What are good practices and pitfalls to avoid? Please comment on any of the points below and and new thoughts. Real time programming is quite challenging. Let’s assume we are running the gateway or reasonable hardware ie. 20core server with ample memory.
1 If my project is on the gateway where there are already 2 other projects doing different
part of the solution- can this 2 projects bring performance of my project to a halts or
slow it down dramatically if they are doing time consuming queries or something silly
like time.sleep?
2 When running my project what are the things to be avoided apart from time.sleep? I
guess long SQL queries behind gateway event if the event is configured as using the
same thread is a bad practice? Should gateway events be running on the separate
threads in most cases?
3 How bad is actually time.sleep command ? Apart from freezing GUI can it freeze other
parts of the Ignition.
4 Are there any commands which can freeze processing IO ? this would be really bad
for control
5 In general what are components of Ignition needed to be analysed in Real time programming - transaction manager, SQL bridge? etc what module is processing IO?
6 How shall i measure if my performance is good enough ? is writing timestamps to the
internal tags for monitoring and checking how long things take a good idea or are there
better metrics?
7 Are NUMA principles supported by Ignition - fully or partially? eg. can ignition be
dedicated to specific cores on the server?
8 Any good resources for further reading on this either from ignition or the third party?
I know i asked a broad question but please comment on any part, add any new thoughts and by all means correct if I am wrong
Java is not made for real-time control. It is a garbage-collected interpreted environment that often experiences complete (all threads) stalls to manage memory (aka "pause the world"). Its GC methods have gotten much better in the past several years, where the stalls can be a few dozen milliseconds instead of multiple seconds, but even that will break many control latency requirements.
That said, your points:
Yes, multiple projects will compete for resources.
Dedicated threads help, but proliferating threads will also compete for resources.
Any form of sleep ties up a thread. If the thread is shared with other tasks (in a thread pool executor, perhaps--very common in the gateway), those other tasks will be impeded. Numerous cases in this forum of people freezing their entire tag system.
Sure. Any thread can ask the JVM to do a GC pass on demand. That can halt everything. But note that the Ignition platform doesn't do any of its own I/O. It delegates to OPC connections and drivers.
Any module can do anything. There's no way to analyze any of it.
java.lang.System.nanoTime() is the best available instrumentation for time.
I agree that PLC are meant to be used for real time control but Ignition is not only HMI for display bur SCADA capable of control. PLC have cycle times really fast in milliseconds or even faster but I am trying to gauge if ignition could cope with control where responses in the region of several hundreds of milliseconds are still ok? Or due to garbage collections even that might be aT risk? I am talking about situation where control is not safety critical. @pturmel - if you have any final thoughts on this you are always welcome to comment
I have deployed Ignition a few times where it was closely tied to the controls and performed ~100ms data collection for large numbers of data points. You can run a gateway event script at 100ms or even 50ms and have it perform logic as if it was a periodic PLC task. It will have more jitter than a PLC. GC can be configured to spend extra CPU to keep stalls to a minimum, also in the 50ms to 100ms range. So at that level, it is doable.
Once you choose to do such a thing, you will then be constrained on how you actually communicate with your I/O. Standard request/response OPC drivers in subscription mode are not well suited to such traffic, because you really need to write your control values every cycle, and TCP/IP has terrible semantics for that. A UDP socket with a custom, repeating payload would be a better choice.
My Ethernet/IP module exists for a reason. I wouldn’t do any of the above with a lesser protocol.
So it sounds like you don’t actually need “real time” control. Personally, I’d think even a cheap PLC would be better for you, since virtually any PC is going to be inherently less reliable, but it sounds like you might be able to get away with doing the logic in Ignition. Still, this is one of those cases where there’s a big distinction between what you can do and what you should do…
