Timed Loops in LV for Linux?

[Cepera]

A question to NI folks: any hope for us to see timed loops in LV for Linux any time soon?

Thanks,

Sergey L

[mhoogend]

I'm not fully versed on the LabVIEW side of things, so I have no idea of any future plans.  What I have heard on the technical front is along the lines of what has held it back.  As in, we have looked at it, but the solution hasn't presented itself.  Basically the features we leverage to implement the timed loop in other OS environments don't exist on Linux.  Alternative implementations either don't have the features to support it or it is an approach that is severely discouraged on Linux.

We have a bunch of really smart engineers working on LabVIEW though, so it certainly doesn't hurt to encourage NI to figure out a way to support timed loops on Linux.

[Shawn B.]

First I should say that I have no idea what a timed loop does.  How does it differ from a while or for loop with a sleep delay?  I'm guessing it simply provides more determinism?  Is this something National Instruments supports on Windows, or just RT?  Lastly if LabVIEW for Windows does support timed loops is it possible to know what "feature" Windows is providing to make it possible that Linux lacks?

With some more info I may be able to provide some ideas on how it could be implemented on Linux.

--

Shawn

[mhoogend]

As I said, I don't know what it is that it requires.  I'm just going from hearsay.

so it certainly doesn't hurt to encourage NI to figure out a way to support timed loops on Linux.

To decode my statement, this goes back to other discussions of providing the feedback to make the Timed Loop a priority.

[FallGuy]

One avantage of the Timed loops is to allow the developer to put each loop on a specified core.

[Shawn B.]

FallGuy wrote:

One avantage of the Timed loops is to allow the developer to put each loop on a specified core.

Well that can be done on Linux with sched_setaffinity().  Does a timed loop simply run the loop at a periodic interval?  What is the resolution of the interval (milliseconds, microseconds, nanoseconds)?

--

Shawn

[mhoogend]

A little google searching on ni.com brings this up for timed loop info.

http://zone.ni.com/reference/en-XX/help/371361E-01/lvconcepts/configuring_the_labview_timed_loop/

[Shawn B.]

That gives me a little better idea of what a timed loop is.  I'm sure I may be missing some of the details, but basically it looks like it lets you run the loop at a specified interval.  The article mentioned that the clock is 1 KHz by default, and I'm guessing this can be changed and likely can be set to a custom hardware source.  For a custom hardware source NI would develop the device driver and thus should be able to expose a suitable device API to access the hardware clock.  For the default 1 KHz clock the Linux system timer is typically set to 1 KHz for desktop distributions so there shouldn't be any problems there.  Modern kernels (2.6.16+ for i386) even support high resolution timers which would allow for clocks (in theory) up to 1 GHz.

My first choice to implement timed loops would be to use the timerfd APIs (timerfd_create(), timerfd_settime(), timerfd_gettime()).  These allow you to create either a one shot, or periodic timer that is accessed via a file descriptor.  The file descriptor will return from a blocking read when the timer expires, or can be monitored with select, poll, or epoll.  The buffer returned from reading the file descriptor also provides the number of times the timer has expired.  Really the only potential problem for NI to use timerfd is that it is only available in 2.6.25+.  If you need to support RHEL 5 (which you likely do) they you can use timer_create(), timer_settime(), and timer_gettime() which are mostly the same but use signals instead of a file descriptor.

Assigning a loop to run on a specific CPU can be done with sched_setaffinity().  Setting prioritys of the various loops can be done with sched_setscheduler, and sched_setparam().  For the priorities to work you will likely need to use a real-time policy like SCHED_FIFO or SCHED_RR, which may be a deal breaker since they can't be set by an unprivileged process.  I personally wouldn't worry about that since a system administrator can give those privileges when needed.

There may be other features of timed loops that I'm not aware of, but I'm thinking there shouldn't be any technical reasons timed loops can't be implemented on Linux.  If more Linux users request the feature I'm sure NI can allocate the resources to implement them.

--

Shawn

[rolfk]

I'm sure it's possible. Linux is not a second class OS to Windows at all. However the technical implications might be more difficult than you foresee. On Windows when the timed loop was first introduced NI specifically discouraged it's use as being not a safe and completely functional feature and only guaranteed it to work on their own RT targets.

I guess this was because the control they have in their own RT systems goes a lot further than under Windows and I have run indeed into problems on Windows when trying to use it anyhow. The timed loop seems to go very deep into the Windows internals to the extend that I managed a few times to lock up the entire machine completely when using it. With this I mean that no Ctrl-Alt-Del was working anymore, and no task switching or whatsover. The machine simply sat there and seemed to do nothing anymore and the only way out was the power switch. This implicates to me that the timed loop at least partly relies in some ways directly on kernel services and somehow was and maybe still is able to lock that up under certain circumstances.

So a timed loop on Linux might suffer the same faith for its start and maybe quite a bit into its refinement phase and considering the market share of LabVIEW on Linux this might seem simply a to big obstacle for some of the managers. Most likely there is a proof of concept shared library to support the timed loop on Linux already internally but it probably suffers some instability and maybe even lockup troubles and the time needed to debug that did not get allocated.

From my own experiences getting complex system level shared library code to work on Windows, Mac and Linux istn't that much of a problem, but to get all wrinkles ironed out on the different platforms is a real challenge that usually takes a multiple of the time it took to get the code to the point where it is basically working.

[Wang_Liming]

we have Crio 9039 RT Crashing Periodically problem, can you help us?

https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/Crio-9039-RT-Crashing-Periodically-problem/m...