James,
The "remote address" terminal was a good idea. I tried it yesterday, then
tried again this morning to make sure I didn't miss anything, but it doesn't
work. I placed an indicator on the front panel and the remote address field
stays empty. The reomte port indicator does changes to indicate when a
connection is made.
This test program: A random number generator sits in a while loop, while a
TCP Wait listens for a connection. When a connection is made, the while
loop runs transmitting a new random number each iteration. This is
randnumRT.vi. A separate vi, randnumHOST.vi, has a waveform chart and a
digital indicator. When this vi is run it uses TCP Open Connection to
initiate a connection, then reads the incoming data, displays the number,
and plots it on a chart. I have a string control that lets me choose which
device i can connect to. By specifying "localhost" I can run both VIs on
the HOST-PC, or both on the RT engine. If I start the randnumRT.vi on the
RT engine, I can restart LabView on the HOST-PC, specify "DAQ::1" and have a
connection from HOST-PC to RT engine. The remote address indicates
"localhost" when both are running on the HOST-PC, otherwise it remains
empty.
Why initiate from the RT?
In the application that i am trying to build we will need to be able to log
the data to a file. Since the RT engine has no access to the disk, there
must be a communication line to the HOST-PC. I would like for the RT VI
tobe able to run and function completely whether ot not the operator wants
to save data. But if data storage is desired then the HOST can already be
waiting to receive a new connection and save data. I would rather not have
the HOST open a connection and just sit there passing the time.
So what is the application?
Our facility does research on different tillage tools and use a variety of
transducers ot collect the data. I am trying to design an application that
will be versatile enough to handle a wide range of transducers without a
need to change the program. If one test calls for 10 transducers and the
next calls for 50 the application should handle each just as easily. If one
test calls for 10 samples/sec, and the next calls for 200 the application
needs to handle both just as easily. So here is my vision....
A test operator uses the HOST-Acq program to build a parameter list which
details the transducers, their scale factors, a desired range for each, and
a channel number. From that list he builds a display file, specifying how
many charts to view DURING the acqquisition, and which channels to view on
which chart. These two information sets are transfered to the RT-Acq
program. Then the operator enters a filename for incoming data if he will
be collecting data, and this status is also sent to RT-Acq. He then tells
the HOST-Acq he has completed changes and transfered the information and is
ready for data. (At this point the HOST-Acq front panel would be disabled
except for a CANCEL-DATA button.)
The RT-Acq program will configure the analog (and possibly digital)
channels, and the operator choose a sample rate. The analog and digital
start will wait for triggers from the operator (either a front panel button
or a hardware input). If data collection is on, this trigger will also open
a TCP connection and transmit data as it is collected to the HOST-Acq. The
operator wil be able to view the data during the acquisition.
When the trigger is released, the TCP connection is closed, and the operator
resets the HOST-Acq to prepare for new data.
Why not use the RT shared memory features?
Because I didn't fully understand them. I have asked NI when they are going
to offer a course on LabVIEW RT. Essentiall it is the same as non-RT
LabView, just with the added complication of NEEDING to cross from PC to RT
engine. Others with stronger programming background would probably have
been able to use shared memory much easier than I can. Programming is not
my forte, so I am learning concepts, while strugging with syntax, and wading
through methods. Not to mention the endless worry that there is a more
efficient way to do something. Of course.... none of this is set in stone
just yet.
Why use RT at all?
Eventually we also plan to use this system for PID control of some heavy and
possibly dangerous equipment. It wil be imperative that we have the best
possible control, and the quickest response times possible.
>>> "James Kring" 05/10/00 07:34PM >>>
Dexter,
As you may know "DAQ::1" is the TCP address of the 7030 cards RTOS, when
connecting from the host PC. I don't know off hand what the Host PC's TCP
address is, with respect to the RTOS. To find this out run the example RT
TCP Communication VIs that ships with LVRT (TCP-RT Engine.vi and TCP-Host
PC.vi). On the "TCP Listen.vi" (in TCP-RT Engine.vi) there is a terminal
called "remote address". Capture this address when a connection is
established
and you will have your answer. A different approach to your main task is
to have TCP Listen.vi on the RT card and establish connections from the host
PC. Basically you would have the host PC ask LVRT if the task was done,
instead of waiting for it to tell you it was done. Switch the server to
LVRT instead of the host PC.
-Jim
PS - my girlfriend works for the usda in Albany, CA near UC Berkeley. What
is your application? I recently did a project using LVRT with the same card
you are using.
-------------------------------------------
Jim Kring, Project Engineer
Cal-Bay Systems, Inc.
"Solutions for PC based
Instrumentation and Control"
jkring@calbay.com
http://www.calbay.com
-------------------------------------------
