VERY basic - how to decide what type of architecture to use?

[KDillon]

Forgive me if I'm breaking any forum rules with this post - I'm very new to this.

I'm trying to write a Labview program to perform a functional test on an electronic product.  The test is fairly sequential - plug in the unit, apply a certain voltage, step up the voltage until the unit turns on, then turn on an electronic load, measure the load voltage, then step up the input voltage again, etc.  The power supply and electronic load that I'm using both have Labview drivers. 

I'm brand new to Labview, and I have no resources in my company to help me out.  I have taken the Core 1 and 2 training class.  The problem is, I'm not really sure how to start.  Would this be a producer/consumer architecture?  A QSM?  I've been scouring these forums the past couple of days, but most of the discussions are advanced.  I don't understand all the acronyms.  A lot of the replies here assume you have some knowledge of Labview, and I don't.  Part of the problem is that I don't even know enough to ask a specific question, and that's why this post is so vague.

I'm a competent PLC/HMI programmer but don't have any experience in other languages.

I also want to be able to use variables for my limits so that I can easily change the pass/fail limits.  (For instance, I want the voltage and current pass/fail limits to be configurable from a "maintenance" screen on the Labview interface, but I don't know how to create multiple screens or password protect them).

[KDillon]

I forgot to add, I will be repeating certain steps often.  (For instance, verifying that the output voltage and current of the unit are within certain limits... I do this at least 3 or 4 times in the course of the test).  Does this mean a queued state machine would not make sense?

[aeastet]

I think that a QSM would be a perfect fit. If you need to do something like a voltage or current check then you just inject the check in the right place in the queue. This would also allow you to clear the queue once a condition is met. When the test is complete then clear everything.

you might need a producer and consumer loop construction as well depending on how far you go with your program. If you want real time display of your data points, data logging, our anything that would cause the upper loop to slow down enough to not control properly.

I would start with a QSM and work from there to see how complicated your system gets. Do your best to try and figure out what you need before you start so that you give yourself the best chance for success.

[Ben]

I have stated my opinion reagarding the QSM* design pattern previously and will not repeat it again here aside from "I avoid them like the plague".

Architecture questions are good question but hardly "very basic" although some architectures can be very basic.

I would recomend a State Machine that uses Action Engines to control your widgets.

in this thread AND this thread I wrote extensively and included design documents for apps I developed. I invite you to look those over and start developing your own design that meets your needs.

Ben

* It is imposible to fully document all of the possible transitions of a QSM and since my application all are fully documented, the QSM is not an option. A Queued Message Handler on the other hand is different.

[KDillon]

Thank you very much for your thoughts.

Does it make sense to create subVIs for different tasks?  For example, a subVI to check the output voltage and current against the limits established by the operator... a subVI to set the power supply output to a certain level... a subVI to set the current value of the electronic load... etc.?  Then if I found that a certain architecture was not working, I could easily change it.

[Ben]

Yes sir!

I just noticed something spooky. Your avatar is the same as the avatar as the user in one of those old posts. What is it about clowns and architecture?

No wonder litle-uns are creeped out by clowns.

Ben

[Jed394]

I'm just starting to move into more advanced labview programs and I think this is what I struggled with at first.  As your program grows, the sheer amount of sub-vi's and class methods you'll need get pretty large pretty quickly.  I think you just have to bite the bullet and realize that to make things easier in the long run, you are going to have to have a lot more sub-vi's.  It compartmentalizes actions, makes the code easier to read and make edits later on easier, in my opinion.

[aeastet]

That is very right. Then the next step is making modules that you just plug in and reuse. We have all kinds of reusable code. You have to think a lot about how you pass data, control and other things around.

[crossrulz]

As far as architecture, I fully agree with Ben.  A simple state machine to sequence your tests and Action Engines for your equipment drivers is the way to go.  Make each test a subVI.  Then any modularize anything you think you even might be able to reuse.  It will save you tons of time.  And lastly, make sure your directory structure is well organized.  I've inherited plenty of code that I could not find anything because the directory structure was completely flat.

[KDillon]

Perfect!  This gives me a lot to start with!  I didn't even know you COULD organize the directory structure.  I'll definitely look into doing that.

I don't like my creepy clown avatar, either.  I guess that's the price I pay for being a newbie...