Structure and Performance Questions

[yoko911]

Hello good people.
I have this new project around, i need to build from zero some program they already have, this program is an electric test program, they test rotatory sensors (potenciometers), so they control several things from labview:

• Encoder - Motor <- Servo
• Electromagnetic Clutch
• Hipot
• 1 or 2 Adquisition cards
• RelayBoard
• etc.

So as you may see it has many things connected in between, getting myself courius I saw the BD, it was a mess, they didnt have any structure, maybe 3 o 4 subVi and that because they are provided by the servo manufacturer (my guess), they did a state machines, bbut using nested stacked sequences

Leaving introduction aside, my questions are:

• if I create a lot of subvi just to have a smaller BD would it be better? im thinking with all the calling and whatnot
• what its better, having 10 subVi on my BD, or having the source code from the same 10 SubVi on the BD, the first will look better but performance-wise?, is that "cost-efficient"?(Having performance reduced but a well structured code).
• using a lot of subVi, how can i distribute my code, i dont need and aplication(EXE), i just what to sent them (client), all the VIs, well everything is inside a project, but every SubVi should be on a library? 
• One of the specifications, its to use a Produces -Consumer structure, its that apropiate for this aplication?, maybe a "state machine producer consumer" structure?
• Im no expert in LVOOP, but i know OOP, Im thinking using LVOOP will make coding easier when the program gets bigger, what do you think.

Thank you in advance.

PD: sorry for any grammatical errors 

[altenbach]

Performance issues due to subVI overhead are typically negligible and nothing to worry about. The gain in code clarity and modularity easily makes up for it.

If you want to eliminate the subVI overhead entirely, you can inline the subVI (recent LabVIEW version only).

[crossrulz]

It's hard to make comments about what structures to use when the spec is non-existant.  So I'll avoid architecture comments.

As was said, calling of a subVI is so little overhead that it is just not worth worrying about.  I've seen this personally.  And that was many years ago I did those tests.  Things have just gotten faster since.

Look into VIPM for distributing your code.  Either that or use the Source Distribution build spec to put all of your code into a zip file.

To avoid conflicts with your clients other projects, I would recommend putting your VIs into libraries.  Do not make libraries for the sake of making libraries.  Make logical groups of VIs into a library.

In general, make things simple for your client to use.  Putting in a little extra time now to simplify things for the end user will pay off later on.

[Luis_CT]

Hello yoko911,

Answering your questions:

• if I create a lot of subvi just to have a smaller BD would it be better? im thinking with all the calling and whatnot
There is no impact in execution performance, but as altenbach says it is always better to have modularity when you develop software applications so that when you have to make small changes to it you don’t have to rewrite “all” your application almost from scratch.

• what its better, having 10 subVi on my BD, or having the source code from the same 10 SubVi on the BD, the first will look better but performance-wise?, is that "cost-efficient"?(Having performance reduced but a well structured code).
Answer related to the previous question. The advantage in using SubVIs is that you can use them instead of having repetitive code within your application allowing to save resources in your code and maintaining modularity in your project.

•using a lot of subVi, how can i distribute my code, i dont need and aplication(EXE), i just what to sent them (client), all the VIs, well everything is inside a project, but every SubVi should be on a library?
I suggest you to create a project and create virtual folders and group your Vis in them so that your customer can easily identify similar VIs or somehow correlated.

• One of the specifications, its to use a Produces -Consumer structure, its that apropiate for this aplication?, maybe a "state machine producer consumer" structure?
Cant answer this question, as crossrulz says, we need more information and requirements in order to determine which architecture is the best for the solution

•Im no expert in LVOOP, but i know OOP, Im thinking using LVOOP will make coding easier when the program gets bigger, what do you think.
It depends, there’s not enough information to determine if an OOP architecture will be better or not it depends on how you develop the solution to tackle your customer requirements.

Hope you find this information useful!

Regards,

Luis C.

National Instruments

Ingeniería de Aplicaciones

www.ni.com/soporte

[yoko911]

Thank you everyone it was really helpful, and the questions you coudnt answer, well, maybe when im coding it i could ask again Thank you