Moderate to Large Application Design help requested

[jdebuhr]

So even though my profile states I have used LabVIEW for 10 years. The majority of that time was writing code to work within the large application that we were required to use. I had a few other projects that went outside of that realm, but it was in LV4.0 and LV5.0

When I started at my current job I had LV 6.0 and was required to write some test programs. the very first ones I did have come full circle and have changed as I have one basic shell type program that launches the individual VIs used for each circuit board we test. I am quite happy with that one at the moment, btu need to address 3 other Programs.

these 3 are unique with exception of sharing some configuration files and GPIB commands. I have the GPIB commands worked out to something that allows me to use my 20year old equipment as well as 1 year old equipment. They are in Traditional GPIB due to some PCs having IOtech non-VISA compliant cards.

These 3 programs have some user Display's on the main panel:

XY Graph

String Table

Instead of rewriting all at once, I am going to do one, then use as much of the code on the other 2.

Here is my current menu type set-up using Menu rings

-Test Setup

--DUT info

--Coupler Offsets

-Equipment Set-up

-- Analyzer

-- Sweeper

-XY Graph tests (plots 1 graph, then drops power, plots graph #2)

-Power output (reads power at several frequencies and returns power, Drops power takes on reading)

-Power output Port 2 (reads the same several frequencies at the current dropped power, Adds to the Table with Power output from Above)

-Print Data, takes all above data exports to Excel, saves and Prints

-Reset system defaults (Clears all values)

-Change equipment (allows user to change equipment info this is also launched when first executed)

-Load system defaults, (loads 2 text files)

It works fine, but I know I can make it better.. it was written in 6.0.1 and upgraded to 7.1 then 8.0.1 but I did not change much.

It is at the point now where it is runnign good and there is no current features to be added so I thought now is the best time to re-write it.

Some of the tests I have are currently sub-vis but I was thinking of dynamically loading/calling them as needed (Xy graph tests and Power output) I think an event structure would be the best for the menus, but how do I handle the Sub menus? they are a menu ring that I disable if you are not in that portion of the test.

Have have not had too much experience with Notifiers and Queues, would either of those work in some way?

There are so many features I have not really touched yet but alny suggestions would be helpful.

[Mike Ashe]

Backing up from the Test Executive stuff for a moment, you ask about menu and event handling, interVI communications (queues & notifiers) etc.

Might I suggest that you go on over to www.openg.org and get the OpenG Commander. Then, stop before you download the OpenG Toolkit and all the other available goodies.

Take some time to study the source code, architecture and style of the Commander itself. You will find great style and LabVIEW architecture principles all through it. Events, dual event/processor loop architecture, dynamic load/run, queues/comms.

Spend a couple days studying it, then see if it doesn't answer a lot of your issues above as well as provide you with a lot of code/snippets/VIs to use in your test systems.

Enjoy

[Chris Davis]

So even though my profile states I have used LabVIEW for 10 years. The majority of that time was writing code to work within the large application that we were required to use. I had a few other projects that went outside of that realm, but it was in LV4.0 and LV5.0

When I started at my current job I had LV 6.0 and was required to write some test programs. the very first ones I did have come full circle and have changed as I have one basic shell type program that launches the individual VIs used for each circuit board we test. I am quite happy with that one at the moment, btu need to address 3 other Programs.

these 3 are unique with exception of sharing some configuration files and GPIB commands. I have the GPIB commands worked out to something that allows me to use my 20year old equipment as well as 1 year old equipment. They are in Traditional GPIB due to some PCs having IOtech non-VISA compliant cards.

These 3 programs have some user Display's on the main panel:

XY Graph

String Table

Instead of rewriting all at once, I am going to do one, then use as much of the code on the other 2.

Here is my current menu type set-up using Menu rings

-Test Setup

--DUT info

--Coupler Offsets

-Equipment Set-up

-- Analyzer

-- Sweeper

-XY Graph tests (plots 1 graph, then drops power, plots graph #2)

-Power output (reads power at several frequencies and returns power, Drops power takes on reading)

-Power output Port 2 (reads the same several frequencies at the current dropped power, Adds to the Table with Power output from Above)

-Print Data, takes all above data exports to Excel, saves and Prints

-Reset system defaults (Clears all values)

-Change equipment (allows user to change equipment info this is also launched when first executed)

-Load system defaults, (loads 2 text files)

It works fine, but I know I can make it better.. it was written in 6.0.1 and upgraded to 7.1 then 8.0.1 but I did not change much.

It is at the point now where it is runnign good and there is no current features to be added so I thought now is the best time to re-write it.

Some of the tests I have are currently sub-vis but I was thinking of dynamically loading/calling them as needed (Xy graph tests and Power output) I think an event structure would be the best for the menus, but how do I handle the Sub menus? they are a menu ring that I disable if you are not in that portion of the test.

Have have not had too much experience with Notifiers and Queues, would either of those work in some way?

There are so many features I have not really touched yet but alny suggestions would be helpful.

If you haven't had much experience with Queues and the event structure you might want to start with practice on those since that is probably the two most useful tools to have when tackeling a large project (or even a small one). I don't know if you are using a state machine in your current program, but study up on those as well. Some decent examples can be found in the LV examples. Look for Producer / Consumer or Master / Slave architectures. There might also be a state machine example in the NI examples now which would help. I would start by making up a "scratch" VI or a practice vi where you can test out your ideas without all the code that you need to do the actual test(s). Then you can move from there to impliment the idea that you've refined with the code that actually executes the work.

:thumbup:

[jdebuhr]

Backing up from the Test Executive stuff for a moment, you ask about menu and event handling, interVI communications (queues & notifiers) etc.

Might I suggest that you go on over to www.openg.org and get the OpenG Commander. Then, stop before you download the OpenG Toolkit and all the other available goodies.

Take some time to study the source code, architecture and style of the Commander itself. You will find great style and LabVIEW architecture principles all through it. Events, dual event/processor loop architecture, dynamic load/run, queues/comms.

Spend a couple days studying it, then see if it doesn't answer a lot of your issues above as well as provide you with a lot of code/snippets/VIs to use in your test systems.

Enjoy

Thanks I will do that..

[mross]

The two best things that have happened to me over the last couple years were User Events and learning the Producer/Consumer architecture.

In your programs I have the impression that there is lots of user interaction. Obviously, you have a wide variety of tasks going on. I think you should conside a producer/consumer form with queues. I find that the P/C is very akin to a flow chart. If you have a good flow chart you are on the way.

In a nutshell you will have an event loop that responds to user input. Each user event will fire off a series of actions by loading the queue - enqueueing. A second loop or third or more, depending on how many parallel functions you need, dequeues and the case structure responds with the desired action. The case can enqueue further actions or just finish and wait (I usually enqueue a "Wait for user instructions" case to do the waiting.) Within the cases or the event loop you can make decisions based on states of the system and enqueue appropriate responses.

I could go on, but you should just try it.

MIke

[jdebuhr]

If you haven't had much experience with Queues and the event structure you might want to start with practice on those since that is probably the two most useful tools to have when tackeling a large project (or even a small one). I don't know if you are using a state machine in your current program, but study up on those as well. Some decent examples can be found in the LV examples. Look for Producer / Consumer or Master / Slave architectures. There might also be a state machine example in the NI examples now which would help. I would start by making up a "scratch" VI or a practice vi where you can test out your ideas without all the code that you need to do the actual test(s). Then you can move from there to impliment the idea that you've refined with the code that actually executes the work.

:thumbup:

Yep, I have messed with the queues and notifiers a little bit, but will exploer them in more detail. I almost always use a 'scratch' vi for trying new things, then either drop it into where I need it or build around it in a sense.

[jdebuhr]

Okay,

I have another couple questions.. I have done Event Structures and prefer them tot he State machine design I used in 6.0 when I first wrote these apps.

The question is with the queue design, are you able to have multiple Consumer loops and one Producer loop, if I understand it right the Event structur would be in the producer loop, that would handle my UI.

then if you can have multiple consumer loops what is the best practice to determine which consumer loop would run.

Meaning could I have a separate consumer loop for Dialogs, another for the actual tests etc?

EDIT: Also would i be able to set up a notifier within the Consumer loop? so if the Actual test get executed could I use a nofifer to do a task before continuing?

[mross]

Okay,

I have another couple questions.. I have done Event Structures and prefer them tot he State machine design I used in 6.0 when I first wrote these apps.

The question is with the queue design, are you able to have multiple Consumer loops and one Producer loop, if I understand it right the Event structur would be in the producer loop, that would handle my UI.

then if you can have multiple consumer loops what is the best practice to determine which consumer loop would run.

Meaning could I have a separate consumer loop for Dialogs, another for the actual tests etc?

EDIT: Also would i be able to set up a notifier within the Consumer loop? so if the Actual test get executed could I use a nofifer to do a task before continuing?

It is a data flow process. A consumer loop runs and completes when all the output tunnels are filled and continues if the conditional says so. All the while loop inputs must fill, then data flows to the dequeue Element function.

If there is an element in the queue, then that is dequeued and it feeds the case structure. The case corresponding with the dequeued element runs. etc.

If there is no element in the queue, then the consumer loop waits unitl one arrives, then it is processed.

Elements can stack up in the queue and they get processed when the consumer gets time, in FIFO order. OR if nothing is queued up by some other consumer loop or the event loop, then it waits.

This gets very useful AND messy when you have more than one queue and corresponding consumer loops.

A user evernt could queue up multiple operations in one consumer loop that are processed sequentially, or it could queue up several elements in differnent queues and corresponding consumer loops would run in parallel.

I hope you don't have to do all that the first go around, but it does work.

If that is still not clear then ask again.

Mike

[jdebuhr]

Thanks, that helps. It is how I was starting to understand it, but that explanation clears it up. That is the tough part of being the only LabVIEW guy here, no one to bounce ideas off of or ask opinions. Which is Why we are here right?

Anyway, I think I will be able to use one consumer loop, I don't need the speed of parallel loops, Although the parallel loops would be great for wirting my data to excel, while starting the next task...

So if I were to use 2 consumer loops, I would also need 2 obtain queues correct?? One for each consumer loop?

[crelf]

Thanks, that helps. It is how I was starting to understand it, but that explanation clears it up. That is the tough part of being the only LabVIEW guy here, no one to bounce ideas off of or ask opinions. Which is Why we are here right?

Sure is - and it's also another reason to get yourself down to NI-Week and have a beer with us!

[jdebuhr]

Sure is - and it's also another reason to get yourself down to NI-Week and have a beer with us!

Yes I would like to get to NIWEEK.. It is not going to happen this year though..

[mross]

Thanks, that helps. It is how I was starting to understand it, but that explanation clears it up. That is the tough part of being the only LabVIEW guy here, no one to bounce ideas off of or ask opinions. Which is Why we are here right?

Anyway, I think I will be able to use one consumer loop, I don't need the speed of parallel loops, Although the parallel loops would be great for wirting my data to excel, while starting the next task...

So if I were to use 2 consumer loops, I would also need 2 obtain queues correct?? One for each consumer loop?

Yes, that is correct. 2 consumers requires a lot more planning. You can also have a third loop that services both queues... It can get very ugly.

[jdebuhr]

Yes, that is correct. 2 consumers requires a lot more planning. You can also have a third loop that services both queues... It can get very ugly.

Cool that makes sense.. I should be able to do it with one Producer/ one consumer loop.

NOw to get planning..