04-03-2018 01:31 AM
Hi!
I developped a big application under Labview RT. This application is made of different modules. Each module has a specific function (e.g. Log, recording...). To communicate between these modules i use RT FIFO.
These architecture works pretty good, but sometimes without any reason, i received the error -2206 (LabVIEW: RT FIFO does not exist.) when i read data from a FIFO. I'm sure i didn't delete the FIFO (all FIFO are deleted at the end of the program). Moreover if i ignore this error, and read the FIFO data again, it works (without opening a new reference to the FIFO).
I searched on different forums and i found this subject : https://lavag.org/topic/11372-crio-tcpip-problems/#comment-68414.
It seems i have the same problem, sometimes, the FIFO return an error without reason. Does anyone has an idea ?Or had the same problem ?
04-03-2018 07:42 AM
Hmm. I "learned" that RT-FIFOs were designed to (extremely-rapidly) get data out of critical Timed Loops to keep the "RT" side of the acquisition running at the desired speed. In my code, the RT-FIFO is the "link" between a three-tiered Producer/Consumer Design:
The point is the only place an RT-FIFO is used (in my code) is to get data out of the RT-Timed Loop and into parallel Queue-transporting Processing loops. This includes sending data between sub-VIs (using either Named Queues or "Wireless" Queues). As a result, there's only a single RT-FIFO in my large Acquisition/Control routine, but multiple Queues (and Network Streams) ...
Bob Schor
04-03-2018 09:05 AM
Hi Bob thanks a lot for your answer!
I used RT FIFO instead of queue in order to prevent access to memory manager. In my application i tried to limit the build array, and more generally all fonctions that can allocate memory to prevent priority inversion...
At the begining i used this mechanism only between 2 modules, and i decided to generalize this to the whole application.
As I said, it works ... but sometimes i get this damned error! For the moment, i ignore the error, but i hope there is not a hidden problem with RT FIFO (number limitation, error if two functions access the FIFO at the same time...)
That's why i ask for some feedback....
07-29-2020 10:06 AM
Old thread, but I've encountered this same "phenomenon" where error -2206 appears to occur for no reason (LabVIEW 2018 RT). The FIFO is NOT being deleted and is being accessed (written to) in another timed loop with higher priority just fine. My read loop produces this error which apparently can be ignored with reading being successful the next iteration. I've used RT FIFOs for many years and this is the first time I've run into this issue so it seems quite niche. My use case is (roughly): timed loop #1, priority 100, writes to FIFO every 1 msec; timed loop #2, priority 60 reads from FIFO in a normal while loop (within the timed loop) with a 10msec timeout (i.e. it roughly reads 10 elements at a time and processes them). The read FIFO will produce a -2206 error very infrequently.
07-30-2020 07:54 AM
I'm fairly confident this issue occurs when a potential priority inversion is encountered. This error only occurs in my write timed loop that includes VISA communication that may execute at a lower priority than my read loop. I'm suspecting the FIFO encountered a potential priority conflict and returns the -2206 error to indicate that the FIFO is currently "not available".
08-31-2023 03:58 AM
Hi @Inertia,
I just found out about this issue when reading code from my colleagues where they systematically ignore error -2206 after reading an RT FIFO.
Since you have dug into this problem, have you by any chance reported this as a bug to NI ?
Just to know if NI is aware of that and if there is an official workaround ?
Regards,
Raphaël.
07-17-2024 09:41 AM
I haven't seen an update on this. I am using LV 2020 RT on a sbRIO-9629 and just encountered this. I have several timed loops running on different processors. I am using an RT FIFO to transmit Fault codes to a parallel loop datalogger (which is not a timed loop). It is not very much information ( basically every once in a while a writer would send a single element to the FIFO). The read loop is much slower but will read all the available elements when it isn't empty. Does this in a for loop with no wait. So the idea is that if there are 5 elements, it will quickly read all of them out and then log it to its log array and then later (every 30 secs log that to disk). I have some writers that work. For example a System Loop (Timed Loop at 50 ms) on Processor 1 at Priority 900 that works. Another Steer Loop on Processor 2 at 10 ms on Priority 4000 that gets this -2206 when sending a single element. I changed the timeout from 0 which it was previously to 10 ms in the writer and it didn't help. Does the Priority of the Timed Loop or which Processor it is assigned to affect. I am getting this on the Writer not the Reader so maybe it is different than this thread but it feels like the same. Something with Priority inversion.