# Ignition and real time control - what pitfalls to avoid and what are good practices **URL:** \ **Category:** Ignition\ **Created:** [June 16, 2022, 9:36am UTC](https://forum.inductiveautomation.com/t/ignition-and-real-time-control-what-pitfalls-to-avoid-and-what-are-good-practices/60822 "2022-06-16T09:36:14Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![hewking32](https://avatars.discourse-cdn.com/v4/letter/h/b5ac83/32.png) [@hewking32](https://forum.inductiveautomation.com/u/hewking32)\ **Post date:** [June 16, 2022, 9:36am UTC](https://forum.inductiveautomation.com/t/ignition-and-real-time-control-what-pitfalls-to-avoid-and-what-are-good-practices/60822/1 "2022-06-16T09:36:14Z")
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 🙂 ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [June 16, 2022, 11:00am UTC](https://forum.inductiveautomation.com/t/ignition-and-real-time-control-what-pitfalls-to-avoid-and-what-are-good-practices/60822/2 "2022-06-16T11:00:43Z")
> [@hewking32](#): > > What are good practices Don't. Really. 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: 1. Yes, multiple projects will compete for resources. 2. Dedicated threads help, but proliferating threads will also compete for resources. 3. 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. 4. 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. 5. Any module can do anything. There's no way to analyze any of it. 6. `java.lang.System.nanoTime()` is the best available instrumentation for time. 7. Ignition is oblivious to NUMA concerns. Good luck. ---
**Author:** ![hewking32](https://avatars.discourse-cdn.com/v4/letter/h/b5ac83/32.png) [@hewking32](https://forum.inductiveautomation.com/u/hewking32)\ **Post date:** [June 16, 2022, 12:15pm UTC](https://forum.inductiveautomation.com/t/ignition-and-real-time-control-what-pitfalls-to-avoid-and-what-are-good-practices/60822/3 "2022-06-16T12:15:45Z")
Phil thank you a lot for your thorough reply. Ps. I started to read your old posts as they are very educative. You have a true passion for the automation 🙂 ---
**Author:** ![witman](https://avatars.discourse-cdn.com/v4/letter/w/d2c977/32.png) [@witman](https://forum.inductiveautomation.com/u/witman)\ **Post date:** [June 16, 2022, 2:53pm UTC](https://forum.inductiveautomation.com/t/ignition-and-real-time-control-what-pitfalls-to-avoid-and-what-are-good-practices/60822/4 "2022-06-16T14:53:09Z")
As @pturmel said; don’t. You want a PLC for the real-time control. Use Ignition as the operator interface. ---
**Author:** ![hewking32](https://avatars.discourse-cdn.com/v4/letter/h/b5ac83/32.png) [@hewking32](https://forum.inductiveautomation.com/u/hewking32)\ **Post date:** [June 16, 2022, 11:00pm UTC](https://forum.inductiveautomation.com/t/ignition-and-real-time-control-what-pitfalls-to-avoid-and-what-are-good-practices/60822/5 "2022-06-16T23:00:46Z")
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 🙂 ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [June 17, 2022, 1:45pm UTC](https://forum.inductiveautomation.com/t/ignition-and-real-time-control-what-pitfalls-to-avoid-and-what-are-good-practices/60822/6 "2022-06-17T13:45:12Z")
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. ---
**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\ **Post date:** [June 17, 2022, 2:14pm UTC](https://forum.inductiveautomation.com/t/ignition-and-real-time-control-what-pitfalls-to-avoid-and-what-are-good-practices/60822/7 "2022-06-17T14:14:34Z")
I agree with @pturmel and @witman, use a PLC. ---
**Author:** ![Joe\_Chlimoun](https://avatars.discourse-cdn.com/v4/letter/j/54ee81/32.png) [@Joe\_Chlimoun](https://forum.inductiveautomation.com/u/Joe_Chlimoun)\ **Post date:** [June 17, 2022, 4:17pm UTC](https://forum.inductiveautomation.com/t/ignition-and-real-time-control-what-pitfalls-to-avoid-and-what-are-good-practices/60822/8 "2022-06-17T16:17:36Z")
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…