Re : CompactRIO RT freeze when I use "Set Time.vi"

[Nicolas_Bats]

I'm using a compactRIO and need to update the internal time of the device to be clock synchronized with my whole system. Everything seemed to work perfectly but when I try to apply an offset between 0 and -30 seconds, my compactRIO freeze. Nothing happen if I apply a positive offset or an offset "higher" (in a negative way) than -30 sec.

The duration of the freeze equals the offset I apply on my device and after this delay, everything comes back to normal. The freeze affects all my RT code (other processus as well) and not only the VI where I use the "Set Time.vi". The FPGA seems to be working during the freeze time because I got "DMA is full" error after the freeze and the FPGA LEDs keep blinking during the whole time (on the contrary the RT LED stop blinking).

Has any of you already noted something similar on compactRIO 9068 (Linux) ? Or do you have any idea of what is going on ?

Thanks for you help.

Nicolas

Additionnal informations :

   - LabVIEW 2013 SP1

   - NI RIO 14.0.1

   - CompactRIO 9068

   - Linux Embedded

   - LavBIEW Real-Time 13.0.1

PS :

- I use regular loops, no absolute timing VIs only tick count or nothing.

- The freeze happens in interactive mode but also with an rtexe.

- The compactRIO stays connected during the freeze.

[Guillaume.D]

Hello,

I'm not surprised by this behavior : the VI "set the time" define the absolut timing (hour and date) for the target : tha changes which are applied at this VI are applied at all the process ans task of the target.

The FPGA of the CompactRIO is not impacted by this : in your VI, you define "localhost" wich corresponded at the RT part of the cRIO system.

The FPGA continue to work separately of the RT part.

Int he most application, you use the VI  "Set the time" to define the absolut time at the initialization, and after you don't modify it.

Best Regards,

[CyGa]

Hi !

This behaviour is highly problematic ! You can't freeze a complete RT system for a so long time !

Usually, on embedded targets, when changing the RTC time, it waits until it gets an pos./neg. edge from the HW clock (re-phasing). So the maximum time the RT OS should freeze corresponds to the longuest delat you may have between the HW clock period the RTC synchronization clock (with a 1KHz HW clock and standard RTC it should something around 1ms).

As you said in most application, you use the VI set time once at initialization. Yes, in the case you're using only 1 compactRIO and not requiring to synchronize data acquired over the time with other system. In real life applications, you usually need to keep several (distant) systems synchronized together on a network, so you can correlate events happening on the differents actors on your system. That's the point of having a NTP server on a private network...

I'm wondering : if you go 20 sec. back in time, does the OS freezes for 20 seconds ?

Can you give us more details on how the RTC works on a CompactRIO RT target (synchronization, time update, impacts) ?

[Nicolas_Bats]

---

Guillaume.D a écrit :

Hello,

I'm not surprised by this behavior : the VI "set the time" define the absolut timing (hour and date) for the target : tha changes which are applied at this VI are applied at all the process ans task of the target.

The FPGA of the CompactRIO is not impacted by this : in your VI, you define "localhost" wich corresponded at the RT part of the cRIO system.

The FPGA continue to work separately of the RT part.

---

I agree that Set Time VI affects the whole RT code but what I don't understand is why "untimed loop" or "timed loop with internal 1 kHz clock source" (no absolute time) are affected by the absolute time shift.

The behavior doesn't happen on VxWorks target.

---

Int he most application, you use the VI  "Set the time" to define the absolut time at the initialization, and after you don't modify it.

---

I'm developing a continuous compactRIO data logger which (I hope ^^) should never stop even after hours / days / months of running. I have noticed a drift of 1.5 sec / day on my compactRIO so I must need to resynchronize it all the time.

[Nicolas_Bats]

More code to test ...

[Nicolas_Bats]

After many tests, using LabVIEW 2014 & NI Real Time 14.0.1 seems to "solve" the issue.

I don't have informations or explanations about the behavior described above, but I will update this topic if I got somes from NI. Meanwhile, Linux compactRIO users should consider to use NI RT 14.0.1 instead of 13.0.1.

[guilherme.zat]

I´m having the same problem described by Nicolas_Bats.

I was able to replicate the freeze by running a loop (using Actor Framework) with a Wait(ms) function inside and changing the date/time of the cRIO on MAX to a year before (instead of 2015 it was set to 2014). All my loops frezzes with this type of architecture. 

I´m doing this because my system has to update it´s time by NTP or the user can set a date/time by himself (disabling ntp).

Does anyone has an alternative for this?

Thanks for your help.

Guilherme Zat

Addionational informations:

- LabVIEW 2015

- NI RIO 15.0

- CompactRIO  9030

- LabVIEW Real-Time 2015

PS:

- My WebService responds normally during the freeze. ( I think it is affecting the WAIT function used inside the Actor Core Loops).

[ZX81]

Guessing:  Did you try without the 'Wait' (or skipped while changing the clock).  There's a good chance the implementation of 'Wait' assumes no one is messing with the RTC.  There's also a good (better?) chance it doesn't matter.  Maybe the implementation of 'Wait' changed from LV-2014 to LV-2015.

[guilherme.zat]

Since i´m using several loops (Actors) running in parallel i needed to add the Wait(ms) function so the RT could use the time to do something else, like processing the messages from the other Actors.

My thought was to change the Wait(ms) to Tick count, but I´m concerned if the inside of the Actor Framework (Processing messages and other stuff) isn´t using the wait funcion as well.

[AristosQueue (NI)]

I don't know much about cRio or other RT systems in this regard, but asking a couple of co-workers, someone pointed out that some systems use a threading model where threads go to sleep and say, "System, wake me up at time X." If the absolute time of the system then moves backwards, you have to wait until X occurs... that might account for your threads stopping, depending upon how long the jump was. If the absolute time of the system moves forward, it *might* be that the thread never wakes up because that time never occurs. None of this is from anyone authoritative about RT, just things these develoeprs had seen in their time about various operating systems.