Apparent time lag on PXI realtime

[Daniel_Chile]

Hi. I got a weird problem on LabView realtime. I am developing an "intelligent" data acquisition application intended to run on a PXI 8184 rt controller. My application uses timed loops, RT FIFOs, a watchdog, writing to monitor, disk logging and serial communication with UPS.

Both RT system time and host (windows) system time are well synchronized (a few seconds of difference).

The problem is that when the application runs, the time difference between both systems starts to increase, I mean, RT system clock apparently runs more than five seconds per minute slower than host machine system time, at least as reported by "get date/time in seconds" function on RT program. In few minutes of running, the system times on both machines reach a huge difference.

Well, I supposed that my program was screwing the RT system time in some way, but if I reboot the RT system, the time difference between both systems return to the original setting (only a few seconds). This makes me think of some kind of error on the "get date/time in seconds" function, I don't know why.

Any comments or workarounds will be greatly appreciated.

Daniel R.

[devchander]

Hi daniel,

It looks like your application is giving least priority to the "get date/time in seconds" function 

Probably, it is reporting time only after finishing all other tasks which have a higher priority/criticality.

do others agree?

dev

[Daniel_Chile]

Hi, dev. Thank you for your answer.

About that, should I mention that if I stop my application on the RT and then load and run another small VI, which consists of a single "while" loop with only the "get date/time in seconds" function, even though the time difference does not increase, it remains reading the "late" system time. Apparent synchronization is back only after rebooting.

Curious, isn't?

About priority you are right, the "get date/time in seconds" function is on the low-priority timed loop of my application, but the CPU time usage always keeps around 30% and there are no "late" or discarded frames.

All comments appreciated.

Daniel R.

[.avi file]

Greetings!
   Thanks for the inquiry. This is expected behavior in LabVIEW Real-Time 7.1.1 and earlier. We have taken care of the issue in LabVIEW RT 8.0 which will release in the near future. LabVIEW 8.0 is out and you could download that to your computer to get hands on.

http://zone.ni.com/devzone/conceptd.nsf/webmain/a312b731d7ce143d8625708b0070c71b

Thanks much and hope this helps
Best regards
Avi Harjani

[Daniel_Chile]

Hi, Avi, thank you for your answer.

Do you mean that this apparent time lag is an expected behavior or that it's a bug you've resolved on LV RT 8.0?

The link you posted only talks about LV RT 8 generally. Where can I find information about why and how this problem is produced, so I can think of a workaround? I need it for my application.

See you!

Daniel R.

[.avi file]

Greetings Dan:

    Yes this was a bug that we resolved in LabVIEW RT 8.0.

As a workaround, since you are using a PXI controller, use the attachment in the following link

http://digital.ni.com/public.nsf/websearch/EE7AC739A2E2BE068625699000568143?OpenDocument

It uses a Read Time Stamp Counter (RDTSC) assembly instruction for Pentium-class processors (even the AMD processors on the PXI controllers are Pentium-class).

Thanks and hope this helps
Best regards
Avi Harjani

[.avi file]

Greetings Dan:
     Yes it is a bug that we fixed in LabVIEW RT 8.0. As a workaround since you are  using a PXI controller, you could use the attachment in the following link.It uses a the Read Time Stamp Counter (RDTSC) assembly instruction for Pentium-class processors (even the AMD processors on the PXI controllers are Pentium-class).

http://digital.ni.com/public.nsf/websearch/EE7AC739A2E2BE068625699000568143?OpenDocument

Hope this helps, Good luck
Thanks
Avi Harjani

[Daniel_Chile]

Hi, Avi, thank you for your answer. I'll give this workaround a try.

If it works in RT, I think it should do the trick.

I'll be telling you if it worked.

Thanks again and see you.

Daniel R.

[RobCole]

Having fought this one myself, I think I can answer "what's going on?" in this case.

The problem is that the update OS clock function in RT is a low priority process. If you are running time critical or high-priority loops in your system, then the OS clock update gets starved and the clock starts to lag. When you reboot the controller, then the hardware clock is read and updates the OS clock. The hardware clock is fairly accurate, but Get Date and Time reads the OS clock.

I know that the wording I've used isn't technically accurate, but that's the gist of what's happening.

Whether LabVIEW 8.0 gives you access to the hardware clock or just maintains its OS clock better, I do not know. I do know that it works well.

     Rob

[Daniel_Chile]

Hi, everybody. From your comments and a similar thread I found ( http://forums.ni.com/ni/board/message?board.id=280&message.id=804&requireLogin=False ), I've come to a workaround that works fine for me on a PXI controller. It just needs to be run at the start of the application, when the "Get date/time in seconds" is still supposed to read a decent timestamp and then it gives a "correct" timestamp from the reading of the processor counter.

Note that it will work fine even if the application is stopped and then run again. As it works as a buffer, it cannot be reentrant.

In my application I don't make an intensive use of it and it works fine, but I really don't know if it could cause priority inversion when used intensively on a low-priority thread, since I don't really know how this DLL calls work.

Well folks, thank you all.

Daniel