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

[felipefoz]

Hello everyone,

I am also having same problems with Set Time.vi, although I am not allowing user to set time manually, it only updates from time to time using NTP.

The VI responsible for updating controller clock (saveTimestamp.vi)  sometimes succeds and sometimes does not.

When it doesn't I got these error information and codes:

Error -2147467259 nisyscfg.lvlib:Save Changes (Hardware).vi:320001<APPEND>

<b>Complete call chain:</b>
     nisyscfg.lvlib:Save Changes (Hardware).vi:320001
     nisyscfg.lvlib:Set Time.vi:6150001
     saveTimestamp.vi:3800004
     saveTimestamp.vi.ACBRProxyCaller.7A30002A

If anyone has any futher information on these errors, I would appreciate it.

Thanks for your help.

 Addionational informations:

- LabVIEW 2015

- NI RIO 15.0

- CompactRIO  9030

- LabVIEW Real-Time 2015

[ZX81]

Unfortunately, nisyscfg.lvlib: Save Changes.vi is protected with a password.  Also unfortunately, the error code is 'Unspecified error' (right-click the error cluster and 'explain error').  The .vi does have detailed help, but nothing that useful.

My guess:  The Save Changes.vi has a timeout (Set Time.vi isn't protected, so I see it does).  But that timeout is based on the clock (not system ticks, like it should be).  The default timeout is 5 minutes.  So, if the NTP update sets the clock forward by 5 minutes, it looks like the timeout has expired.  Normally, the sub-vi should use the 'timeout' error code in this case, but I've seen quite a few places where error codes aren't what they should be, especially when it makes a system call, or .NET call.

Do you override the 5 minute default?  5 minutes for a timeout seems suspiciously long, so I suspect they set it so long to allow 5 minutes of correction without an error.  On the other hand, I would never expect NTP to give you a 5 minute update, unless you have two different NTP servers that keep arguing over time.

Suggestions:

1. try using the same call to set the time ahead by 10 minutes.  If it produces the same error, but does work correctly, then you can probably safely ignore the error and go on.

2. set the timeout to larger than you'd expect the NTP updates to be (I suggest 1200000ms), and see if it goes away.

3. look at the 'detailed result' for anything useful, and check 'changes require restart'.

----

AristosQueue was right about the scheduler.  That's why I suggested inhibiting the Wait.vi while changing times.  Typically, though, a change forward in time is okay.  The triggers to resume a thread are almost always ({current-time} > {trigger-time} AND {current-thread-priority} <= {triggering-thread-priority}), not {current-time} == {trigger-time}.  Using == would mess up any time two threads want to trigger at the same time, or if a higher priority thread is active.  Of course, there is a lot more to it than this, like switching every few milliseconds regardless of triggers, and handling multiple threads at the same priority.