# Tag Timestamping and Scan Times **URL:** \ **Category:** Ignition\ **Created:** [December 22, 2022, 9:28am UTC](https://forum.inductiveautomation.com/t/tag-timestamping-and-scan-times/67912 "2022-12-22T09:28:56Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![coffee732](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@coffee732](https://forum.inductiveautomation.com/u/coffee732)\ **Post date:** [December 22, 2022, 9:28am UTC](https://forum.inductiveautomation.com/t/tag-timestamping-and-scan-times/67912/1 "2022-12-22T09:28:56Z")
Where can I find information on how Ignition gets tag data in relation to poll rates and scan times using it's own OPC server? Related to the above: I know Rockwell's FactoryTalk is capable of setting up a kind of 'subscription' to a Rockwell PLC, allowing for scan time levels of timestamping and alarm buffering with what's known as "FactoryTalk Alarms and Events". Is it possible for Ignition to interface with FactoryTalk to get this kind of detailed information? ---
**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:** [December 22, 2022, 1:40pm UTC](https://forum.inductiveautomation.com/t/tag-timestamping-and-scan-times/67912/2 "2022-12-22T13:40:31Z")
Rockwell does not publish or expose that protocol, and I don't know of anyone who has reverse engineered it. ---
**Author:** ![coffee732](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@coffee732](https://forum.inductiveautomation.com/u/coffee732)\ **Post date:** [December 22, 2022, 2:03pm UTC](https://forum.inductiveautomation.com/t/tag-timestamping-and-scan-times/67912/3 "2022-12-22T14:03:10Z")
So I am correct in saying that to utilise FT Alarm Events you need all 3: Rockwell PLC (PLC) Rockwell FTView Linx Gateway (OPC Server) Rockwell RSView (SCADA) You couldn't swap out the SCADA for Ignition and somehow get the info from the FTView OPC server for timestamps? ---
**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:** [December 22, 2022, 2:25pm UTC](https://forum.inductiveautomation.com/t/tag-timestamping-and-scan-times/67912/4 "2022-12-22T14:25:50Z")
Pretty sure not. @Kevin.Herron can correct me. FT Alarm Events is a technology introduced specifically to produce vendor lock-in to the FT vertical stack, in my not-so-humble opinion. It isn't that hard to use data structures to construct time-stamped event queues and pass those upstream to non-FT products. Some AOIs that implemented such would be the vendor-neutral approach. ---
**Author:** ![coffee732](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@coffee732](https://forum.inductiveautomation.com/u/coffee732)\ **Post date:** [December 22, 2022, 2:33pm UTC](https://forum.inductiveautomation.com/t/tag-timestamping-and-scan-times/67912/5 "2022-12-22T14:33:08Z")
Understood. Creating AOI's with timestamps isn't an issue. Is there a way for Ignition's inbuilt alarm handler to accept an external timestamp rather than rely on when it gets it the data from the OPC server? ---
**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:** [December 22, 2022, 3:09pm UTC](https://forum.inductiveautomation.com/t/tag-timestamping-and-scan-times/67912/6 "2022-12-22T15:09:09Z")
Yes, via scripting, presuming each alarm is on its own triggering tag. When writing to a tag, instead of writing a bare value, which then gets good quality and the current timestamp, you can instead write a manually constructed `QualifiedValue` with your desired timestamp. I believe that will enter the alarm journal correctly. (It does work with general tag history.) ---
**Author:** ![coffee732](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@coffee732](https://forum.inductiveautomation.com/u/coffee732)\ **Post date:** [January 3, 2023, 2:41pm UTC](https://forum.inductiveautomation.com/t/tag-timestamping-and-scan-times/67912/7 "2023-01-03T14:41:07Z")
The below successfully writes values out to 2 tags I created, (alarm boolean status and a tag to display the LINT as DateTime), but the actual timestamps on the tags and the Active Time in the alarm window still use the system time. Any pointers? ``` from com.inductiveautomation.ignition.common.model.values import BasicQualifiedValue as qv, QualityCode as qc if currentValue.value != previousValue.value: #Tag Paths AlmTagPath = tagPath + "_Alarm" PLCTimePath = tagPath + "_Time" AlmTimePath = tagPath + "_Alarm_New_Time" #PLC's Timestamp readPaths = [PLCTimePath] PLCTimeVal = system.tag.readBlocking(readPaths) #Tag Values PLCTagVal = currentValue.value AlmTimeMills = int(PLCTimeVal[0].value / 1000) PLCTime = system.date.fromMillis(AlmTimeMills) #Fully Qualified Values AlmTagVal = qv(PLCTagVal, qc.Good, PLCTime) AlmTimeVal = qv(PLCTime, qc.Good, PLCTime) #Write out to Alarm Tag and PLC Timestamp Tag writePaths = [AlmTagPath, AlmTimePath] writeVals = [AlmTagVal, AlmTimeVal] system.tag.writeBlocking(writePaths, writeVals) ``` ---
**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:** [January 3, 2023, 2:48pm UTC](https://forum.inductiveautomation.com/t/tag-timestamping-and-scan-times/67912/8 "2023-01-03T14:48:31Z")
My recommendation only applies to memory tags. OPC tags always get their information from the OPC server. Many drivers leave timestamp management to the server, which will then always use its time. ---
**Author:** ![coffee732](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@coffee732](https://forum.inductiveautomation.com/u/coffee732)\ **Post date:** [January 3, 2023, 2:50pm UTC](https://forum.inductiveautomation.com/t/tag-timestamping-and-scan-times/67912/9 "2023-01-03T14:50:05Z")
The tags I'm writing to in the script are both Memory Tags. ---
**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:** [January 3, 2023, 2:53pm UTC](https://forum.inductiveautomation.com/t/tag-timestamping-and-scan-times/67912/10 "2023-01-03T14:53:32Z")
Hmmm. Might need to get support involved. I expected that to work. ---
**Author:** ![coffee732](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@coffee732](https://forum.inductiveautomation.com/u/coffee732)\ **Post date:** [January 4, 2023, 1:21pm UTC](https://forum.inductiveautomation.com/t/tag-timestamping-and-scan-times/67912/11 "2023-01-04T13:21:52Z")
Update: I noticed that the script wasn't firing when I tried to set the timestamp to a date the past. wrapper.log was displaying errors regarding the historian. In the Gateway, I had the Realtime tag provider advanced option 'Allow Back-fill Data' checked, I unchecked this and the script successfully executed with the Timestamp on the data being the custom 'in the past' timestamp, but the Alarm was still coming in with the current timestamp. On the Alarm I changed the Timestamp Source from 'System', to 'Value'. The Alarm then came in using the custom timestamp.