How to set the Timestamp Source to Value on a tag, this option is available in Ignition 7.9 but I can not find how to do this using Ignition 8.
I need this option because alarm bits are timestamped by the PLC in our projects.
Kind regards,
Jan
Well, that’s a history-related setting, not the tag itself.
There’s 2 timestamps that might come with a value from an OPC server - “source” and “server”. OPC tags always get the “source” timestamp if defined and the “server” timestamp if not. Usually it’s the “server” timestamp, which in the common case with e.g. a polling-based driver is the timestamp at which it polled the value. “Source” timestamps are only used when there’s a possibility the device will send a timestamp along with a value.
Ok, I meant the history-related setting.
We use an additional OPC OFS of Schneider Electric for timestamped events, which is capable of sending the timestamp along with a value. This works perfectly for the alarm, but of course we would like to write the event to history with the same timestamp, so this state change can be use in graphs with together with other signals.
So still I can not find the setting in Ignition 8!
I’m not sure exactly how this works in 8 or what the equivalent is for history. I’ll have to ask around in a couple hours when more people are in the office.
any news about this item?
Hi,
Sorry for the delay- this setting was removed in 8 in an effort to start to reduce the multiple layers of timing definition and to get down to single sources of data.
The system timestamp only makes sense in situations where the system is scanning tags to collect values. In cases where the values are coming from the sources and being evaluated as they change, it makes sense to use the source timestamp.
So, we’ve made the logic that was previous driven by this setting more implicit. If the history is being collected “on change”, the value timestamp will be used. If the history mode is “tag group” or “periodic”, the system timestamp will be used.
I hope this helps. We’re open to refining the settings a bit more if necessary, and will be doing a little more work on tag history soon (for example, identifying and separating server-generated bad quality events from other quality events that come from the device).
2 Likes
the OPCDA server we have hooked up to ignition, TDS32 from ABB, exports TAGNAME and TAGNAME_TS on every value to provide an explicit timestamp on that tag. We need this for volume calculation tags so that we have the correct timestamp on the volume. It has nothing to do with when the value was polled, it comes from the device and is the timestamp on the calculation event. It has to be possible to combine these two tags into a tag with the value and the provided timestamp.
Hi!I am facing a problem of timestamp mismatch.The tag value is getting logged at a different time stamp in the historian but not the exact time at which it got executed.For instance if my tag’s last execution was at around 11:15 pm , the value corresponding to 11:15 pm is getting logged at 11:20 pm in my historian.Why is this happening?Is there any solution to this?Kindly help me out.
Tag Setting:
Sample mode : Periodic
Min time between samples :5 min
Max time between samples : 5 min (I want to log data for every five minutes)
The tag group base rate is also 5 minutes
1 Like
Hi Colby, maybe I did not properly understand your explanation: the “source” timestamp is NEVER used and this is a problem. I’m running in trouble (there is a ticket) because in case of “flushing” from an MQTT device all the message are getting the system timestamp instead of the source timestamp. In this situation the data becomes not useful at all (i.g. I could have a large number of pressure value related to the time of flushing…).
This is true in general and beyond MQTT flushing: the tag “on change” must be valued with the source timestamp if it is coming from an external source. Differently becomes not useful (i.e. in case of massive flushing) and in any case is not coherent (the data acquires the server timestamp instead of the correct one on the device).
As per your post, if the history trigger is not “on change” but it is “periodic”, in such a case makes sense to have the system timestamp. But only in this case.
So: is there a way to have the source timestamp in the history for the tags “on change”?
Thanks, Elio
Any resolution to this problem? I am having what I think may be a similar issue where I need to use the source timestamp value from the node instead of using the time of when the tag was actually updated in ignition.
For example: I want to update a memory tag on a “Value Changed” event from a different tag. When the (source) tag changes, the (target) memory tag’s timestamp becomes the current datetime. The problem is, the (source) tag could have been a delayed change as it is MQTT (latency, connection disruption, etc). I would like to be able to force the timestamp on the (target) memory tag so the historian will log the original timestamp.
We have the same problem and I brought it up with Ignition v.7 as well. Some of our customers want values to be stored in the historian at regular intervals, like every 10 seconds whether the value changed or not. But even in Ignition v7 you could not use the "value"/souce time stamp from the device and set the storage to the historian on scan class execution or any other specific time interval, it could only be "on change". And we can't use system time because after a period of time where we lose connection to a device, when connectivity is restored all the missed data then comes in with the current system timestamp which is completely unacceptable.
It has been a huge problem for us. We are planning to do a rewrite of our application and I was hoping Ignition v8 allowed for source timestamps that would be stored with scan class (now Tag Group) settings, but alas no. For this reason alone we may need to use something other than Ignition for our new application.