We are using SNAP PAC, are moving to 10.2 and are adding some functionality.
We have a “Dispatch” Chart running that communicates with an external windows based process. This Dispatch Chart is only used for tasks that must be synchronous with external hardware not controlled by OPTO22 hardware or processes. Until recently we were able to capture the System time and log it as part of a log record. Simply: “TimeToString(sSystemTimeDispatch);”. Dispatch can initiate and control a little over 60 tasks. We now would like sub-second resolution on the start and end times. I know we can use up timers, but those are not “human readable”. We could start one at midnight and convert the value to HH:MM:SS.000, but there are a lot of locations and it introduces errors between 2 tasks that span midnight…
Is there a mechanism to capture the System Time in higher than 1 Second resolution?
Perhaps you could continue to use your “TimeToString(sSystemTimeDispatch);” and append the last three digits of Milliseconds Since Powerup. Elapsed Time and Milliseconds Since Powerup are already synchronized. If you go with this approach, consider the very rare occurrence of when Milliseconds Since Powerup ‘rolls over’, but this may be perfectly divisible by total seconds (the ideal situation here), or if not, the very rare error of less than a second may be acceptable to you.
[edit] (FFFF F030 010C) Milliseconds Since Powerup ‘rolls over’ every 49.71 days (Page 92 of OPTOMMP Protocol Guide Form 1465-200312—March 2020). Or (FFFF F030 0228) Milliseconds Since Powerup ‘rolls over’ every 584,542,046 years (Page 93). Both of these are available in my PAC-R1, PAC-R2, PAC-EB1, PAC-EB2, and GRV-EPIC-PR1.
I should note that this command only works on SNAP PAC Controllers. EPIC has a real time clock and this memory map location does not exist on (in?) that controller.
The easiest way to get milliseconds is to use the GetDateTime command. It sets an integer table with the current date and time. The milliseconds value is in index 7. This will work on PAC and EPIC.
Be careful if concatenating the milliseconds result from GetDateTime with TimeToString, since you are getting these values at two different times and it will not be an atomic operation. It is possible towards the end of the second that you could end up with the previous second in TimeToString, and the milliseconds from the next second.
It would be best practice to build the time string all from the date/time table returned by GetDateTime.
I wondered if I could slip it past everyone… beta firmware on an EPIC… Its been fixed.
One of the joys and hazards of the job.
(That and I wanted to prove to myself that the command worked fine on an EPIC).
