Script-driven Labview?

[Jeffrey W Percival]

I have a VI that we use in the traditional way, by clicking buttons on a
front panel. Sometimes, though, we need to perform a long and elaborate
sequence of control, which we would like to invoke via a script. The
script could be generated offline by some other app or could be a
manually edited file.

Is this possible? Has anyone created a labview/Tcl marriage?

Also, is it possible to keep a record of a session, and replay it later
if desired?

--
Jeffrey W Percival, Senior Scientist and Associate Director
Space Astronomy Laboratory, University of Wisconsin - Madison
1150 University Ave, Madison, WI 53706 USA
608-262-8686 (fax 608-263-0361) jwp@sal.wisc.edu
http://www.sal.wisc.edu/~jwp

[Labviewguru]

Jeffrey,

This is a very common application of LabVIEW (at least for me) and there are so many ways to do it, I couldn't even begin to scratch the surface.

I would suggest that you come up with a definition of your need, and if you can't figure out on your own how to implement it, consult your National Instruments rep, or hire a consultant.

Some tips that may help:

Test Executive (obsolete to some degree) and Test Stand are National Instruments' "scripting" applications. These are specifically designed for ATE testing and sequencing, but can be customized for other applications. Test Stand is a particularly nice product because it can also integrate other software 'tests' as well as use active custom programs in creation of sequences for comple
tely custom applications.

If you have further questions, please post them here, or feel free to email me. It would probably be better to post here, as you will get a broader range of answers, but if I don't get back to this post, please feel free to email me the question as well.

[Underflow]

For simple applications, scripting is easy to do using a state machine structure. An idle or default state is defined with a script reader. When the idle state is hit, the reader goes out and reads the next state and parameters from the script file, and places them on the queue of the state machine. Once that state is done, the reader gets the next line from the script, repeating until the script is done. I've used this method for simple automation of reporting using a program that is normally controlled from a front panel.

