NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Timed loop pauses execution when NTP time jump occurs

Hi,

 

I've implemented NTP on a sbrio-9651 using the guidance in NI NTP Guide and it seems to work. I then tested the behaviour by deliberately changing the clock. To monitor the hardware I broadcast a CAN message with a counter value to see whether the Real Time processing was interrupted at any point.

My findings were; 

  • Setting time to the future
    • 4 min step change - Timed loop kept executing, sending counter values through CAN at 50Hz.
  • Setting time to the past
    • 6mins - CAN message counter froze - I suspect the Timed loop stopped executing.
    • 20secs – Adapted with no issues.

As an aside I performed a different Test looking at the step change of 4min 5 sec to the future. I logged the Timed loop duration counters which 9 out of 12 showed a pause of 50 second delay at the moment the clock was changed. 

 

So my question is; Is it possible to configure the Timed Loops to use MONOTONIC clock and not be affected by the NTP Time sync?

 

There is a similar discussion here: Permissions Setting date time with system exec or script

Background Reading

 

0 Kudos
Message 1 of 8
(3,296 Views)

I've just found this knowledge base article about getting unexpected Timed Loop behaviour when time is set backwards: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9pJSAS.

 

Is this issue still current?

0 Kudos
Message 2 of 8
(3,268 Views)

Oliver_15,

 

What version of LabVIEW are you using? This is a known issue that has been resolved in LabVIEW 2015 SP1. If you are using LabVIEW 2014 or 2015, the only workaround is to reboot the controller immediately after changing the time. 

 

For more information you can reference, LabVIEW Run-Time Hang On NI Linux Real-Time After System Time Set Into Past.

 

Thanks,

Andy 

Product Support Engineer

0 Kudos
Message 3 of 8
(3,260 Views)

Hi Andy,

I'm using LV2015 SP1 (Version 15.0.1) 32bit Environment so doesn't quite make sense.

 

The sbRIO-9651 has;

  • Firmware
    • NI Linux Real-Time ARMv7-A 3.14.46-rt46-ni-3.5.0f0
  • Software
    • HTTP Client with SSL Support 15.0.0
    • LabVIEW Real-Time 15.0.1
    • Network Streams 15.0
    • Network Variable Engine 15.0.0
    • NI System Configuration 15.3.0
    • NI-RIO 15.5
    • NI-VISA 15.5.0
    • OpenG ZIP Tools 4.1.0
    • Run-Time Engine for Web Servies 15.0.0
    • System State Publisher 3.4.0
    • Variable Client Support for LabVIEW RT 15.0.0
    • WebDAV Client with SSL Support 15.0.0
    • WebDAV Server 15.0.0
0 Kudos
Message 4 of 8
(3,253 Views)

 

Hey Oliver_15,

 

Interesting. Did you upgrade this controller from a previous version of software or have previous NI drivers installed on the host computer? Could you provide a MAX Technical Report for the host and the cRIO? This should help us understand the software stack where we are still seeing this behavior.

 

You could try reformatting the target via MAX to ensure the necessary updates for the fix are on the controller.

 

 

0 Kudos
Message 5 of 8
(3,247 Views)

Hi Andy,

 

This controller had v3.0 firmware before I updated it. I've also got LV2015 SP1 in 32bit and 64bit, as well as NI Max v17.0.0f0 installed. Attached is a MAX report of the software stack. 

 

I'll try reformatting the sbRIO and see if that helps.

0 Kudos
Message 6 of 8
(3,241 Views)

Hi Oliver_15,

 

After a little more investigation, I think you may be seeing a related issue to the one mentioned above that was found and resolved in LabVIEW 2016 (CAR 567981). This is specific to Timed Loops hanging when the time is changed during execution. This looks to be the exact behavior you are seeing. I recommend testing your code in LabVIEW 2016 to confirm that this is the cause.

 

Thanks,

Andy

0 Kudos
Message 7 of 8
(3,230 Views)
  • Setting time to the past
    • 6mins - CAN message counter froze - I suspect the Timed loop stopped executing.
    • 20secs – Adapted with no issues.

*FACEPALM*, they use the wrong clock. Yet another case of not having read the manpages.

 

man 3 clock_gettime

 

Actually, I'm regularily seeing such things in old industrial companies, especially in regulated areas like medical devices or automotive. 

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 8 of 8
(2,721 Views)