System time drift when calling NI-Motion VIs on PXI controllers

[Sci-Vi]

Hello,

Just a mail to avoid others wasting time if faced to that fancy bug:

We are using PXI systems with NI PXI controllers running Windows 7 and Motion boards of the 7340 family (PXI-7344). We have noticed that when calls where made via NI-Motion VIs to query the various axis status registers (for example position, ADC value, general axis or reference status), the system (Windows) clock runs FASTER than it should be. The more NI-Motion calls are made per second, the faster the Windows clock runs. When addressing status for 4 axis 10 times per second (100 ms loop rate), the drift is more than 5% !

I include here a sample program that reproduces this behavior.

This is a critical issue for example if you log data with or based on timestamps, and it is even getting worse if Windows is configured to periodically synchronize its own clock to a time server via NTP protocol (this is how we noticed this problem in the first place). In this case, you see big discontinuities in your logged data every once in a while. Our systems must be automatically running and logging data continuously all year long, so this bug is a real challenge.

People at NI managed to reproduce this bug too, and are currently addressing it (no idea of any CAR # yet). Note that this problem has not been seen on a non-NI desktop controller running Windows 7 64 bit...

The exact configuration is the following:

PXI-1036 chassis

PXI-8101 controller (or PXI-8102 on another system)

PXI-7340 4-axis in slot 4, no physical connections for this test

(PXI-6221 in slot 2, unused in this sample program)

Windows 7 Enterprise SP1 32 bit English

LabVIEW 2011 SP1 32 bit English

NI-Motion 8.3

PXI Platform Services 2.6.2

(all additional NI software from distribution 2012 DS1)

Controller BIOS: upgraded from 1.3.1 to 2.0.1f0, problem seen with both BIOS versions

I'll try to post here as soon as we get news from NI.

Regards,

Vincent

[Ben]

I'm curious.

What external reference are you using to show the system time is running fast?

5% is approaching an hour for a day and that is unheard of.

Is the ms timer affected?

Ben

[Sci-Vi]

I currently have no idea about the ms timer, I should try when I have some time.

For the external reference, as you say 5% is nothing small, so it's pretty straightforward to check :

You just take any stop watch, you look at the Windows time on the PC monitor, and look how many seconds elapse on your stop watch for a 1 minute increment of Windows time. You usually get 60.0s ±0.2s (your own accuracy in handling the stop watch), then you run the VI querying NI-Motion axis status as stated above, and you read about 56.5s on your watch for every 1 minute increments of Windows time... Pretty impressive, isn't it ?

Vincent

[Ben]

---

@Sci-Vi wrote:

I currently have no idea about the ms timer, I should try when I have some time.

For the external reference, as you say 5% is nothing small, so it's pretty straightforward to check :

You just take any stop watch, you look at the Windows time on the PC monitor, and look how many seconds elapse on your stop watch for a 1 minute increment of Windows time. You usually get 60.0s ±0.2s (your own accuracy in handling the stop watch), then you run the VI querying NI-Motion axis status as stated above, and you read about 56.5s on your watch for every 1 minute increments of Windows time... Pretty impressive, isn't it ?

Vincent

---

Yepper!

A casual discusion of this issue last week with my in-house motion guy had us asking "How could the possible screw that up?"

Ben

[Naity · Accepted solution]

Hi all,

I wanted to let you know that the upcoming NI-Motion 8.4 driver should fix this issue.

Best regards 

[Sci-Vi]

Yes indeed...

I was just about to post an update here : I can indeed confirm, we have tried the pre-release NI-Motion 8.4 on our PXI systems (same configuration as described above) and the problem is gone... Thank you NI for the fix !

Regards,

Vincent