That being said, this method has a lot of limitations. Items like conditionals and passing results between states can become complicated very rapidly. Test Stand *is* an excellent program (it's used where I work), and is much more sui
ted to complex applications.

[kostya]

Jeffrey,

If you need to build a script driven application, you should have a
look at 'CalcExpress for LabVIEW'. It is a toolkit that has a script
processor designed to be used in LabVIEW applications. You can control
your VIs with the help of it. However, it is only for Windows and it
isn't free.

You can obtain more information at
http://www.kshif.com/calcexpress/

Regards,
Kostya

[Randy_H]

Jeffrey,

What did you want to do with LabVIEW and TCL? Did you just want to run a TCL script? If that is the case, you can use the System Exec.vi to launch wise.exe and run the TCL script. I have attached a quick example which I will eventually post a a full example program.

Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

[Jeffrey W Percival]

This posting got me to thinking about different approaches to scripting,
which I categorize as "labview running the script" and "the script
running labview". The state machine method below is an example of the
former. The VI is designed to read a script, interpret symbols, etc.
The latter, which may not be possible, is to imagine a VI that has no
knowledge of scripts, but is somehow
invoked and controlled from some external source.

Is the latter approach possible? Is that how Test Stand works? The
virtue of the latter approach, if it is possible, is that any legacy VI
can be used from a script; in the former approach, the VI has to be built
specially to do it.

-Jeff

Underflow wrote:

> For simple applications, scripting is easy to do using
a state machine
> structure. An idle or default state is defined with a script reader.
> When the idle state is hit, the reader goes out and reads the next
> state and parameters from the script file, and places them on the
> queue of the state machine. Once that state is done, the reader gets
> the next line from the script, repeating until the script is done.
> I've used this method for simple automation of reporting using a
> program that is normally controlled from a front panel.
>
> That being said, this method has a lot of limitations. Items like
> conditionals and passing results between states can become complicated
> very rapidly. Test Stand *is* an excellent program (it's used where I
> work), and is much more suited to complex applications.

--
Jeffrey W Percival, Senior Scientist and Associate Director
Space Astronomy Laboratory, University of Wisconsin - Madison
1150 University Ave, Madison, WI 53706 USA
608-262-8686 (fax 608-263-0361) jwp@sal.wisc.edu
http://www.sal.
wisc.edu/~jwp

[Dennis_Knutson]

Your second definition is how TestStand works. TestStand is a general purpose test executive. You create sequences of test steps (a script if you will) and the test steps can be written in any number of languages including LabVIEW VIs, LabWindows/CVI, DLLs, HP VEE, and even TCL scripts. It is extremely powerful and flexible. We converted from a custom LabVIEW application a couple of years ago and it was the smartest thing we ever did. Legacy LabVIEW code needed only small modifications in order to pass test results to the TestStand engine. You can download an evaluation copy by going here or you can contact your local NI sales
engineer.

[Jeffrey W Percival]

Ah, the magic word, TCL! So this is possible!

Maybe a few more words about our goals... we intend to use labview to control a fairly complicated scientific
instrument. We expect that knowledgeable users will sit at the front panel of a VI, and work the instrument "by
hand". You know, fire this pneumatic, move that stepper, open the shutter, etc.

I expect this top-level VI will have many sub-VIs that use various NI boards, like motion control, DAQ, etc. A
vanilla data-flow VI driven by a human operator.

At some points, though, the operator will want to invoke a long, canned, sequence of events. He'll sit there,
watching the blinking lights and listening to the whirring motors. When the script is over, he may start
clicking away again, or may choose to run another canned sequence of events.

Now, I envision these scripts coming (somehow) from a html form. My concept, still in its infancy, is this: say
some scientist, far away, fills out a web form. He chooses to ask for 10 exposures, each 20 seconds long, with a
filter change between each. He clicks "submit", a script is generated, and inspected somehow for correctness,
approval, etc. The operator receives a queue of such scripts, and fills his day with a mix of running things "by
hand", and also from these customer-generated scripts.

So,

1. Does this concept match any of the existing scripting models?
2. Is it possible to achieve this with a VI built without internal scripting code (i.e. using the external
executive model)?
3. Can scripts for various solutions be built easily, with, say, perl or other CGI-style tools?

Thanks very much for your ideas on this.

Dennis Knutson wrote:

> Your second definition is how TestStand works. TestStand is a general
> purpose test executive. You create sequences of test steps (a script
> if you will) and the test steps can be written in any number of
> languages including LabVIEW VIs, LabWindows/CVI, DLLs, HP VEE, and
> even TCL scripts. It is extremely powerful and flexible. We converted
> from a custom LabVIEW application a couple of years ago and it was the
> smartest thing we ever did. Legacy LabVIEW code needed only small
> modifications in order to pass test results to the TestStand engine.
> You can download an evaluation copy by going > "http://digital.ni.com/demo.nsf/websearch/8420757C000CFF3D86256AB9006FDC6C?OpenDocument&node=1457_US">here 
> or you can contact your local NI sales engineer.

--
Jeffrey W Percival, Senior Scientist and Associate Director
Space Astronomy Laboratory, University of Wisconsin - Madison
1150 University Ave, Madison, WI 53706 USA
608-262-8686 (fax 608-263-0361) jwp@sal.wisc.edu http://www.sal.wisc.edu/~jwp

[Labviewguru]

This is possible in Test Stand, though the interface may require some training, and I'm not sure it would be a piece of cake to go from the HTML "order form" to the Test Stand sequence.

However; a custom interface could be created in LabVIEW that could either allow for this functionality, or interface between Test Stand and the HTML scripts.

[Chevengur]

4 years ago I needed a fully embedded scripting capabilities inside the LabVIEW. We had many OEM products, and each of them required slightly different Calibration and Test setup. It took less than a month for me to write an object-oriented (device-oriented) Script Engine (interpreter, resembling C-Objective ). As a result, the time required to set a Test for a new model reduced from weeks to 20 minutes. The advantages of the approach are: everything is written in LabVIEW, thus, it is easy to control the whole process, it is free.
Some time ago, In NI Developer Zone I have seen couple simple examples of embedded Python.