LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Share instrument in loops

Hi,

 

I'm wondering if there's a way to share an instrument panel within multiple loops/cases in labview? Basically I'm trying to get an IV chart based on the test the user selects, the only way I can correctly get this to work is have an individual graph within each case. Obviously this is not ideal as it would require numerous charts on the instrument panel. I know there must be an easier way to do this but can't figure out how. Right now I only have an instrument for case 1 and have left the other 4 cases unwired for testing purposes.

 

Thanks,

 

Konrad

Download All
0 Kudos
Message 1 of 10
(3,280 Views)

We can't see your code since you password protected it.

 

What I would recommend is a separate loop just for writing to the graph.  You can send a command via a queue from the various test sequences.


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 10
(3,274 Views)

Oops, sorry. Here's an unlocked version. The problem I'm running into is that I take multiple measurements on the device in question, so it's already in a loop. I need the chart to update after each scan. When I then try and make alternate cases for different devices, I cannot "share" the instrument front panel and instead need to make seperate charts for each device.

 

Thanks,

 

Konrad

0 Kudos
Message 3 of 10
(3,265 Views)

Does this help?

/Y

 

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 10
(3,228 Views)

Would that work under multiple cases if I connected other data? What does that Feedback node do?

 

Konrad

0 Kudos
Message 5 of 10
(3,207 Views)

The feedback node feeds data back to the next iteration/loop. In this case you'll add a new graph every measurement.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 10
(3,170 Views)

Ok,

That helps, but is there also a way I can use that same graph on the front panel for multiple tests? Like, for example I have 4 different cases and each one has a loop that runs n times taking n measurements. I want to make it so that I can have the data pushed to one idividual graph from each case. So if a user selects 1,2,3 or 4, the data will all goto the same graph on the front panel.

 

Konrad

0 Kudos
Message 7 of 10
(3,160 Views)

The correct way would be to keep the measurement in a shift register and on a value change event send the measurement to the graph. The other possibility is to place your graph in an array of clusters and write/show different indexes.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 8 of 10
(3,151 Views)

So basically the event would push the data out of the loop if the values changed? Would the loop then continue until complete?

 

Konrad

0 Kudos
Message 9 of 10
(3,124 Views)

@niedk wrote:

So basically the event would push the data out of the loop if the values changed? Would the loop then continue until complete?

 

Konrad


The loop would be your main loop, taking measurements and/or reacting to UI changes until you close the program. Which would land in one of 3 designs (requiring more or less modifications to the current code):

State machine

Event driven program

Producer/consumer

 

I've come to like the producer/consumer a lot lately, though it's also the biggest modification. The 2 other ones can be quite similar, in the state machine the state is the main controlling information, and in 1 state (idle) you can have an event structure handling stuff. In the other case it's the other way around, the Event structure is the main controller and in the timeout or user event case you'll do your measurements.

 

In all designs you should have information going through the program in shift registers in the main loop so you can access it and avoid unnecessary controls/indicators/data copies and keep a good wired flow. 🙂

 

In this case i'd try the State Machine, with an type-defed Enum for states it's easy to expand and keep code modular. The states structure can be direct-, array-, queue- or event-based, but i think the direct form will be good enough, it's rather easy to change to one of the others, should it be needed.

 

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 10 of 10
(3,100 Views)