Skip to main content
A
atondorf14-Alexandrite
14-Alexandrite
August 29, 2019
Question

Timestamps from Kepserver to Thingworx, lead to TimeShift!

  • August 29, 2019
  • 2 replies
  • 3065 views

Dear Community!

 

we have S7-PLC here connected to a KepServer transfering the data to ThingWorx.

All the data connection, management and so on is working great but still an issue with Timestamp-Tags of type Date. 

OPC-UA and I think also the KepServer define UTC as std. Timezone for all Timestamp data, they do not attach timezone information to the timestamp. So when Thingworx recieves the data from KepServer it takes the data as UTC and stores it to the bound properties.

But our S7-PLCs clock is running at local time, not UTC. So all timestamps recieved by ThingWorx are based on the wrong timezone. I looked around if there is any possibility to "shift" or adjust this inside Kepware.

 

Our current only possible workaround seems to be:

- Define two Date Properties for the Thing, one bound to the Kepserver Tag and a subscription to calculate the shift and write the correct value to the second one.

 

Any other ideas??

 

 

2 replies

P
PaiChung22-Sapphire I
22-Sapphire I
August 29, 2019

Unfortunately that is probably what you need to do, or something similar.

I'm not a kepware expert so I'm not sure if there is something that can be done in kepserver or not.

C
Constantine18-Opal
18-Opal
August 29, 2019

@atondorf, I don't have access to any KEPServerEX at the moment, so I can't verify it myself, but are you sure it uses UTC and not the local timezone of the server (which just turns out to be UTC in your case)? If it's the local timezone, then changing it might do the trick.

 

/ Constantine

A
atondorf14-AlexandriteAuthor
14-Alexandrite
September 2, 2019

Thanks for the information and support, but this does not the trick ... 
In discussion it pointed out, that this is not an issue based on a bug, it's more a missing feature in Kepware.

 

We have a system with one Server and connected PLCs.

All components (Thingworx, Kepware, PLCs) are running in local time zone ( currently MESZ).
The PLC is an S7-300 that does not know anything about timezones, but as we need the PLC to run in local time for communication and synchronisation with other systems, our PLC developers did some effort to sync the PLCs with NTP. 

 

Now we connect the PLC to the Kepserver and have a DB containing some DATE_AND_TIME values. These values are all in local time, as the PLC is running in local time ...

  • e.g. 15:00:00+02:00, where the +02:00 MESZ is not known by the PLC

When I now look at the KepServer tags, I see that these values are numerical the correct values, but they are missing any timezone information. OPC - Spec is quite clear on this, that all TimeStamps in OPC(UA) must be UTC.

  • e.g. KepServer displays: 2019-09-02T15:00:00, without any Timezone designator ...

When I now connect this tag to a thingworx property, Thingworx "correctly" treats the timestamp as utc and displays the value shiftet by the timezone.

  • e.g. Thingworx displays: 2019-09-02 17:00:00, where Thingworx in direct dispaly of properties also does not display the timzone designator. But when I call dateFormatISO() I get the value 2019-09-02T17:00:00.000+02:00 including the timezone.

So what is missing here is a feature to tell the KepServer the timezone designator of an connected device.

The KepServer assumes, that all connected devices provide timestamps in UTC, which sometimes is not possible.

C
Constantine18-Opal
18-Opal
September 2, 2019

Understood. Then two other workaround ideas:

 

  1. Are those timestamps also tags? If yes, maybe you can do conversion to UTC on the PLC side?
  2. I don't know how you store those values on ThingWorx side, but if you do it via bound remote properties which are logged, then try creating another set of properties (also logged, but not bound), and do a conversion inside a Subscription on the Thing or ThingTemplate level (in Data Change event for a given property). If that works -- remove persisted and logged flags from original properties, so that they act as temporary variables.
Terms & ConditionsCookie settingsAccessibility statement