Tag Timestamping and Scan Times

Ignition
1

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?

2

Rockwell does not publish or expose that protocol, and I don't know of anyone who has reverse engineered it.

3

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?

4

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.

5

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?

6

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.)

7

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)
8

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.

9

The tags I'm writing to in the script are both Memory Tags.

10

Hmmm. Might need to get support involved. I expected that to work.

11

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.

2 Likes