LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Help with Event Structure

Hi,

 

I am trying to make a VI which is able to load a txt file for multiple VXM controllers then run the controllers simultaneously or one at a time depending on if the active button for the controller is clicked.  I have copied and pasted the same while loop seven times for each controller.  I am wondering if there is a limit on the amount of times I can run the controllers as I press on and off the activate button.  Additionally, I would really appreciate if someone could critique my code and see if there is a way for me to simplify / improve my current VI because I am still learning LabView.  I attached my VI and the driver for the controller below.  Thank you for any help you can provide.  

 

- Reese 

Download All
0 Kudos
Message 1 of 5
(1,938 Views)

Hi reese,

 

Especially if you might have more controllers in future, I'd suggest redesigning this so you don't need to copy and paste your module.

 

What you need is something that can run asynchronously and carry out some processes.

In the current diagram, that appears to be mostly the same for each controller (although note that your first loop has a True at the end, and your second has a False). If these should be the same, this is one good reason to avoid copy-pasting - code changes aren't propagated between different "modules".

 

You could instead look at creating a single VI that carries out the steps you need (0-5 in your Stacked Sequence Structure, for example - perhaps without the SSS but with dataflow used to sequence appropriately (might require some Flat Sequence Structures if you don't have e.g. 2017's "Stall Data Flow.vim", or a similar VI) and then launching clones of that VI for each module when "Active" is set true.

 

You could then have your event structure (singular) handle events and trigger behaviours via async VIs. In general, you don't want an Event Structure to spend long in any specific Event - it should run quickly then give any "slow" tasks (more than a few hundred milliseconds, perhaps?) to other loops/asynchronous systems.

 

An alternative might be to take a look at something like Actors (i.e. Actor Framework) but that would be a fairly large redesign if you're not familiar with them (or OOP?) and so probably isn't recommendable for only this purpose (i.e. it might be good, but probably more work than it's worth unless you want to learn about it anyway or for something else).

 

You could make Actor-like-objects (without Actor Framework) if you create a reentrant subVI that takes a message/data queue as an input, then send it messages to do things (i.e. run, stop). Then you'd have an array of queues and send a message to the appropriate one(s) in your main Event Handler. This is basically just a cloneable/dynamic Queued Message Handler (for which there are examples and templates).


GCentral
0 Kudos
Message 2 of 5
(1,929 Views)

I agree with @cbutcher that you need a "radical re-design".  I've got several routines where I needed to collect data from multiple experimental stations, each equipped with its own set of sensors, and to stream all of these data simultaneously to data files (and to appropriate Graphs and Video images) during the test.

 

You're not quite ready to go there yet, as you appear to not have much experience with modern LabVIEW programming.  What I'd recommend is that you concentrate on writing good code to handle one station.  Your code has (at least) two significant features that mark it as "not ready for Prime Time" -- you use a Stacked Sequence structure (which don't even appear on the Structure Palette of recent versions of LabVIEW) and you don't use the Error Line to serialize your code.  You should also learn better practices for writing sub-VIs, including:

  • (Almost) Always using the 4-2-2-4 Connector Pattern (it's the Default for a reason!).
  • Always wiring Error In and Error Out to the lower corner connectors.
  • Rarely have more than 2 other Inputs or Outputs.  [Clusters can Be Your Friend].
  • Your stand-alone VI could be based on something like the Queued Message Handler, a template for which ships with LabVIEW, or a State Machine.

Once you have a sub-VI that can handle one station, you can think about coding it as a Pre-Allocated Reentrant Clone, and using the Start Asynchronous Call to "launch" as many of them as you need, giving each one a unique identifier (call them 1, 2, 3, ...) and providing a communication path (Queues, Messenger Channel Wires) back to the Master Routine which does little more than start and stop the Clones, and perhaps allow you to view selected Front Panel data.

 

But first, get the code to handle one station running.  I recommend that you find a mentor or colleague who can work with you on this to help you ramp up your LabVIEW skills.

 

Bob Schor

0 Kudos
Message 3 of 5
(1,842 Views)

Thanks for your suggestions Bob and cbutcher.  I am currently trying to redesign my code by creating one sub-VI which loads the txt file to the VXM driver, one sub-VI which runs the txt file, and a main VI which displays the information I had before on my front panel.  One thing I am struggling to do is be able to send the port number from the main VI to the load sub-VI and then have the load sub-VI send the txt file to the main VI which can then use it for the run sub-VI.  Do you have an example that I can look at because I am having difficulty finding the right code online?

 

Thanks

0 Kudos
Message 4 of 5
(1,801 Views)

Your vxmdriver should be cut into separate vi's, one for each function. If you keep them in the same (which i don't recommend), you should have a type def'd enum as function selector and all functionality as different cases in a case structure, instead of having a boolean to select a function (what happens if someone sends several True inputs?).

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 5 of 5
(1,793 Views)