time matching - eurotherm controller to labview

[Henrik_Volkers]

I ignored the fact that you are commicating using OPC with datasocket (No experience with that, only via serial)

Do you have any documentation (or someone to ask 😉 ) to tell you what data format the variables you named in the OPC-adress need to have?

Starting with the type of the variable (string, DBL, I32, ...?) ?

          if the driver behind it need to coerce the type , funny stuff can happen.

and the format  (how did you know the BDL needs to be ms since midnigth? )

      again, sometimes the software/NI/driver/...  try to be smart and coerce data to the format expected, not always in the way we/you think!

      and timestamp is a fixed point format .. and I'm not shure if NI and the OPC server mean the same.

[sanvish]

HI HENRIK,

 The data type is integer at the opc server end for time parameter .It is not the problem of communication with the controller .the controller is accepting the inputs given from labview. my concern is the time entry made in labview is not matching to time in the controller . if i use time zone correction also its not matching ..

[GerdW]

Hi Sanvish,

please show a manual where the exact format of that specific parameter is explained…

[diman27]

Hi sanvish!

Please read this document carefully: https://www.eurotherm.com/?wpdmdl=27877

Especially chapter 6.

"To overcome these problems, a sub protocol has been defined, using the upper portion of the Modbus address
space (8000h and upwards), allowing full 32 bit resolution floating point and timer parameters. The upper area
is known as the IEEE region."

Maybe the problem is that you are only using one 16-bit Modbus register to represent the Eurotherm controller's 32-bit time format?

[Henrik_Volkers · Accepted solution]

Seems like you wrote a 64bit  DBL instead of a I32 or U32  and the datasocket write is simply writing the lower(?) 32 bits  🙂

try this

and write a I32 to datasocket

read the value also as a I32 and recalc the ms  to timestamp ...     (and keep in mind, that your system clock and the eurotherm clock use different timebases that will drift apart with time 😉

The Second to Time/Day vi can provide systemtime or UTC 🙂

EDIT:  Maybe I32 is not the correct datatype  (unless you have negative time values) so a U32 type would be the correct one. Migth hit you if timevalues are > 2^31 ms  (or is it 2^31-1 ? )

If you get an error writing I32 to that datasocket adress, convert it to U32 or U64 and try again...

[diman27]

Another document from Eurotherm Modbus/Profibus Communications Handbook (HA028014 Iss 7)  says:

The Date and Time values can be transferred within the constraints of either POSIX or ISO8601 formats.

POSIX format. This format maps both values into a single 32-bit number. The values are converted into the
total number of seconds elapsed since midnight on January 1st 1970.

ISO8601 format. The ISO8601 format maps DATE and TIME fields separately.
A DATE value is represented as a decimal number in the format YYYYMMDD. e.g. 14th November 2005 is
represented as a decimal number, 20051114, and converted to a 32-bit hex value, 0x0131F4AA.
A TIME value is represented as a decimal number in the format HHMMSS. e.g. 14:02:35 (2 minutes and 35 seconds
past 2pm) is represented as the decimal number, 140235, and converted to a 32-bit hex value, 0x000223CB.

The author must first find out what format is used in the controller POSIX or ISO.

If POSIX - need some additional conversion from LabVIEW epoch to POSIX epoch.

The LabVIEW timestamp starts at 01/01/1904 00:00:00.00 UTC

The unix epoch is 01/01/1970 00:00:00.00 UTC

And yes, sending the DBL value is wrong. I32 or U32 would be the appropriate type.

And one more thing, it seems Eurotherm uses a non-standard way for transferring 32bit values via Modbus, as I wrote above...

[LFBaute]

The Epoch Date & Time Toolkit has saved me several times on these time calculations procedures, maybe this can help

[sanvish]

Henrik

Hi Henrik,

Thanks for the clarity.. the problem got solved..