holding values in False case

[NickDngc]

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?

[crossrulz]

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.

[NickDngc]

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.

[david1147]

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

[crossrulz]

---

@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.

[NickDngc]

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.

[NickDngc]

---

@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.

[david1147]

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.