RT Ethernet!

[Stijn_Schacht]

Hi everybody,

I know this topic hasn't been viewed for over 4 years but we are experiencing the same issues on a PXI RT Target. What we do is start some timed loops (TLs) and then we stop them after a while with the "stop timed structure" vi, from the timed loop structures palette. Whenever we need these services again on the target, we relaunch these TLs (the TLs are inside while loops. The while loops have a queued command state architecture and one of the states holds the TL for each service). What we see now is that after twe consecutive launches, the system "dies" (no more ethernet access) and the only way to resolve this issue is to reboot the PXI controller --> very similar to the problem in this topic!

The whole problem with this is that our architecture relies on the parallellism and synchronism of TLs. We can't just replace them with regular while loops because these can't be synchronized at their start very properly.

However, replacing the TLs with regular while loops works functionally but it's not OK for us... Who can help us?

We are using LV 2010 RT, FPGA

on a PXIe-RT-8133 controller.

best regards

[Che_T.]

Hi Stijn Schacht,

I'd recommend creating a new discussion post rather than reviving this old thread so that it's easier for us to track stats.  Feel free to reference this forum post in your new post.

Regards,

[Texas_Diaz]

Ethernet and the Timed Loop - an epic battle of priorities. 

Let's talk about this in terms of thread priorities and how things are serviced in RT.  Here are the priorities in RT from lowest priority to highest priority:

THREAD_PRIORITY_IDLE  <====== LOWEST PRIORITY

THREAD_PRIORITY_LOWEST

THREAD_PRIORITY_BELOW_NORMAL

THREAD_PRIORITY_NORMAL

THREAD_PRIORITY_ABOVE_NORMAL

THREAD_PRIORITY_HIGHEST

THREAD_PRIORITY_TIME_CRITICAL  <====== HIGHEST PRIORITY

Ethernet on RT is split up into two services; receive and transmit.  Receive is serviced by threads running at a priority of THREAD_PRIORITY_HIGHEST.  The actual Transmit thread is serviced at a priority level of THREAD_PRIORITY_ABOVE_NORMAL.  If you're running a normal WHILE loop, that code is running under THREAD_PRIORITY_NORMAL, so all transmit/receive operations are allowed to preempt the WHILE loop and network functionality is processed without problem.

A Timed Loop runs at THREAD_PRIORITY_TIME_CRITICAL - while the Timed Loop is running, it's starving all network activity.  If the networking were elevated to the level of THREAD_PRIORITY_TIME_CRITICAL, it would absolutely destroy the determinism in the system; therefore we cannot even consider doing this (sorry, the question I always get is, "Why not just run networking at critical level?" so I had to put that to bed quickly). 

Networking on RT is a non-deterministic operation, it should definitely never be done in a timed loop - if you think you need to do networking within a timed loop, queue the data you want to transmit/receive in an RT FIFO and process that FIFO from within a normal while loop.

Does this help answer your question?

-Danny

[Stijn_Schacht]

Hi Tarantula,

tnx for your answer but apparantly we found the true reason for our problem: you cannot abort timed loops and then restart them --> this will freeze your system.

You can however stoptimed loops via the stop terminal and them restart them. Aborting them will cause system freeze when relaunching the service.

You can however abort the system clock (if they use a shared timing base). This will not freeze your system during restart of the timed loop.

Isn't that weird? Nonetheless, we are very happy to have found a work-around...

best regards