LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RT FIFO Single Element Variable is still buffering....

Solved!
Go to solution

First off I am new to LabView and cRIO...Core 1, Core 2, and RT 1 completed online. No other experience.

 

I have a cRIO 9074 with some local I/O also talking Modbus TCP to several slaves. 

 

I gleaned from my training that for RT systems (timed loops with unique priorities) shared vars should have RT FIFO enabled. So in this case the variable in question is....

I32

RT FIFO (Single Element)

Network Published (although no NI front panel or other system is consuming it - only for acces via distributed system manager) 

 

I am seeing buffering within the cRIO and I am not sure why it is taking place. And it is not desirable.

I was watching data from my inverter on my HMI (both ModbusTCP slaves - neither NI products), and I unplugged the ethernet cable from the inverter - yet the data on the screen was still updating as if the inverter was connected. So either the screen is buffering data, or the cRIO is. To find out which, I modified the inverter config slightly to have a pulse train into bit 0 the I32 value. Thus toggling it 0/1. I then placed an AND gate that would also add the pulse train into a more significant bit so the toggling number would then be 0/16385. I could then manipulate the AND gate in the inverter to send 0/1 or 0/16385 into the cRIO at will.

I placed a probe on a variable that is the modbus input from the inverter within a vi that parses the modbus array into my variables.
I placed a probe on the very same variable (read access mode) that sends that data to the screen within a vi that packs vars into an array for sending out the wire to the HMI.

 

When I changed the magnitude of the toggle values, I noticed the input from the inverter changed immediately, while the output to the HMI remained on the old values (still toggling) - and eventually (many seconds later) changed to the new values. The longer the application runs...the longer the delay before the HMI bound variable takes on the current values from the inverter.

 

This variable is RT FIFO Single Element, Network Published. And as I understood it, single element FIFO variables did NOT buffer values. So if they are being extracted from a queue slower than they are being added (or not extracted at all in this cae)... the current value should just overwrite the queued value.

 

FYI: The behavior is the same with local I/O - I probed a thermocoule input from a 9213 module that is also sent to the HMI and it is buffered as well.

I also tried unchecking the RT FIFO option on the variable in question and saw no improvement.

 

Any help understanding this behavior and a means to eliminate it would be greatly appreciated....


 

0 Kudos
Message 1 of 3
(2,299 Views)

Hi S1ack,

 

Do you have network buffering enabled on your RT FIFO Single Element, Network Published Shared Variable?  It is an option under Network in the Shared Variable Properites window.

 

Regards,

Mike Altmann
Product R&D
NI
0 Kudos
Message 2 of 3
(2,272 Views)
Solution
Accepted by topic author S1ack

No, initially I did not.

I tried some experimenting with it enabled and the size set to one element.

In the end it seems to be a result of me failing to un-deploy, and re-deploy the libraries containing the variables in question.(problem vanished after I 'wiped' the cRIO using MAX and re-installing the software load)

I have been advised that with the number of shared variables in my project I should move to a CVT based method of distributing the variables between loops / processes. So I will be attempting that.

 

 

0 Kudos
Message 3 of 3
(2,264 Views)