Bad Tag Quality after upgrade to 7.5.3

I just upgraded our Ignition system to version 7.5.3 from 7.3.5, and now I am getting bad tag quality for all tags from our sites with PCS7 systems. OPC server is connected, and I am getting readings, but the tag diagnostics say bad quality.

What is going on? I have disabled and enabled the OPC servers for the sites, and the tag quality is still bad.

Dan

Anything going on in the logs?

Well, in the logs, I keep getting the errors:

“Received value with timestamp in the future.”

“Repbulish returned Notification message with publish time in the future”

We have plants all around the country, and in all of the different timezones. The plants that are getting the errors are all running PCS7.

The other plants are not getting the error.

This was never an issue before the upgrade.

The timestamp stuff has been relaxed in 7.5.4 to allow up to a 10 seconds delta in timestamps. This is likely the cause of your bad quality tags.

The latest beta version of the UA module (here) should include this change.

If your timestamps are greater than 10 seconds in the future you’ll have to do some work to get your servers and timestamps synced up a little better. Whether or not the server is in another timezone is not a problem since we’re dealing with the delta on UTC times.

These changes regarding values coming from “the future” were sort of forced on me by the OPC-UA compliance testing and I’m doing what I can to relax them a bit while still remaining compliant.

Alright, we are installing the module now. I will let you know if we come across any other issues.

Dan

Still getting the same error after upgrading to 7.5.4.

What timestamp is it checking against? Is it off the PLC or off of the OPC configuration utility?

Dan

You used that 7.5.4-beta4 module I posted, right?

When a driver reads a value from a PLC and hands it off to the server it sets the source timestamp for that UA DataValue to that system’s current time. This timestamp is embedded in the value that is transferred to any UA clients consuming those values. The UA client then checks that timestamp embedded in the value against the current timestamp of that machine to make sure that it’s not from the future more than 10 seconds.

For this to happen (as of 7.5.4-beta4) the time delta between client and server machines has to be greater than 10 seconds. If you’ve got your machines keeping their timed synced via NTP (or whatever else) you shouldn’t really ever see a drift of more than a 1-2 seconds.

What do the messages in the logs say now? They should include the amount of time delta in the messages.

4 sites, each has a different delta for each.

Some are +500000, others +1000000.

So, do I need to change the timestamp in the PLC, or in the computer running the KEPserver program?

Is there any way to just disable the timestamp check?

Dan

It’s the time on the computer. Don’t just manually adjust it either, run the windows time synchronization.

I’ll see about if I can add an option to disable the check completely, but nothing currently exists.

Is there a way to disable overlays when a client is launched?

You could disable them using a client startup script and the system.tag.setOverlaysEnabled() function (inductiveautomation.com/supp … nabled.htm)

(Disabling overlays in response to this problem is probably not the approach to take.)

Is there a way to disable the timestamp check? Our control systems are directly connected to the internet, so the windows time synchronization is not working properly. I was able to manually change the times, but they are already showing a difference again after 5 days.

There isn’t currently a way to disable it, but I’ll see if that’s something I can do.

In the meantime, make sure the Windows Time Service is running on your servers and if necessary change the interval at which the services synchronize their time.

technet.microsoft.com/en-us/libr … 3061(WS.10.aspx

Also, to anybody else landing here, 7.5.4 is released the allowed delta in that version is anything up to 10 seconds.