Tcl and Labview
love_expect
in a real time.
Has anybody ever used Tcl and Labview together?
I would need to invoke Labview applications from Tcl and be able to
pass arguments and control statements to Labview applications on the
fly. Is this possible and how? Are there any tcl extensions that can
be loaded as a package and used to do this?
Thanks for your help.
Chengye Mao
You may use Tcl and Labview together through Tcl and Labview's C
interface. One method is to embed Tcl in a Labview's C DLL. I am not
sure how to invoke Labview's functions in Tcl, which may not be easy.
Just curious, why would you like to use Tcl and Labview together? I
doubt there are any benefits to use both Tcl and Labview in
applications.
love_expect
I have received some automated tests that are done with the Labview. I
would like to integrate these tests with my Tcl tests so that I can
run all of it from the Tcl/Tk. I would like to avoid writing many new
drivers for my test equipment using tcl because I already have it in
the Labview.
Can I integrate Labview using tcom package (what are the limitations?)
or maybe using DDE, even though that might be too slow (still working
on this)?
seck@google
I'm currently under-taking a similiar effort. The difference being
that I'm using LabWindows/CVI to spawn a Tcl/Expect interpreter,
process the identified Tcl/Expect script and then process the response
via a log file etc.
john
Chengye Mao
>
> I have received some automated tests that are done with the Labview. I
> would like to integrate these tests with my Tcl tests so that I can
> run all of it from the Tcl/Tk. I would like to avoid writing many new
> drivers for my test equipment using tcl because I already have it in
> the Labview.
> Can I integrate Labview using tcom package (what are the limitations?)
> or maybe using DDE, even though that might be too slow (still working
> on this)?
I don't known if Labview has a COM interface. If it does, then TCOM
is the right tool to integrate your application. I will not use DDE.
Leslie Brooks
Mixing TCL and LabView can be very useful; you can take a LabView
program someone else wrote and automate it without changing it. Your
TCL program can "reach into" the LabView VI and push buttons, twist
knobs, set values, read displayed values just as the user would do -
all without changing the VI. You do need the VI to be built with the
COM Server option turned on (if it is built into an EXE). If you have
the VI source then you don't need any special options.
Here is an example that uses the "Frequency Response" VI which is
installed as a standard example (in the Examples directory) when you
install LabView.
#
# Interfacing to LabView via TCOM
#
package require tcom
#
# Start the "Frequency Response" VI as an ActiveX server. (If the VI
was
# compiled then you would refer to it by its registered server name.
For
# example, if you compiled 'A.vi' and created 'A.exe', then you would
load
# it with 'set lv [::tcom::ref createobject "A.Application"]'.)
#
set lv [::tcom::ref createobject "LabView.Application"]
#
# Create a reference to the VI. (You may want to use
# '[$lv ApplicationDirectory]' to get the correct path for this PC.
# For a compiled VI, use just the VI's name, for example:
# 'set viPath "A.vi"'.)
#
set viPath "D:\\National
Instruments\\LabView\\examples\\apps\\freqresp.llb\\Frequency
Response.vi"
set vi [$lv GetVIReference $viPath]
$vi FPWinOpen True
#
# Create the parameter arrays. The first array is a list of terminal
names;
# the second array is a list of their values. We must pass in a value
for
# every terminal on the VI's connector (unless we are very sure that
the VI
# has a valid initial value for that terminal). We must also pass in
a
# value for the output terminals; LabView will ignore it.
#
set names [list Amplitude "Number of Steps" "Low Frequency" "High
Frequency" "Response Graph"]
#
# Create the values array
#
set values [list 5 105 15 1005 0]
#
# Call the VI and get the results
#
$vi Call names values
#
# The Response Graph is returned in 'values'
#
puts $values
#5 105 15 1005 {{400.0 406.238291234 412.573873162...
#
# If the VI is running we cannot use the 'Call' method, but we can
# set and query individual Controls/Indicators. (The "Frequency
# Response" VI does not continue running - you call it, it runs, then
# it stops until you call it again. However, many VIs run
continuously
# once you start them, and many are set to start running as soon as
you
# load them. Obviously, compiled VIs typically start running as soon
# as you load them.)
#
$vi SetControlValue "Low Frequency" 5
$vi SetControlValue "Amplitude" 10
$vi GetControlValue "Amplitude"
# 10
#
# The graph hasn't changed (because the VI isn't running), but we can
# still read it. Notice that the graph is an Indicator (not a
Control),
# but we still use the 'GetControlValue' method to read it.
#
set new_graph [$vi GetControlValue "Response Graph"]
#
# You may need to manipulate the VI's menus. Unfortunately LabView
does
# not expose any method for doing this, so you must use the Windows
# Scripting Shell. The <ESC> key does not seem to work this way, so
# the menus should have shortcuts that use ALT or Ctrl key
combinations.
#
# Start the Windows Scripting Shell and send an <ALT> key to the GUI
#
set WShell [::tcom::ref createobject WScript.Shell]
$WShell SendKeys %%
$WShell SendKeys {DOWN}
#
# Send Alt-X
#
$WShell SendKeys %X
#
# When we are done, we may want to shut down the VI.
#
$lv Quit
Chang Li
Where can I get the LabView Demo to test your example?
Chang
Chengye Mao
> no_ca...@yahoo.com (Leslie Brooks) wrote in message news:<49cf05ac.02021...@posting.google.com>...
>
> Where can I get the LabView Demo to test your example?
>
> Chang