IEC 60870 timestamp in zenon

[abstinent]

Hello,
Can you explain me, please, how can we get a timestamp value supplied with variable in datapacket from IEC 60870-5-104 server when using IEC 870 types with time tag CP56Time2a?
Maybe via VBA or some other issues?
It seems, that in database after data evacuation (zenon archiving) field "timestamp_s" contains system timestamp of a variable (timestamp of assignment a new value according to computer clock) instead of time from IEC datapacket in CP56Time2a.
So, another question is, how to get correct timestamp (transmitted by IEC 60870-5-104 server) in database after data evacuation?

[markclemens]

Hi,

Normally when the RTU / PLC provides a timestamp, and the driver supports the external timestamps (which is the case with the IEC870 driver, provided the correct ASDU type is used at the variable), the external timestamp is used everywhere in zenon.

So you should see the correct timestamp in the event list, in the alarm list, in the variable diagnosis screen, in the historian, etc.

Is it in your case only the evacuated archive that does not have the correct timestamp_ms in the SQL server? When you view the current open archive that is not yet evacuated, does it show the correct timestamp? When this is the case, this may need some further analysis, and I would like to ask you to send an inquiry to your local COPA-DATA support with all relevant information.

Best regards,
Mark

[ursulak]

Maybe you are looking on the values got by GI (general interrogation, made e.g. by connection initialization) not by spontaneous value changes coming later.

In GI the PLC does not send any timestamps as for GI the protocol uses only "pure" type identifications, e.g. T01 instead T30 and sends it not with COT=3 (spont) but COT=20 (interogen). Thus in zenon the first values after communication start can have local timestamps. In iec870 driver, when the PLC sends valus with time tag then in zenon they have for sure the received timestamp.

In the column for status bit in Historian/CEL/AML you can probably see which COT bits were set by the value. For spontanious values the status bits are COT0, COT1 (1+2=3); for GI - COT2, COT4 (4+16 = 20). The status bits T_INTERN and T_EXTERN inform if the timestamp is local or from PLC but i'm not sure if Historian shows these two bits.

[abstinent]

Thank you, for quick replies.

Unfortunately I see incorrect timestamp everywhere in zenon, not only in the database after the archive data evacuation, but before too and even on the pictures (I made VBA script to display LastUpdateTime, LastUpdateTimeMilliSeconds). It seems, that driver IEC870.exe does not use an external timestamp for some obscure reason
For test purposes I used Triangle MicroWorks Protocol Test Harness as IEC870-104 server. In zenon I add a driver IEC870 variable: datatype=REAL, IEC type=T36, COA=3, IOA=7, PLC marker.
I see correct data values but incorrect timestamp (probably system timestamp), and this timestamp goes to the archive:

(LastUpdateTime and LastUpdateTimeMilliSeconds) __ (IEC870 transmitted timestamp)
zenon_timestamp = 16:18:14.764 _________________ transmitted_timestamp = 16:18:14.693
zenon_timestamp = 16:26:04.400 _________________ transmitted_timestamp = 16:26:04.389
zenon_timestamp = 16:33:14.348 _________________ transmitted_timestamp = 16:33:14.277

StatusValue = 0x420000 (Realtime internal bit is set)
StatusExtValue = 0x20003


16:33:14.277: <=== s104 Addr(0) Sector(3) Application Header, Measured value, short floating point number with 56-bit time tag
16:33:14.277: Quantity(1) SQ(0) COT(3, spontaneous)
16:33:14.277: 24 01 03 00 03 00 07 00 00 66 66 ca 41 00 c5 37
16:33:14.277: a1 90 5d 05 0c

( 0x24 = T36 Measured value, short floating point number with 56-bit time tag, COT = 3, COA = 3, IOA = 7, timestamp = {c5 37 a1 90 5d 05 0c} = 2012.05.29 16:33:14.277 )

[ursulak]

great description, i'm impressed.
What zenon version (and build) are you using? I will try to reproduce it.
Have you tried it too with some other type identifications, e.g. T30 and T31?

[abstinent]

I am using zenon 6.22 SP1 build 9. I did not try IEC types T30, T31.

[ursulak]

In this time tag value - in 3th byte the IV bit (IEC60870-5-4 "Binary Time 2a": BS1[24] - invalid) is set: c5 37 a1 ...--> a1= 10100001 ("IV" and 33 min). Thus the driver gives to zenon Runtime not the received time tag value but the local timestamp (+ T_INVAL status bit).

Change the Test Harness configuration to send valid time tags.

[abstinent]

Thank you very much for clarification, now I have a correct timestamp (after changing Test Harness configuration).

[prasadkh]

Hello May I request to inform how we can change the Test Harness Configuration as we are also facing the same Issue.

Thanks