Strange behaviour when settings cRIO system clock

[andre.buurman@carya]

I noticed some strange behaviour when setting the cRIO system clock using the function: rt_set_time_sub_second.vi (found in the forums).

1. I ask the current time offset from a SNTP server.

2. I set the clock with "system time" + offset ("system time" is retrieved just before setting the time) (this takes 10-30 ms)

3. I ask the current time offset from a SNTP server after 2 minutes (sometime the offset is nearly zero as expected, but sometimes the offset differs up to 2-3 seconds from the previous offset.

It seems as if some system service is causing this because changes in order and extra sleeps don't seem to influence this behaviour.

Can anyone please shed some light on this issue?

[A_Person]

Hi André:

When using SNTP on a cRIO, it should synchronize with the time server once on power up and then start making incremental changes in the processor clock after that to keep the time synchronized.  From my experience, manually setting the time can cause the cRIO to lose synchronization but I really haven't investigated the behavior too much.  Generally speaking there shouldn't be any need for manually updating the time later on as long as the cRIO stays connected to the time server.

Can I ask what your use case for manually adjusting the time is to understand if there are any better methods for your application?

[andre.buurman@carya]

Hello Alex,

I don't use the SNTP service available in the cRIO system, because I can't oversee what the it will do when the connection to the server is lost for a period large enough for the cRIO to drift past the boudaries of the SNTP clock diciplining algoritm.

I have my own function that requests the offset from the SNTP server, it also checks for response validity as defined in the RFC, taking the best of 5 each request.

Due to this I need to manually update the system clock to account for the drift, but doing this disruptes the time even more than before the update.

I hope this sheds some light on my needs and challenges.

[Andrew_E]

What CompactRIO are you using along with what version of LV and NI-RIO?

[andre.buurman@carya]

Hello Andrew,

I use LV 2011 with NI-RIO 4.0 on a NI-9014 controller.

[andre.buurman@carya]

Is there already some news regarding the issue?

[Hossein128]

Hi,

Did you check that?

http://zone.ni.com/devzone/cda/epd/p/id/5846

regards,

[andre.buurman@carya]

The link you gave is the source I got the VI from that I use to set the system time.

It doesn't answer my question.

[Andrew_E]

Hi Andre,

Sorry for asking more questions, without providing a solution, but have you tried other SNTP servers? Also have you tried setting the time stamp manually (either through MAX or just regular date/time write in LV) without using SNTP and measuring the drift?

Regards,
Andrew

[andre.buurman@carya]

Hello Andrew,

I only used the SNTP to show in what context I use the "rt_set_time_sub_second.vi" and to determine the current offset to precise timing source.

The behaviour is displayed when I call this particular VI to set the time.

Normal behaviour would be:

- set time to current time minus 1 second -> offset relative to time server should be -1 second.

- again set time to current time minus 1 second -> offset relative to time server should be -2 seconds.

- etc.

This is not the case, I follows an unpredictive pattern.

The attached VI snippet (don't look at the style 😉 it is to get all code in 1 VI for easy posting) contains the functional code required.