How NOT to clear graph/chart between each VI run

[asukumari]

In most cases we would want to clear a graph to start with a new data acquisition. In my case, however, I would like to retain the previous cycle's values on the graph. The point of doing this being that I would like to see the state of transition between different cycles of acquisition. In this example different cycles of acquisition is analogous to executing one VI run.

The example here clears the graph every time I run the VI. Is there a way to set it to retain the graph from the previous run and explicitly clear only when the user wants to (which can be done using a property node and a Boolean control).

[altenbach]

The data is held in a shift register, so you would need an uninitialized shift register.

(Better use a state machine. A real app should not be started and stopped, be always running, and just transition from idle to active states)

---

@asukumari wrote:

(which can be done using a property node and a Boolean control).

---

No, graphs are cleared by wiring empty data to them or in this case clearing the data in the shift register. Clearing the control is short lived if the shift register still contains the data. (Charts can be cleared by writing to the history data property, but that's a different topic)

[asukumari]

I see, therefore adding an event structure to start and stop an acquisition is the right way to do it.

Attached is an example using uninitialized shift registers. The functionality still seems to be the same, it doesn't seem to retain the values from previous event. Is this because I am not passing the data between different events in the event structure itself?

UPDATE:

Added shift regs to while loop to retain the values. Did I do it the right way? It seems to work. Is there any other caveats I should be aware of if I am building a large app which may entirely depend on state machine architecture?

Thank you for directing me in the right direction.

[crossrulz]

---

@asukumari wrote:

Attached is an example using uninitialized shift registers. The functionality still seems to be the same, it doesn't seem to retain the values from previous event. Is this because I am not passing the data between different events in the event structure itself?

---

But you DID INITIALIZE your shift registers.  They are being initialized to empty arrays.  Uninitialized would be not wiring a starting value into the shift register.  Enjoy this little nugget for some clarification: Action Engine.

[altenbach · Accepted solution]

---

@asukumari wrote:

. Did I do it the right way?

---

Sigh! That "NiVerified" in the file name tells me that you scavenged that code from some posted example. In that case you should provide a link to it.

You did not attach the code version where you also use a shift register in the outer loop, but there you should decide if you want to initialize it or not. Depends if you still want to retain data between stop/run or if this is now a state machine that never stops.

In any case, that example is somewhat flawed and I don't like it at all.

• It is generally a bad idea to stuff lengthy code inside event cases. This deserved a producer-consumer architecture or similar. Locking the panel for 5 seconds is NOT nice to the operator.
• "build array" (in concatenate mode) is the preferred way to append 1D arrays (more obvious code, fewer unused inputs where the unwired defaults might confuse some)
• Since you exactly know the final array size before the FOR loop pyramid executes, you might want to do an "in-place" solution that allocates the entire array at once (e.g. with NaN) and then replace with valid data as you go.
• If you only want the final graph update, you could even use a concatenating tunnel, then append that to the data from the outer shift register. In that case, the graph terminal would belong before the event structure so it automatically clears when the VI is run, but no event has executed yet. In your current bottom version, the graph will show stale data until the OK button is pressed.
• That "Reinit to default" for the graph is just plain silly. Completely over-engineered.
• It is confusing to the programmer to rename the boolean text to "Run", but leave the label at "OK Button". Giving controls intuitive names is a big step towards code diagram clarity. You should hide the button labels on the front panel, the boolean text is sufficient.

[asukumari]

Yes that NI Verified was an example program (I assumed it's certified by NI to be a much cleaner minimal working example than the one I wrote )

Anyway, I will re-structure and try with Producer-Consumer architecture. The last 2 points you provided in specific are really fundamental to maintain code clarity and clean UI. Thank you !