# real-time timestamps

**URL:** <https://forum.inductiveautomation.com/t/real-time-timestamps/22928>\
**Category:** General Discussion\
**Tags:** ignition79\
**Created:** [February 27, 2019, 3:00pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928 "2019-02-27T15:00:18Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![bygryapg](https://avatars.discourse-cdn.com/v4/letter/b/cab0a1/32.png) [@bygryapg](https://forum.inductiveautomation.com/u/bygryapg)\
**Post date:** [February 27, 2019, 3:00pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/1 "2019-02-27T15:00:18Z")

</div>

Hi there!  
Is Ignition a real-time control system?  
If so, how is this implemented?  
I do not understand what is the speed of obtaining timestamps…

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [February 27, 2019, 3:48pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/2 "2019-02-27T15:48:11Z")

</div>

I suppose it depends on your definition of “real-time”.

It’s hard to answer your question without more details. In the most common case, data points are polled from PLCs at some rate defined in Ignition and the timestamps are applied to those values as they are received. This is a bit of a simplification of how things work but without a better question I’m not sure it’s worth going into.

---

<div class="post-metadata">

**Author:** ![zxcslo](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zxcslo/32/61610_2.png) [@zxcslo](https://forum.inductiveautomation.com/u/zxcslo)\
**Post date:** [February 27, 2019, 5:19pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/3 "2019-02-27T17:19:25Z")

</div>

Ignition is **not** Real Time control system.  
Real-Time timestamps come from [Controler](https://www.controleng.com/articles/fundamentals-of-real-time-processing-in-automation-and-control/).  
(also, PLCs are NOT Real-Time Controllers).  
Real-Time timestamp means the actual time, when the signal change occurred, not when the value was registered.

---

<div class="post-metadata">

**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:** [February 27, 2019, 6:09pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/4 "2019-02-27T18:09:44Z")

</div>

> [@bygryapg](#):
>
> Is Ignition a real-time control system?

No. Not by any definition I've ever encountered.

> [@bygryapg](#):
>
> I do not understand what is the speed of obtaining timestamps…

Pretty much every timestamp that Ignition generates uses millisecond _ **resolution** _. However, due to java garbage collection and the lack of priority configuration, the best _ **accuracy** _ you can expect is a few tens of milliseconds, after spending considerable effort and using superior hardware. Otherwise, you'll probably do no better than the low hundreds of milliseconds, and occasionally, \>1000ms.

---

<div class="post-metadata">

**Author:** ![bygryapg](https://avatars.discourse-cdn.com/v4/letter/b/cab0a1/32.png) [@bygryapg](https://forum.inductiveautomation.com/u/bygryapg)\
**Post date:** [February 27, 2019, 6:37pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/5 "2019-02-27T18:37:37Z")

</div>

Ok. Then I do not understand what is meant by “Real-Time Historical Data”?

---

<div class="post-metadata">

**Author:** ![ethomason](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ethomason/32/43338_2.png) [@ethomason](https://forum.inductiveautomation.com/u/ethomason)\
**Post date:** [February 27, 2019, 6:43pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/6 "2019-02-27T18:43:18Z")

</div>

What is the context? These are 2 different things - real-time data is what is happening right now and historical data is what has happened previously.

---

<div class="post-metadata">

**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:** [February 27, 2019, 6:53pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/7 "2019-02-27T18:53:24Z")

</div>

Real-Time _ **Control** _ has a very specific engineering meaning: response time to control inputs has a provable upper limit in a specific system. Modern Real Time Control **_Systems_** generally guarantee very short latencies, like, often measured in _microseconds_, from an input signal change to the corresponding output signal change.  
Real-Time _ **Data** _ is simply regularly updating readings of specific signals from a control system, typically with adjustable pacing. In Ignition, each individual signal (tag) is assigned a pace (read interval) via a _scan class_.  
Historical Data is simply recordings of the above Real-Time Data, not necessarily at the same pace as originally read, and possibly skipping or statistically compressing unchanging values.

---

<div class="post-metadata">

**Author:** ![bygryapg](https://avatars.discourse-cdn.com/v4/letter/b/cab0a1/32.png) [@bygryapg](https://forum.inductiveautomation.com/u/bygryapg)\
**Post date:** [February 28, 2019, 9:04am UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/8 "2019-02-28T09:04:33Z")

</div>

That’s great! Came closer to scan class… But the Ignition works on Java’s virtual machine… I understand correctly, don’t I? The ignition is not embedded in the core of the operating system?

Perhaps I do not know the specifics of the communication drivers, perhaps the Ignition records an archive of events regardless of the execution cycle of the program itself on the virtual machine. Please explain.

In the INDUCTIVE AUTOMATION work package, I see projects in the food processing, construction materials, petrochemical industry. But what could push the **engineers** to **approve** such a project I do not understand.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [February 28, 2019, 12:24pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/9 "2019-02-28T12:24:53Z")

</div>

What projects of yours do you think have such hard real-time requirements and what other software packages are you under the impression meets those requirements?

---

<div class="post-metadata">

**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:** [February 28, 2019, 1:57pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/10 "2019-02-28T13:57:27Z")

</div>

> [@bygryapg](#):
>
> But the Ignition works on Java’s virtual machine… I understand correctly, don’t I? The ignition is not embedded in the core of the operating system?

Correct. Ignition is not a real-time control system because Java does not provide any response time guarantees. Nor do the operating systems it runs on.

> [@bygryapg](#):
>
> perhaps the Ignition records an archive of events regardless of the execution cycle of the program itself on the virtual machine

No. If anything in the JVM or the OS delays a device read that Ignition is doing, then there will be jitter. And there is always some jitter. And if the delays pile up, you can miss an interval.

If you must record precise timestamps, code in the origin device (PLC) is usually needed, along with precision clock synchronization. Ignition can read the captured timestamps as regular data, as long as the corresponding events don't happen too fast for the OPC driver to keep up. All of this is non-trivial.

---

<div class="post-metadata">

**Author:** ![bygryapg](https://avatars.discourse-cdn.com/v4/letter/b/cab0a1/32.png) [@bygryapg](https://forum.inductiveautomation.com/u/bygryapg)\
**Post date:** [February 28, 2019, 2:17pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/11 "2019-02-28T14:17:01Z")

</div>

I’m actually talking about soft real-time control systems.

In the Ignition, I’m concerned about the fact that with a PLC scan cycle \<50ms, (e.g. Siemens S7-416 CS Brewmaxx/ProLeit) in conjunction with OPC, the Ignition can skip a series of events.  
Brewmaxx/ProLeit somehow negate it, and logging comes with a timestamp accuracy of \<100ms. It works all on WinServer2003 with not the most productive hardware.

Began to understand and then came across You 🙂

On systems that have met: Ammann 2000 Plus control system asphalt plant (QNX), DeltaV, is another story 🙂 , RSU oil terminal (WinServ2003). Brewmaxx - brewery(WinServ2003). ProLeit-milk factory (WinServ2003). Intouch + Historian - through OPC but you can configure \<10ms.

---

<div class="post-metadata">

**Author:** ![bygryapg](https://avatars.discourse-cdn.com/v4/letter/b/cab0a1/32.png) [@bygryapg](https://forum.inductiveautomation.com/u/bygryapg)\
**Post date:** [February 28, 2019, 2:18pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/12 "2019-02-28T14:18:12Z")

</div>

> [@pturmel](#):
>
> And if the delays pile up, you can miss an interval.

That's what I meant.

---

<div class="post-metadata">

**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:** [February 28, 2019, 2:24pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/13 "2019-02-28T14:24:54Z")

</div>

You might find my [Ethernet/IP Class1 Communication](https://inductiveautomation.com/moduleshowcase/module/automation-professionals-llc-ethernetip-class-1-communications) driver interesting. Won’t help you with Siemens hardware, though.

All of the above running on Windows, unless they use a real-time shim in place of its normal HAL, are not really guaranteeing \<100ms accurracy. But they achieve it to four or five nines, and it isn’t in the control loop, so no one really cares about a rare skip.

---

<div class="post-metadata">

**Author:** ![bygryapg](https://avatars.discourse-cdn.com/v4/letter/b/cab0a1/32.png) [@bygryapg](https://forum.inductiveautomation.com/u/bygryapg)\
**Post date:** [February 28, 2019, 2:34pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/14 "2019-02-28T14:34:03Z")

</div>

Siemens Drivers-module.modl

And this driver it uses to connect? PG interface?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [February 28, 2019, 2:35pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/15 "2019-02-28T14:35:30Z")

</div>

> [@bygryapg](#):
>
> And this driver it uses to connect? PG interface?

Ignition's Siemens driver uses the "PC/Other" interface. It's not currently configurable to use anything else.

---

<div class="post-metadata">

**Author:** ![chi](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@chi](https://forum.inductiveautomation.com/u/chi)\
**Post date:** [February 28, 2019, 3:06pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/16 "2019-02-28T15:06:32Z")

</div>

> [@bygryapg](#):
>
> Intouch + Historian - through OPC but you can configure \<10ms

You might be able to _configure_ 10ms, but that does not guarantee that you receive an actual value every 10 ms. Like others already mentioned in this thread, there are a lot of factors to consider, like network delays, operating system delays, hardware overload, time synchronisation...,  
To put it short, there is no SCADA system i know that can guarantee a sampling time.  
If you can not accept a data loss, you have to program data acqusition and buffering in a real-time task in the controlling plc. Then use a handshake mechanism to transfer the data to your SCADA system. To qoute pturmel: **This is not trivial** and you won't get it out of the box with any SCADA.

> [@bygryapg](#):
>
> But what could push the **engineers** to **approve** such a project I do not understand.

I don't think that any engineer would come up with the idea to use a SCADA as a real-time **control** system.

---

<div class="post-metadata">

**Author:** ![bygryapg](https://avatars.discourse-cdn.com/v4/letter/b/cab0a1/32.png) [@bygryapg](https://forum.inductiveautomation.com/u/bygryapg)\
**Post date:** [February 28, 2019, 3:27pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/17 "2019-02-28T15:27:39Z")

</div>

I raised the question about the accumulation of historical data in real time. I apologize for off topic. And of course this SCADA operational control, nothing more.

---

<div class="post-metadata">

**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:** [February 28, 2019, 3:47pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/18 "2019-02-28T15:47:41Z")

</div>

> [@bygryapg](#):
>
> I apologize for off topic.

You don't have to apologize, in part because it's not off-topic. Ignition and other SCADA systems aren't real-time control systems -- not even soft real-time control -- but SCADA systems _ **are** _ supervising real-time control systems. PLCs are real-time control systems, after all. Latency guarantees keep getting tighter, but even 1970's era PLCs would _ **reliably** _ read their inputs, run their scan, and set their outputs in a bounded number of milliseconds. They couldn't do much in that scan, but they'd do it every time.

You just started your topic with a confusing collection of engineering terms.

---

<div class="post-metadata">

**Author:** ![bygryapg](https://avatars.discourse-cdn.com/v4/letter/b/cab0a1/32.png) [@bygryapg](https://forum.inductiveautomation.com/u/bygryapg)\
**Post date:** [March 1, 2019, 8:30am UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/19 "2019-03-01T08:30:05Z")

</div>

Okey. Back to top.

I’m afraid I do not have enough English to describe the operation of the data archiving system in InSQL, DeltaV or OSI PI. Judging by the drivers you have an idea about these systems.

So my question is:  
what are the means of collecting, compressing, archiving real - time data coming from PLC? In what format is this data stored? That’s what I meant when I asked about the real-time system, meaning that **Ignition** is a **SOFTWARE**  **complex**.

API/SDK?

Thanks for your patience. 🙂

---

<div class="post-metadata">

**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:** [March 1, 2019, 1:02pm UTC](https://forum.inductiveautomation.com/t/real-time-timestamps/22928/20 "2019-03-01T13:02:06Z")

</div>

There’s a whole [section of the manual](https://docs.inductiveautomation.com/display/DOC79/Historian) describing the historian. Ignition’s tag historian only does very limited compression, using a linear extrapolation algorithm that I can’t find right now. The SQL Bridge’s transaction groups do no compression at all.

[Next page](https://forum.inductiveautomation.com/t/real-time-timestamps/22928.md?page=2)