Function like code block reuse

[shukui]

I am new to Labview and have some questions about code reuse and hope someone can help me. 

I have a Labview program that controls a spectrum analyzer, capture traces from it and saves to a computer.  Inside the program, there is a case that when a user presses the "Get Trace" button, the program will: (1) get the data from the spectrum analyzer; (2) prepare the file header and file name; (3) save the data in a text file; and (4) update the screen display.  What I'd like to do is to reuse this block of codes in other places.  For example, I'd like to add another mode that takes a new trace every 5 seconds, or change some settings and capture a trace with each set of settings.  I am used to programming in other language like C or C++, in which case I just need to make the "GetTrace" a function and call it where I need it.   How can I do that in Labview?  Or can I do that? 

As far as I understand, I can make a subVI, which will take some inputs, work on them and generate some outputs.  That doesn't seem to solve my problem, because I will have to provide a dozen also inputs and another dozen also outputs every time I use the subVI.   Can the subVI get its inputs and generate its outputs on its own, like a C funciton?  Can I pack the inputs and outputs so it works like a standalone module? If so, how?

Anyone willing to help?  Please let me know if you need more detail.  Thanks a lot.

Regards,

Shukui

[AKA_TG]

Based on your comment and

If I understand you correctly ..

I believe you can get the similar behavior if you set the input and output of your sub VI to Variant.

Then it is up to the code on each "side" of the VI to know what "type" of data is going in to and returning from the it

That would mean some significant thought to the architecture of the data structures (and the external processing code).

as well as building the variants to pass the message data construct.

With that in mind I don't really think it would be stand alone "as is".

It would have to be inside a wrapper of some sort. Then perhaps the wrapper could be stand alone like a facade or adapter.

Thus you'd also need a way to store this message in the variant along with the data and a way to get it at the other end.

"devil in the details" Since a variant can carry any and all data types and structures.

My idea is probably not too pretty though 🙂 Let someone else chime in with a better approach.

[CoastalMaineBird]

For maximum re-use, you want to compartmentalize things as much as possible.

I would start with the instrument controller.  Make that a module (subVI) with subVIs of it's own if need be, and have it do NOTHING but control the instrument.

It doesn't know about files, it doesn't know about displays, it doesn't know about headers, nothing but this instrument.

Give it a FUNCTION input which is like a command: INIT, CONFIGURE, CAPTURE TRACE, REPORT TRACE, SHUTDOWN, whatever functions you need.

Within that VI, do the various functions when they are called.  Use a WHILE loop with shift registers to remember things: the INIT function maybe makes a TCP connection and remembers the CONN ID in a shift reg.  The CAPTURE function later uses that CONN ID to send a command.

The one and only place where you generate actual instrument commands is in this VI.

The idea is that nobody talks to the instrument except thru this manager, and this manager code does nothing else.

Then make a separate manager to take the trace data and format it into the file that you need.

Next month, when you need to control the same instrument from a different program, you have the controller all built.

[aeastet]

You can take all of the inputs and put them into one cluster and the same for the outputs. If you do this you will only have one input and one output. Do you know how to use clusters? It is a really nice way to bundle up a lot of different data types and update them via one connection. You would just have to bundle and unbundle them inside of the vi.

There are many things that you could do here. You could make a loop that processes the data and send events or ques to it to get it to save data. You could make it into a subvi and send it information and save data that way too.

[CoastalMaineBird]

 Can the subVI get its inputs and generate its outputs on its own, like a C funciton?  

I don't know what you mean by this.  If you mean like a C static variable, then yes, you could store things in a global variable, call the function, the function gets things out of a global, and operates on it, but that gains you nothing, I think.

Passing things by wire is the fastest way.  If you have lots of things, make a cluster.  A cluster is like a C struct - a container with all sorts of controls or indicators within it.  You pass a cluster on a single wire.  If you use it in a lot of places, make a TYPEDEF for the cluster. That way when you need to add something to the cluster tomorrow (and you will), you change it in one place and all the VIs that use it automatically follow.

[AKA_TG]

ANother way to re-use code in LabVIEW is to create good state machine architectures that can be re-used and expanded upon.

(Action Engines they are called)  There is a lot of reading here on that topic. I believe all serious LabVIEW programmers use state machines.

A decent AE state machine, with error handling and proper shutdown built into it, is very valuable construct to have handy for

solving problems like yours.

For example  your driver must be used many different ways and do many diffewrent things. Therefore you need a way to take all the things to be done and break them down into manageable states.  Then your input to the VI will make happen all the tasks you need by calling the states it needs.  The state machine is then wrapped with your executive VI.

By making each state as simple as possible you increase the likelyhood for re-use.

[CoastalMaineBird]

I've never heard the term "action engine", but I use state machines all the time.  They're absolutely essential if you're controlling more than one instance of the same instrument.  

I have a blog post about that: http://culverson.com/state-of-the-machine/

Whether it's a state machine or not, though, it's best (for re-use purposes) to encapsulate the instrument functions into one VI (with subVIs if necessary) and have it be in charge of that (those) instrument(s).

[aeastet]

If you haven't read about Action Egines then you should read through this community nugget by Ben.

http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801

[Yamaeda]

" the program will: (1) get the data from the spectrum analyzer; (2) prepare the file header and file name; (3) save the data in a text file; and (4) update the screen display"

Sounds like (atleast) 4 sub-vi's to me. 🙂 That way you'll have small and nice interfaces for each. Just like i assume you wouldn't make the above code into 1 procedure in C++ with 20 parameters nor would you in LV. 🙂

/Y 

[CoastalMaineBird]

Well, "Action Engine" is Ben's term.  I've been using them, exactly like that, for 20 years.  I call them "managers". Same thing.