String Concatenation Vs. 64-Bit Arithmetic

[SteveMyres]

I am receiving a time from a Modbus device, and I have the option of receiving it as an array where each element contains one part of the date in standard calendar format,

{{2012, 10, 9, 16, 20, 10, 345}} encodes {{YYYY, MM, DD, hh, mm, ss, milliseconds}} and I can build a date string using concatenation

OR

I can get the time in the form of a 64-bit INT returned as two 32 bit INT's (MSW x 2 ^ 32 microseconds + LSW), which I can convert to a systime() encoded number with a little arithmetic.

I assume the arithmetic is faster. Are there any other considerations? Which do you recommend and why?

[AzeoTech]

You probably can do it with the 64 bit int. You'll need to figure out where the 0 point is. In DAQFactory (and Windows / Unix) its Jan 1, 1970. Then the math is pretty simple, you just have to remember that DAQFactory numbers are all double precision, 64 bit floats and as such can't store a full 64 bit int. But if the 0 point is 1970, you shouldn't need all 64 bits. In fact, microseconds since 1970 fits just fine in a double.

But, I'd just use the other registers. It'll be only marginally slower, and mostly in the transmission of the extra 3 words. Converting it to DAQFactory time will take maybe 100 microseconds. You'll want to use the strToTime() function described in the user's guide section 4.12.11.

[SteveMyres]

Yes, their Zero Time is 1-1-1970 (which is bad because their docs say 1972). A value set from today was 314280 (MS DINT) and 616000000 (LS DINT), for example. I can manipulate the format of the sent data a little, and I really don't care about microseconds. Probably less than a second would be good, but milliseconds or hundredths should be adequate.

Even seconds since 1970 is 1.34 * 10 ^ 9, so is pushing a 32-bit INT. Milliseconds pushes it to 1.34 * 10 ^ 12, so needs ~40 bits. I was thinking seconds in register 1 and ms in register 2 or something like that if I were to do it numerically. It means I have to manipulate the native format a little but it's no huge deal because it's on a one-shot basis when the event to be time-stamped occurs.

And....the target format is string anyway, so maybe concatenate(DoubleToStr(Array)) makes more sense.

[AzeoTech]

You can fit microseconds into a double. A double float (64 bit) can store 15-16 sig figs. You need 9 for the seconds, and 6 to get to microseconds. To convert your two values, lets call them LS and MS, you'd do:

newTime = LS / 1e6 + MS * 2^32 / 1e6

Fortunately, MS * 2^32 puts you right up at 16 sig figs, but since the 1st is a 1, its within the range of a double.

[SteveMyres]

For a variety of reasons, I'll probably go with the arithmetic approach.

However, is there a format specifier in FormatTimeDate that will allow display of seconds as a real.

IOW, if my time value is 1350150400.025, I want the string to format as Oct-13-2012 17:46:40.025

What I'm doing now is

FaultDisplay[0][1] = FormatDateTime("%b-%d-%Y %H:%M:%S", (FaultData[0][3] << 16) + FaultData[0][2]) + "." + Right("00" + DoubleToStr(FaultData[0][4]), 3)[/CODE]

Which works but feels like a bit of a kludge.

(FaultData[0][2] and [0][3] hold the integer seconds, while [0][4] holds the ms, obviously)

[AzeoTech]

No. You'd have to add it in, similar to what you did, or if you have the time as one big number as from the arithmetic approach, you'd do something like:

formatDateTime("%b-%d-%Y %H:%M:%S", theTime) + right(format("%.3f",thetime),4)

[SteveMyres]

That's cool -- it's fine the way it is now, just always trying to broaden my knowledge and/or come up with the cleanest solution.

Thanks!

(In addition to documenting their Zero Time incorrectly, they neglected to mention that while the array approach gives correct local time, the Boatload-Of-Seconds method is in GMT and you don't instantly notice because the BOS encoding isn't really human-readable. That took me an hour or so to get sorted. Kept assuming it was my conversion arithmetic on the other end, but it was that the time value being sent to me was different, both for some bizarre reason referred to as "Wall Clock Time"! That's OK -- "ServoActualPosition" isn't the Actual.....Position.....of the.....Servo. Go figure.)