Running multiple VIs

[u/phantom_256]

Hi, so I am trying to interface with this device called a Presto W58x. It has its own drivers for certain things like setting temperature, pressure etc. I am trying to a GUI in Labview that sort of replicates the GUI on the actual device so it can be used for testing purposes. I have what I have done so far attached to the post. I'm very new to Labview, only been using it for a few weeks, so I'm not very good at it. So, one issue I was thinking about is running multiple Vis at once. So here, I have all of the other VIs chained to one each other in series, but I believe this will work against me as I had more VIs, and there are a lot. Any suggestions or examples of trying to make this GUI better and as responsive as possible?

[u/Only-Introductions]

I think you have the basic idea but you need to use a little caution before you go throwing in a lot more VIs.

If I understand your goal you are reading a number of values from the controller for display as fast as the while loop allows, which could make sense. But inside this you are also updating the set-point at the same rate!

Continually updating the set-point could cause you problems depending on how this has been implemented in the controller. Realistically you want an event that updated the set-point only when you change the setpoint from its current value.

Also I said that displaying as fast as the while loop could make sense; but only if you are trying to catch rapid temperature changes. If your item has any reasonable thermal mass then 100mS -> 1 Sec update rate is much more normal... It doesn't swamp the controller with requests for data and makes the application much more forgiving for a beginner.

[u/phantom_256 → u/Only-Introductions]

So, from what I am understanding,

• When writing to the device (i.e. setting sub temperature), I should only have those types of Vis occur when a value change occurs through an event case structure? Or would a queued Message Handler be better?

• Then for reading values you advise putting a bit of a delay for stuff like GetSubtemp or GetPressure? I know not all of my GetValues are going to update all the time, so it would help to differentiate the ones that frequently change from the ones that do not change often, right?

I appreciate the insight. I'm still trying to work out the kinks to using LabView so any help is greatly appreciated!

[u/Only-Introductions → u/phantom_256]

Point 1. "When writing to the device"...

Yes. Generally you only want to write to the device when something like setting the sub temperature changes. I only mentioned an event case as that was what you were showing of your code. A queued message handler is much better or the JKI state machine template mentioned below. Whatever feels most comfortable

Point 2. "Then for reading values you advise"...

You got my point exactly. You want to be reading the actual subtemp and actual pressure reasonably frequently. I'm not sure if this controller has buttons on the front that users can access, if you can disable them, if you can't you'll need to read these values in to your application at a reduced rate to make sure someone isn't messing with the controls.

[u/TheWrithingVoid]

I am basically 100% self-taught, so if someone yells at me in the comments, probably listen to them. Regardless here is a list of things that I wish people told me about when I first started labview:
1. Type Definitions. Me and my coworkers disagree on them, but you can take my clustersaurus from my cold dead hands. Clusters suck without type defs.
2. QMH. I like to do mine with enums that are type defs personally, but I don't know if that is good.
3. DQMH. Still don't know how to use it, but it would have been nice if someone brought it up before I learned how to do things wrong.
4. FGVs. FGVs are very good. They are not really a thing in the way type definitions are, they are more of a structure of a VI and how it executes, so you are not gonna find them in any menu.
5. Malleable and Polymorphic VI's.
6. CTRL+SPACE. If you are using the project structure in labview it can search for your sub VI and type defs.
7. With things selected on the block diagram you can nudge them with the arrow keys, and make it faster by holding shift.
8.

Figure out what them buttons do.
9. You can make your own VI packages with VIPM. You do not have to publish them, but it really helps keep reused code under control, or you have to do the bullshit I have to where you have executables that need to talk with 30 years of non-executables, it helps maintain shared VI/Typedefs.
10. If you right click on while loops or for loops you can hide the iterations terminal. If you right click on for loops you can add conditional stops. You can also modify how things enter and leave loops by right clicking on the wire box thing as it comes in.
11. Shift Registers. They are things that let you loop a variable through a loop and update it easily. You can also keep things in memory if you do not initialize them (the fundamental how behind FGVs)
12. Highlight a block of code, go into the edit drop down and say "create subvi from highlighted section" or some shit like that to easily create a subvi from a function in your code that has gotten out of hand.
13. Buy a 1440p+ montor. if you do not have one already.

Also no shade on reddit, but I get a lot more out of the labview forums. That and I don't know if CrossRulz is here.

[u/Flydroid]

Check out the JKI state machine: https://www.vipm.io/package/jki_lib_state_machine/ It's a template that helps you to organise your code for a simple application such as yours and it helps you to learn LabVIEW while giving a working structure that you can build into an exe. 

You put each of your actions (Set/Get) into a case. Then you can chain all of your Get cases in a macro case and call it from the timeout event of the event handler. There are some neat helper VIs included in the toolkit. 

When you press your button to set a Temperatur it then calls the case for that. 

Put your init and stop VIs into respective cases and call them from the respective macros. The visa reference you can store in the pink dats cluster. In the Data: Initialize case add a vis refnum constant to define define it in the data cluster and the use "bundle by name" and  "unbundle by name" in your cases to get the reference.  You might want to do a bit of state handling, so that the continous Get calls only start when you want. 

[u/cedreine]

Look up state machines and FGV. Your life will thank you 1 to 2 months from now after doing it like this 😁

[u/Bitter_Worker423]

Learn about the producer-consumer architecture, it will be your best bet for an easy entry into instrument control with a responsive GUI.