Modularized programming - problems with multiple analog inputs on single DAQ

[VeeJay]

Hi Guys,

please find attached screen shots of my program's main vi and one of the many subvi's . I have used State machine concept to run different states (shown) and each state as shown has subvi's running. In the shown screen shot of Main, the Start Protocol case has three subvi's running.

Since I can create only one task for multiple analog inputs, I created the analog input task in subvi_1 (screenshot). some Values read in this subvi are sent to other subvi's by using references. when the program is running, sometimes what happens is that random values appear on some of the analog channels and my error notifications trip and the program stops. This goes away when I remove on of the analog channels and just measure 2 instead of 3. Why is this happening? I assume there is some problem with respect to sampling rates. I use DAQ 6008. Can someone explain sampling rate with respect to analog inputs? My understanding is a little muddled.

Also, on an other note, Is this a good programming method? Should I create tasks in main vi as opposed to creating and using tasks and channels in individual subvi's?

I would appreaciate any help and resources to good modularized programming methods.Thanks!

Vj

[VeeJay]

Also, Is using reference a good way of communicating between layers of vi's? I have read little about using VI server ? Would this be relevant in this case? Or would you think opening the subvi reference in main would work or is it the other way around? Too many questions.... 🙂 But thanks for taking time to answer them ;)!

[johnsold]

It is hard to tell what is going on in your VIs because of the size of the diagrams.  Try to keep them to the size of one screen.

Value property nodes tend to be slow and force the thread to execute in the UI thread.  Rather than updating all the indicators on the Main VI from the subVIs, you could use Action Engines or queues to pass the data from the subVis to the Main.  Then you connect to the terminals with wires.  Wires are almost always preferred to using property nodes (references).  If Value(signaling) is required to trigger an event case, then use the property node.

Lynn

[VeeJay]

HI Lynn,

Thank you for your response. I have a couple questions though.

With regards to the way I am updating information on "Main vi" from "Subvi", you say that it is not a good idea to use property nodes. Where can I look up examples for action engines? How would a queue work in this sense? I get queues for parallel while loops, but in the case of "main vi" and "subvi" it is more of an hierarchy, correct? How do I implement queues here? Examples would be great.

And with regards to my attachments, All I wanted to know is whether I am reading multiple Analog Inputs correctly. What happens in my code is that the "subvi Elev" reads all the analog inputs and passes values to "Subvi speed" by using references. Although I would love to create a separate analog input channel in the "subvi speed" ,I am unable to do so because USB 6008 only allows creating one Analog Input task.

Q? Now, would you think I should create tasks in "main vi" and and pass them on to "subvi" as opposed to creating them in "subvi's" . PLease refer attachment. I am using State machine for "mainvi". Thanks!

[johnsold]

VJ,

The best way is always to use wires.  Returning the data from the subVI through a connector pane terminal and wires is best.  If the subVI really needs to have user interaction, perhaps it should be in a subpanel with its own controls and indicators.

After looking at your Main VI diagram again, it appears that you have not taken full advantage of the state machine architecture.  I cannot be sure because I do not have the other states or the subVIs.  Rather than "Start Protocol" being a single state which does everything regarding your process, perhaps it should be subdivided into several states such as Elev, Start Motor, Stop Motor, Set Speed, Wait, Update Display, Save Data, ...  Some of these are generic because I do not know what your system actually does.

Search for Ben's Nugget on Action Engines (AE). That is the most comprehensive document available on AEs.

One way to handle systems which need to acquire data from one device and use the data in several places is to create an acquisition Vi which runs in parallel to the main VI and passes the data via queues or Action Engines.  The tasks could be created and used only in the Acquire VI.  The architecture of the Acquire VI itself could be a state machine.  I have used this type of structure several times without ever using a control reference to pass data.

Lynn

[VeeJay]

---

The best way is always to use wires.  Returning the data from the subVI through a connector pane terminal and wires is best.  If the subVI really needs to have user interaction, perhaps it should be in a subpanel with its own controls and indicators.

---

When you have a "subvi" inside "main", the only way i know to update "main- controls and indicators" is by using control reference from "main" and passing the value from "subvi" . I don't understand what you mean by "through a connector pane terminal and wires". I have the  "subvi" connector pane wired to the reference which is dragged from "main" to "subvi" front panel. Is this what you mean?

What ever user interaction is needed, I have made it available at the "main vi" level and the control values are passed down to "subvis" through references.

Ben's nugget is quite interesting, but I think it would take a long time for me understand what is said in there. I know it is going to be useful, but currently, I am finding it hard to understand what is said there.

VJ

[VeeJay]

 

One way to handle systems which need to acquire data from one device and use the data in several places is to create an acquisition Vi which runs in parallel to the main VI and passes the data via queues or Action Engines.  The tasks could be created and used only in the Acquire VI.  The architecture of the Acquire VI itself could be a state machine.  I have used this type of structure several times without ever using a control reference to pass data.

Lynn

---

Also, in using queues, doesn't it make the process more sequential than parallel; although we have parallel loops , one for acquisition and one for main vi.

[johnsold]

I suspect that we are not talking about the same things.  Looking back at the diagram you posted originally of the Main program, it appears that once the elevation subVI starts running everything happens through that subVI and you are passing references to many of the Main controls and indicators to the subVI.

When I think of modularized programming, I think of something quite different.  One VI, usually the Main, handles all the user interface - the controls and indicators.  All values are passed via wires to and from indicators and controls.  One subVI handles data acquisition.  The subVI never changes a front panel indicator.  It sends data to the Main via a queue or Action Engine and the Main wires the data to the appropriate indicator.  Similarly commands and parameters from the main are sent to the acquisition subVI via a queue.  Both the Main and the subVI are probably state machines which never stay in one state for more than tens or a few hundred milliseconds without checking for communications with the other VI or errors.  Some programs with more complicated requirements will expand this model to have several independent subVIs, each with their own queues.  But always only one VI deals with the front panel directly.

Lynn