LabVIEW
creat subvi in larger DAQ PROJECT
@ramses64 wrote:
Hi,
I think you should search on your code parts that make the same thing, and that are used in many places : it is "useless" (just for code beauty) to use subvi if you don't use it in other places.
Refnums are easy to use, but code is hard to understand, and hard to maintain. you should use clusters to store your variables in a unique place, global variables... etc.
Hope this will help you.
Best regards,
Hi ramses64!
I beg to differ but I break the "code beauty" rule on a regular basis and I do so using control refnums. This image is typical of what my top-level VIs look like.
In the early days of LV when we only had (bearskins and stone knives) attribute nodes (look like property nodes but can only be used in the VI where the control lived) we had no choice and all interaction with the GUI had to be done in the top level VIs.
Those things were a mess since all fo the code had to be in the top-level VI. If your app did something complicated well the diagram looked like it.
But Control references have relieved us of that restriction and we can now write top-level VIs that look like top-level ideas like what mode are we in? etc.
The image I showed above is part of an album you can find here. Under each of those images (I invite you to view for yourself) you will find a link to where I first used those images in other threads. Those threads have a lot of words to further explain techniques for developing easy to read code. But before you chase down the original thread links review those images and ask yourself "Can I get an idea of what Ben was doing?" If so plese read on. If not forget I ever posted.
There are some "gothcas" associated with property nodes and I again invite you to search those out yourself but a short list follows.
1) many use UI thread which is single threaded so over use will give you bottlenecks that slow down the code.
2) Require mor work so keep the frequency of use down to reduce CPU demands.
3) Controls and indicators are I/O devices to show a value or get a value. They should not be used as a buffer.
4) For large data sets (highspeed chart updates for example) are best handled using the therminal for the FP object.
Just rying to help,
Ben
@dragon-long wrote:
In my project
I have many Producer consumer loops (one for control solenoid valve the other collect data from ni 9213 and Pressure transducer). I like to create sub VI to decrease size of block diagram.
Is there some good methods?
The basic method is analyzing and defining small segments of code that do a specific task. Often as small as 5-10 blocks. That's a good sub-vi which well be reusable, able to give a meaningful name and will reduce code size in the main program.
I've often seem people wrapping e.g. ActiveX calls/property nodes in separate vi's just to reduce size and get symmetrical/identical blocks. That might be going a bit too far, but in your case ...
Make sub vi's for each daq command, or an action engine to handle on objects command (if they're similar enough). How would that affect your code?
/Y
@ramses64 wrote:
Hi,
I think you should search on your code parts that make the same thing, and that are used in many places : it is "useless" (just for code beauty) to use subvi if you don't use it in other places.
Refnums are easy to use, but code is hard to understand, and hard to maintain. you should use clusters to store your variables in a unique place, global variables... etc.
Hope this will help you.
Best regards,
There are many good reasons to make subvis, even if the code you put in them is not used multiple times within your application. They make your code more compact, easier to read, and more organized. No subvis can lead to "spaghetti code" very fast.
@dragon-long wrote:
In my code, I need to use DAQmx in a while loop with other graph or digital display. Can I creat this kind of code as a subVI?
Anyway
I will thing about your advice
Sure, put the DAQmx read in a sub-vi, the read array as output, and connect to a graph.
/Y
