We are connected to a 3rd party OPC-UA server that is communicating to vendor PLCs. The timestamp returned by their OPC-UA server is incorrect, currently it has the year as 2009. All the tags that are setup to historize are being collected in different sqlt_data table than the rest of the tags in the project. This causes the trending for the tags from the 3rd party OPC-UA connection in our power chart trend to not show data. We are currently using Ignition Version 8.1.19, is there a fix for Historian and incorrect timestamps?
What 3rd party OPC-UA server are you using?
It is a OPC-UA server created by the vendor who developed the PLC code. Its a B&R Embedded OPC-UA server. When the trending is done in the power chart, it uses the sql_data table that was created by the timestamp that is controlled by the Ignition gateway. The tags being historized from this OPC-UA connection have a different timestamp, so Ignition created a separate sql_data table for that data. The power chart doesnt find that data when the tag is selected to be trended.
This is getting really complex really quick.
Does the 3rd party OPC-UA server have the correct time on it? Is it the same timezone as the Ignition gateway?
Can you contact the vendor who made the OPC-UA server, or do you have someone on hand confident play around with it.
I’m not sure why Ignition would create a second sql_data table. I would think it would be same table and can be sorted via timestamp.
Something sounds kind of funky. Are you familiar with how those SQL tables are populated?
I think we are gonna need a lot more information to figure this out.
Because the OPC server is supplying bogus timestamps. Ignition is backfilling history based on those timestamps. Most people want this behavior to cover short comms outages.
I'm pretty sure there's a setting to use Ignition's timestamp, but I didn't find it with a quick search. @Kevin.Herron ?
{ The right answer is to make the B&R PLC synchronize to a reliable time source. I recommend Time Machines TM2000B, fwiw. }
1 Like
That makes sense. Kind of like its getting pruned?
There's a setting to use System or Source under a tag's alarm properties, but I don't know if it does anything in regards to history.
I think it used to be a tag history property but in 8.0 or 8.x the property was removed and it's not configurable any more.
Best bet is to get your OPC UA server to have the correct time. There's no reasonable excuse for anything else.
We don’t have access to the configurations of the PLC or the 3rd party OPC server. The History settings on the gateway are set to partition every month. So Ignition is creating a sql_data table for each partitioned month. So currently there is a table for 8/2022 and 8/2009 because the 3rd party OPC server timestamp has a year of 2009.
The power chart is unable to trend the data because the data has timestamp of 2009 while everything else has 2022.
There is a “Allow Back-Fill Data” setting in the Realtime settings of the gateway, but that is unchecked. I don’t see any other settings to force a tag to use the gateway timestamp instead of the OPC-UA server timestamp.
The only workaround that I have has been to un-historize the OPC tags, then create expression tags that get their values from the OPC tags. Then historize the expression tags.
1 Like
You could add a tag change script to the tag, and then use system.tag.storeTagHistory() to store the data with an updated timestamp. That would get rid of the additional tags anyway.
If you want the data to be stored on some period other than On-Change, you could use a Gateway Scheduled Event. Then you could use a combination of system.opc.readValue(s)() and system.tag.storeTagHistory() to add the history.
I would definately be reaching out to whomever has control of the OPC Server config, to see if the date is set correctly though.
1 Like
Reference tags would be easier than expression tags, but, yeah, as everyone else is saying, fixing the server time is definitely the right answer.
Would be a nice feature to be able to deactivate UA timestamp and rather use Ignitions own time in the device settings. 
3 Likes
Just had the same issue and I currently use reference tags between tag providers. The reference tags keep the same timestamp as the OPC tags