Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
Unexpected date/time display behavior
-
We are querying some epoch times via Modbus/tcp, and are experiencing some unexpected behavior:
modbus register (a double word, 2 input registers) contains: 1551356992;
data point as 4 byte signed integer, interprets the value differently as 1551302656 with plain formatting, but displays "Jan 18, 1970 14:55:02" when using date/time formatting;further, another register contains the value 0; data point interprets correctly as zero, but displays "Dec 31, 1969 16:00:00".
No doubt serious pilot error here, but I'm at a loss to make any sense of it.
-
Hi bullitbd,
I'm not understanding.
data point as 4 byte signed integer, interprets the value differently as 1551302656 with plain formatting
Meaning this is the value the point is reading? Have you checked to see if perhaps the register offsets are off by one (and then also check the 4 byte signed integer swapped types at those offsets)? Mango is 0-offset, but some begin their offsets at 1.
but displays "Jan 18, 1970 14:55:02" when using date/time formatting;
That's because it's expecting a time value in epoch milliseconds, while a four byte integer can only really provide epoch time in seconds. So, put a multiplier of 1000 on the point, or set the conversion exponent on the time renderer to 3.
further, another register contains the value 0; data point interprets correctly as zero, but displays "Dec 31, 1969 16:00:00".
That would suggest to me that you're at GMT-06:00 and have a time text renderer on the point.
-
@bullitbd said in Unexpected date/time display behavior:
Jan 18, 1970 14:55:02
Thanks for the quick response, Phil. Right you are on number 2...
to your third point, actually on GMT-08:00, which does explain that!The offsets are right - still trying to sort why the epoch value is off by a couple of days +/-. Will keep mucking about here.
-
to your third point, actually on GMT-08:00, which does explain that!
Wait, there aren't 22 hours in a day? Whoops :P
The offsets are right - still trying to sort why the epoch value is off by a couple of days +/-. Will keep mucking about here.
How did you know the value in the register before reading it? Perhaps it's not sync'ed to the right time. The bit banging to decode registers into data types can be found here, but it's quite unlikely there's an issue there: https://github.com/infiniteautomation/modbus4j/blob/master/src/com/serotonin/modbus4j/locator/NumericLocator.java
