How to pick different chart labels based on a control?

[sbernie2]

Yep, I have managed to do that and hopefully it is working.

I used your idea, Bob_Schor, of employing an event structure looking for "measurement type changed?" to reset the graph and change axes labels. However, even though I stuck this structure within a loop that continually plots the data, it only seems to run once.

For example, I run the Vi, have it start the multimeter, begin data collection. Change type of data to be collected … plot changes labels (and clears, although nothings been plotted yet). Try to change type of data again... nothing happens.

Ideas?

[RavensFan]

Don't attach a picture that is just a screenshot of a tiny part of your program.  Too many important things are cutoff or hidden.

Attach the actual VI!

[cbutcher · Accepted solution]

RavensFan is of course right that a VI would allow a more confident diagnosis, but I'd guess that your Event Structure is running when you have an event, but then blocking the loop from iterating the rest of the time (or something similar).

I'm guessing this based on the fact that you're not doing all of the Event-dependent stuff inside the Event Structure. Inherently, this isn't a problem, but it makes me think there may be a problem with the loop iterations being blocked.

You also have an Event Structure in a Case Structure. Although again not always a problem, this is often a cause of unexpected/undesired behaviour. Probably you want a separate loop containing only the Event Structure, and references to the appropriate controls/indicators (e.g. the graph/chart - and as was already pointed out, they're not the same). Then do the data acquisition/plotting separately (although be careful for desynchronised updates if that matters to you - probably not given it should be for almost no time).

A basic example is attached.

[sbernie2]

I did not attach the VI before because it relies on a lot of subVis I did not create and do not wish to spend a long time explaining. The attached VI won't run without those but is partially annotated so you can guess at their function. It has a lot of other issues with it and needs to be restarted, yet again, besides the continuing graph/chart issue.

Credit for the source code and basic VIs goes to National Instruments, Tektronics, and Quantum Design Instruments, respectively. I did not create any of this.

[sbernie2]

It's working now, although it does require that you toggle the measurement function control once on startup before the y-axis label matches the selected option. I achieved this either by a) pulling the case structure out from inside the event structure for changing the axis label; or b) removing an event structure that all this used to be within, generally simplifying the program. Not 100% sure which it was.

Summary of changes: 

1.  Removed case structure inside event structure identifying change in selected measurement function.
2.  Used "NewVal" of the event structure to set the value of the axis label, instead of a case structure with a case for each option.
3.  Worked in a way to get the units from the multimeter and concatenate those strings with the measurement function labels.

Still got quite a bit of work to do, but my original question is now answered. Thanks, All!

Code credit to Tektronics (multimeter), QD Instruments (program MultiVu and PPMS machine), NI (multimeter instrument driver), and V. Morano (original combination of two drivers).

[RavensFan]

Thanks for attaching some sort of VI.  Even if it isn't runnable for us or has missing subVI's, we can poke around and see hidden things.

I do see one major architecture flaw that may or may not explain your problem,  but is certainly a problem in itself.  You have multiple event structures in that VI including one inside the another.  They are all set to Lock the Front Panel until the Event Completes.  That means if you execute a value change, but the event structure is in the path of execution, that means you will never be able to click on the front panel controls that would lead the that event being handled.  You will lock up your code!

Read Caveats and Recommendations when Using Events in LabVIEW - LabVIEW 2016 Help

Do you really need those event structures?

Stuff that is so nested and/or serialized is a nightmare as you can't guarantee the user will manipulate the controls in a way that guides the code through a vary narrow path of execution order.  This code should be rearchitected from scratch using a state machine architecture.

[sbernie2]

I posted this earlier but for whatever reason the post was rejected. It's working now, except it does require that the user toggle the measurement function control once on startup before the y-axis label matches the selected option. I achieved this either by a) pulling the case structure out from inside the event structure for changing the axis label; or b) removing an event structure that all this used to be within, generally simplifying the program. Not 100% sure which it was.
Summary of changes:

1. Removed Case Structure inside Event Structure identifying change in selected measurement function.
2. Used "NewVal" of the Event Structure to set the value of the axis label, instead of a Case Structure with a Case for each option.
3. Worked in a way to get the units from the multimeter and concatenate those strings with the measurement function labels.

Still got quite a bit of work to do, but my original question is now answered. Thanks, All!
Code credit to Tektronics (multimeter), QD Instruments (program MultiVu and PPMS machine), NI (multimeter instrument driver), and V. Morano (original combination of two drivers).

[cbutcher]

I didn't look at your code yet (posting from phone) but in general with an enum control, if you're using the value in an event structure but need the initial value for a starting setting, you can use the "New Value" element on the left side of the Event Structure inside your loop and move the actual control outside (click on one of the default visible items like Time or Source and change it or drag down to expand if New Value isn't visible)

Note that a case when you almost certainly should not do this would be when your control is a latching boolean (because the actual control must be read for the latching effect). But for an enum using the event structure provided value is fine (for a latching boolean, it's a little safer to assume an initial condition, usually false).