LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

holding values in False case

I have created an FPGA data acquisition application. One of the loops in the Host application reads data from the FPGA through a DMA FIFO and writes the values to a Mixed Signal Graph. The acquisition is done in a subVI that checks the DMA FIFO for an appropriate number of acquisitions (Number of Elements = 125). This comparison is fed to a Case statement; in the True case the Mixed Signal Graph (MSG) is updated, but in the False case the Graph should hold its current value.

 

Since I am using a subVI for the acquisition, the MSG indicator is outside all case statements. I need some way to write the last value to the indicator in the false case. Normally I would use a Feedback Node. However, the subVI includes another subVI that is called on First Run to initialize the MSG with Bus Names, Axis Names, etc. Using a Feedback Node causes the initial formatting to be immediately overridden while waiting for the DMA FIFO to fill up the first time.

 

My current solution is to use a reference to write back the current value of the MSG indicator, but the LabVIEW style guide discourages the use of references to update control/indicator values. Is there a more elegant solution?

Download All
0 Kudos
Message 1 of 8
(2,940 Views)

Why can't you just have your Feedback Node set to Initialize on First Call?  You then supply what the output should be for the initialization.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 8
(2,904 Views)

If you look at the left side of either png file, you'll see a subVI within a Case Statement controlled by a First Call? function. That subVI does a lot of graph initialization - sets axis names and ranges, sets plot names, controls bus display options. If I use a feedback node, whether initialized or not, all that formatting is immediately wiped out by the feedback node.

 

I guess the feedback node would work if I could programmatically control the initializer value, but the initializer subVI is called within the case statement after the initializer terminal would have been set.

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

It would be an option to split static configuration apart from the data. However, that would require some rework on the code..

0 Kudos
Message 4 of 8
(2,842 Views)

@NickDngc wrote:

If you look at the left side of either png file, you'll see a subVI within a Case Statement controlled by a First Call? function. That subVI does a lot of graph initialization - sets axis names and ranges, sets plot names, controls bus display options. If I use a feedback node, whether initialized or not, all that formatting is immediately wiped out by the feedback node.

 

I guess the feedback node would work if I could programmatically control the initializer value, but the initializer subVI is called within the case statement after the initializer terminal would have been set.


Have that initialization VI pass out the initial graph data and then use that to initialize your feedback node.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 8
(2,820 Views)

All of the formatting is done on the input reference via property nodes - it's passing the initial formatting versus passing actual initialization data. The output of the formatting subVI is a reference to the MSG, not the actual MSG; I can't connect it to the initializer terminal without using the "Value" property. I attached the subVI for ref.

0 Kudos
Message 6 of 8
(2,810 Views)

@david1147 wrote:

It would be an option to split static configuration apart from the data. However, that would require some rework on the code..



Yeah I guess that's my ultimate question -- is writing to an indicator using a reference and property node enough of a sin to rework the code? Adding shift registers to the calling loop is going to clutter up the Host application with extra wiring - not the end of the world, but I'm already pushing the screen size with an event structure UI loop and 3 parallel data acquisition/processing loops.

0 Kudos
Message 7 of 8
(2,806 Views)

Well, I personally don't think it is worthwhile. I don't see any other risk with this kind of coding style except that it is not a recommended dataflow format.

0 Kudos
Message 8 of 8
(2,775 Views)