Programmatically detecting Plot Visibility Checkboxes in LabVIEW

[AzhStark]

Hi everyone,

I have a question regarding a part of a program that I'm working on which is about capturing data from an oscilloscope.

The program needs to be able to capture multiple analog signals from multiple channels of the oscilloscope and get the waveform characteristics such as rise time, frequency, peak to peak etc.

The displaying of multiple waveforms on the graph is achieved through enabling all channel inputs and using Plot Visibility Check boxes.

What is required now is to know which plot(s) are enabled so that their waveform characteristics can be displayed.

My goal is to identify the enabled plot(s) and display the data accordingly.
e.g. When Channel 1 is checked, only the data of Channel 1 should be displayed and the data of Channel 2 should display 0. And vice versa.
Additionally, when both Channels are selected, data of both channels should be detected.

In order to achieve this, is there a way to programmatically detect the action of Plot Visibility Checkboxes?
As in, is it possible to programmatically know which plot is displayed on the waveform graph?

If there is any alternative method to get the same result, please let me know. Your help would be appreciated.

I have attached the segment of code relating to this issue.

Software, Drivers and Equipment used:
* LabVIEW Ver.2015
* Agilent 2000 3000 X-Series Driver
VISA Resource Name: USB0::0x0957::0x17A4::MY53160161::INSTR
* Agilent Technologies DSO-X 3034A (Keysight Technologies) Oscilloscope
* SG1638B 2Hz-2MHz Function generator
* Toshiba Windows 10 PC

[RavensFan · Accepted solution]

Cycle through all the plots and check their visibility property.

[crossrulz · Accepted solution]

---

@AzhStark wrote:

In order to achieve this, is there a way to programmatically detect the action of Plot Visibility Checkboxes?

---

[brentjustice]

The plot attribute change event does indeed actually fire off when plot visibility changes.

The weird part is that visibility is not in the list of attributes returned by the event data.  This has always seemed like an oversight, or maybe a bug.  Regardless, you can infer that the event was a visibility change if the NewVal and OldVal attributes are equivalent