贴个英文FAQ－通信（串并口，VISA，GPIB）
时间：12-13
整理：3721RD
点击：
Communications (back)
Serial
How do I find a single character in a serial input stream?
<Alex Le Dain alexATicon-tech.com.au>
(Timeless)
One method is to read all the bytes at the port. In a loop determine the
number of bytes at the port using the "Bytes at Port.vi", passing the number
of bytes to the "Serial Port Read.vi". Search the string returned using the
"Split String.vi" or the "Scan String For Tokens.vi". If the character is not
present, concatenate the read string with the data passed from the previous
read (via a shift register) and continue to concatenate the string until the
character is detected. If the character is present split the string at this
point, passing the complete string to the processing VI, while passing the
remainder of the split string back to the shift register to be concatenated
with the next loop iteration (so there is no loss of data).
(back)
Can I use a modem to send data?
<Mark Boettcher markbATminimitter.com, Dan White dwhite.cybermetrixATflexc
ell.com, Alex Le Dain alexATicon-tech.com.au>
(Timeless)
A modem can easily be accessed from LabVIEW using the standard serial
port VI's. This is a fairly simple task using the Serial Driver Init VI
directed to the port the modem's hooked to and send out the modem command
strings like:
"ATZ" - reset the modem
"ATFOO" where FOO is whatever special modem commands you want to send
"ATDT19005551111" to dial 1-900-555-1111
After this just clear a string and sit in a loop building a string with
whatever comes in the serial port until you get a CR character. Then search
the string for the substring, "CONNECT" (if attempting to access another
modem). If that's not in there, then repeat the process until either that
happens or you get a timeout.
Once the modems are synced, the data can be sent after flattening it to
string type. Make sure that packets of data are sent and if there are
integrity issues then perhaps a CRC checksum should be included in each
packet. If you want to disconnect then send out an "ATH1" to command to hang
the modem up and finally close the serial port.
One fequently asked question is whether a WAV file can be played after
initiating a dial out with a modem. No definitive answer has been posted, but
it appears you would dial out as above. Instead of a CONNECT string response
from the other modem, you could look at the return string which should
contain the "RING" string when the modem is in verbose mode and dialing out.
Once the RING string is not detected (or there are no other error messages)
then it may be reasonable to suggest that someone/something has answered. How
to play the WAV file is still an unanswered question apart from the inelegant
method of then initiating playing the file out the soundcard lineout into the
MIC of the modem.
Don't forget to send out a CRLF combination after every string you send
out. In other words strings would look something like: ATZ/r/n. Furthermore,
there needs to be a wait of at least 400mS for the "OK" return string after
initializing the modem with "ATZ" before attempting to dial with the "ATDT"
string.
There are also commercial toolkits available from Microsys Technologies
(see Other Links and Resources) and there is an article in the LabVIEW
Technical Resource (LTR, Vol 5(1)) that deals with sending messages to a
pager, but involves modem initialization and control aspects that would be
useful in setting up modem communications.
(back)
How do I use a modem to send an audio message?
<Jean-Pierre Drolet sinternaATtr.cgocable.ca>
(Sep 2000)
To send an audio message by phone you need a voice modem. Unfortunately
some of the commands required differ from one manufacturer to other. Thus a
VI done for a specific modem might not work for another type.
To have a modem independant interface you could also use the Windows
Telephony API (TAPI) on Windows systems. Unfortunately this would invlolve
delving into DLL calls from within LabVIEW (not for the faint hearted).
Indeed, some of the system calls required to get this to work are quite
cryptic. However at least on Windows, the telephone line of a voice modem is
configured as a Sound I/O device and LabVIEW recognizes it. Unfortunately, it
does not seem to be possible to use Sound VIs to send/receive audio messages
from LabVIEW to the telephone line (it would be GREAT!).
Below are the commands required for a Rockwell Semiconductor Systems
series of modems. The instructions were pulled from the "AT Commands for
RCV56ACx, RCV336ACx, RCV288ACx, and RCV144ACx Modems" Reference manual.
Hopefully they will guide you through the requirements for your specific
modem.
All the send commands should be preceded by "AT". The commands are shown
as send (SND) and receive (RCV) pairs.
SND: #CLS=8 Configure the modem for Voice Mode (still ADPCM).
RCV: OK The modem agrees, and is now set up for voice.
SND: #BDR=16 The DTE knows that compression requires a 38,400 bps speed,
so it forces this as the new speed.
RCV: OK This OK message is sent at 2400 bps, but the modem then switches
to 38,400 bps.
SND: #VLS=0 This ensures that the telephone line is selected.
RCV: OK The modem agrees.
SND: #VRA=45 The DTE allows 4.5 seconds for ringback to stop before
assuming that the modem thinks that the remote has answered.
RCV: OK The modem agrees with the DTE's assumption.
SND: DT6807 The DTE makes a telephone call, and the modem dials and goes
through call progress. BUSY or NO DIALTONE can be detected, but in this
example, the modem gets ringback.
VCON This message is sent 4.5 seconds after the third
ringback cadence is detected by the modem. The modem is in effect
assuming that the remote telephone was answered on the third ring because no
fourth ringback was detected before the #VRA time-out. The modem enters
Online Voice Command Mode, and DTMF and answer tone detection is enabled.
(Note that during this period, the modem might have detected answer tone from
a data modem. In this case, the appropriate <DLE> shielded code has to be
sent prompting the DTE to pursue a data handshake.)
SND: #VTX The DTE has a message to send.
RCV: CONNECT The modem says: "send it."
SND: <Data> The DTE sends the message: "Hi Dave. Your mother called."
RCV: <DLE><ETX> Procedure complete.
VCON DTMF still active.
SND: H The DTE has completed its forwarding task.
<Data> is the audio data stream of the message to send. 1,2,4 and 8 bits
"compression" (read resolution) are supported. This example is for 4 bits
compression , if the message data has 8 bit resolution, you packed the 4
MSbits of every two bytes in a single byte and send it. <DLE> (ASCII 8) is
the escape code for shielded codes; you have to send it twice when
encountered in the data stream. You end data stream with <DLE><STX>. 4 bits
compression requires at least DTE (computer) connection at 38400 bps, 8 bits
requires 115000 bps.
(back)
VISA
What is VISA and do I need one?
<Kevin Kent Kevin.KentATusa.alcatel.com>
(Timeless)
VISA (Virtual Instrument System Architecture) is an attempt to create a
standard I/O software package for VXI equipment. It also includes GPIB and
serial interfaces. It was created as part of the VXIplug&play System Alliance.
VISA is an API (application programmers interface) that provides a
uniform interface from a program to GPIB, VXI, GPIB-VXI and serial
interfaces. Instead of using separate API's for each interface the VISA API
can be used. This allows the programmer to generate code that can be easily
ported to the different interfaces. (ie interface independent drivers). VISA
can be incorporated into LabVIEW, LabWindows/CVI, Visual Basic or any ANSI C
compiler.
Do I need one? Probably. Most new drivers from NI are based on VISA and
all IVI drivers require VISA. Drivers that do not use any of these interfaces
will not need VISA, but others will benefit. Developing drivers is difficult
enough, if you have to develop drivers for each of the different interfaces
it becomes a real challenge. It is possible with VISA to develop one set of
drivers that will work for, say, both GPIB and serial. Once this is done
either interface can be used with no change to the higher level software.
(back)
What is National Instruments' current viewpoint on VISA?
<Dan Mondrik dan.mondrikATni.com>
(Timeless)
Several users have recently expressed disappointment at using National
Instruments VISA driver in LabVIEW. While we realize that VISA (or any API)
can't be all things for all people, it is our goal to make VISA suitable for
all T&M development -- instrument drivers and applications alike.
For those of you who don't know me, I am the lead VISA designer/engineer
at National Instruments. I have been involved with both the VISA
specification and its implementation here at NI for a number of years. Since
this posting is rather long, here's a summary of what follows:
- Initial reasons why NI created VISA
- Benefits that certain customers see in VISA
- Features of past/new versions of VISA
- Request for feedback
Initially, we set out to make an API that users of multiple T&M
interfaces could find commonality in. The best example of interface
independence that we could think of is where you have an instrument that
supports, for example, both GPIB and Serial connections. With a common API
(VISA) you need only one instrument driver, and that driver does not care
which connection you are using (except during initialization). Now as a
couple of you have pointed out, a device with multiple ports is not a very
common scenario. But most users do have more than just one device that they
are using -- at least one of them has a GPIB connection and at least one of
them has a Serial connection. Why is that important? Well, consider a new
user (who doesn't have ready-made drivers for his instruments) that can now
program his entire application with just one API. And for those of you
familiar with (and content with) NI-488 and the LabVIEW Serial VI's, consider
what might happen in several years when you need to replace an instrument.
Suppose that the manufacturer of your GPIB/Serial instrument no longer uses
that interface, but makes that same type of instrument for some other
interface (such as PXI). NI will ensure that VISA can access all major
interfaces for T&M instrumentation in the future.
VISA provides other benefits, too. Comments from certain users indicate
that they prefer the refnum-oriented session-based nature of passing VISA
handles from one VI to the next. Although this does complicate using
VISA-based drivers interactively, the program flow is easier to read,
especially in cases where you have more than one of a given instrument -- for
example, production test. In addition, the attribute node introduced with
VISA (now called the property node) allows you to set multiple configuration
parameters such as timeout, EOS character, etc., in one place. Both of these
technologies are becoming omnipresent in LabVIEW -- for example, VI server
and ActiveX. As the recent postings to info-labview indicate, however, there
is another group of users that would prefer a more traditional approach. We
would like to please both camps, and that is why we introduced Easy VISA VI's
in LabVIEW 5. We are interested as to whether this approach is beneficial.
Based on some of your posted comments, we acknowledge that we do still
have some work to do -- otherwise, I wouldn't be writing this. However, we do
feel that VISA is a mature product, and we are committed to continue
improving it, as we have done since its inception. The initial VISA
implementation (called VTL) had far less functionality than it does today.
Since that time, VISA 1.0 added serial support, asynchronous I/O, and
advanced features such as locking. Our VISA 1.2 release for Windows 95/NT
added new tools for configuration (T&M Explorer) and debugging (NI Spy). Our
next version of VISA (2.0 will be available later this year -- exactly when
depends on which platform) adds remote/local control for GPIB devices and
miscellaneous commands/queries for VXI devices. Our hope is that this release
should remove 'performance' from the NI-488 vs. NI-VISA decision. In
addition, we are adding serial support for all features that LabVIEW has that
VISA currently lacks. This is important because in a future version, LabVIEW
would like to provide all serial support through VISA. So rather than ignore
and toss out the VISA serial functionality, please let us know if you have
problems trying it. (Although this is not a call for VISA 2.0 beta users, let
us know if you would like to help test it. If you have the time, your lab
provides testing vectors that we'd never even dream of.)
If you've read this far, you're probably ready to respond. We do
appreciate your feedback and will truly evaluate it for inclusion in future
releases. Believe me, we'd like everyone to be happy with our VISA
implementation. We know it can be easier to use, but we need you to tell us
EXACTLY what you do and don't like about it now. Whether you have ideas for
improvement, or just want to let us know (if applicable) why you chose not to
use VISA, we'd like to know. Rather than consuming bandwidth on info-labview,
please respond directly to me (address below).
Thanks for reading this, and I look forward to hearing your suggestions.
(back)
Why doesn't my VISA session work?
<Clay Weston clayATwestontech.com>
(Timeless)
Did you open VISA sessions before trying to read and write? Did you get
any error messages when you opened them? Did you supply the correct session
IDs to the read/write VIs? You might want to report exactly what the error
message is and exactly when it is reported. Cycle instrument and PC power,
then use Probes or Simple Error Handler VIs to determine where the error
first appears. Try sending an example message from the instrument manual
verbatim. Verify that you are terminating your messages properly. Send your
message to a front panel variable with \ codes enabled to see that you are
sending exactly what you expect.
(back)
Parallel
How do I write out the parallel port?
<Bruce Mihura bmihuraATeden.com, Nick Moulton Nick.MoultonATpa-consulting.
com>
(Timeless)
You can use your parallel port as a free little DIO card! You get eight
bits of output and five bits of input.
If you can determine which address your port is using, it is a simple
matter to use the "In Port.vi" and "Out Port.vi" (except on WinNT) to read
from and write to your parallel port. WARNING!!! Be careful not to short
anything out, as this port is built in to your computer, and inadvertently
touching the wrong pins together for just a millisecond can destroy your
port! These pins, as output, can only drive a tiny amount of current, so you
would need additional circuitry to drive relays. I recommend buying a
parallel port card, which are only about $20, just to be safe.
First, you need to determine the port's I/O address. In Win95,
right-click on "My Computer", select Properties, then select the "Device
Manager" tab. Click on the + sign next to Ports, the double-click on any
"Printer Ports" you see. Clicking in the Resources tab of the window which
comes up tells you the I/O range, in hexadecimal. For the more primitive
Windows, try these addresses (all hexadecimal): 0x378, 0x278, then 0x3bc.
Once you know the port's I/O address, "In Port.vi" reads eight bits, and
"Out Port.vi" writes eight bits. Take advantage of LabVIEW's ability to
display any numeric in hexadecimal format (under the "Format & Precision"
menu) and show the radix on your numbers lest you forget. Show the address as
hexadecimal, and the data as hex, octal, or binary, for easier interpretation.
Here is the relationship of pins to bits on the 25-pin connector: Pins 2
through 9 correspond to output bits 0 (LSB) through 7 (MSB). Pins 15, 13, 12,
10, and 11 correspond to input bits 0 (LSB) through 4 (MSB). Pin 11 in
inverted. Most connectors manufactured today have tiny pin numbers embedded
in the plastic next to the pins.
If you want to know more, there are plenty of parallel port FAQ's on the
internet. One such resource that is valid as of 28/02/2003 is:
http://www.lvr.com/jansfaq.html
During the power on self test (POST) some BIOSs scan ports to check to
see if they're installed. On one machine I had the situation where the
external hardware was setting the IO lines such that the BIOS was not seeing
the port (hence LPT 1 was not installed and no printing was possible). If
this happens, make sure that your external hardware is disconnected when you
reboot the machine.
(back)
How do I access the IO ports under WindowsNT/2000/etc?
<Alex Le Dain alexATicon-tech.com.au>
(Feb 2003)
Unfortunately, or some would say fortunately, you cannot access the
port's (using IN PORT and OUT PORT) directly under operating systems suh as
Windows NT and Windows 2000. To access the port's under these operating
systems (and others like them) you need to download the AccessHW patch from
NI's web site. Simply navigate to http://www.ni.com and enter "accesshw" in
the search engine on the main page.
(back)
How do I print to a line printer?
<Alex Le Dain alexATicon-tech.com.au>
(Jan 2001)
You can use a line printer wuth LabVIEW, but you need to add a line to
your LabVIEW ini file first. Although this is a perfectly valid solution to
this problem you should read the excellent advice about this critical INI
file in the section entitled "Should I play with the undocumented LabVIEW
settings?".
First add the following as a single complete line:
serialDevices="COM1;COM2;COM3;COM4;COM5;COM6;COM7;COM8;
COM9;\\.\COM10;LPT1;LPT2;LPT3;LPT4"
using a simple text editor such as NOTEPAD.
Second, you need to access the printer just as you would a normal serial
device. In other words you must initialise the port (port 10 for LPT1) with
the Serial Port Init VI and use the Serial Port Write VI to send the string
to be printed direct to the printer. Note that this will pause your program
execution until the printing is completed. To avoid this feature you will
need to setup a separate process and pass the strings to be printed via a
queue or global.
If you want access to the line printer in a built application, then the
same rules for other LabVIEW ini file settings should be followed (see "How
do I include ini settings in my built application?").
(back)
GPIB
How do I release LabVIEW control over an instrument?
<Michael Porter mporterATarielcorp.com>
(Timeless)
It depends on what you mean by release control. A few instruments
incorporate commands that explicitly lock their front panels. If you are
using one of those, simply send the complementary command to unlock the
panel. Some other instruments automatically lock their front panels when you
send a GPIB command. For those, look up the unlock command (probably Local,
LCL or something similar) and send that. Most instruments however do nothing
to prevent local operation so there is no real need to "release control".
Also remember that if you are dependent upon some instrument-based way of
locking to secure the test system, be aware that all instruments will unlock
their front panels when you power cycle them. Therefore don't forget to check
the instrument to see whether it has been power cycled. Many instruments have
a bit in their status register that is set if the instrument has been
powered-up since receiving the last command, and since you should be reading
this status register to check for errors anyway, it is a low cost way of
verifying the instrument state.
(back)
TCP
(back)
UDP
(back)
DDE
(back)
Serial
How do I find a single character in a serial input stream?
<Alex Le Dain alexATicon-tech.com.au>
(Timeless)
One method is to read all the bytes at the port. In a loop determine the
number of bytes at the port using the "Bytes at Port.vi", passing the number
of bytes to the "Serial Port Read.vi". Search the string returned using the
"Split String.vi" or the "Scan String For Tokens.vi". If the character is not
present, concatenate the read string with the data passed from the previous
read (via a shift register) and continue to concatenate the string until the
character is detected. If the character is present split the string at this
point, passing the complete string to the processing VI, while passing the
remainder of the split string back to the shift register to be concatenated
with the next loop iteration (so there is no loss of data).
(back)
Can I use a modem to send data?
<Mark Boettcher markbATminimitter.com, Dan White dwhite.cybermetrixATflexc
ell.com, Alex Le Dain alexATicon-tech.com.au>
(Timeless)
A modem can easily be accessed from LabVIEW using the standard serial
port VI's. This is a fairly simple task using the Serial Driver Init VI
directed to the port the modem's hooked to and send out the modem command
strings like:
"ATZ" - reset the modem
"ATFOO" where FOO is whatever special modem commands you want to send
"ATDT19005551111" to dial 1-900-555-1111
After this just clear a string and sit in a loop building a string with
whatever comes in the serial port until you get a CR character. Then search
the string for the substring, "CONNECT" (if attempting to access another
modem). If that's not in there, then repeat the process until either that
happens or you get a timeout.
Once the modems are synced, the data can be sent after flattening it to
string type. Make sure that packets of data are sent and if there are
integrity issues then perhaps a CRC checksum should be included in each
packet. If you want to disconnect then send out an "ATH1" to command to hang
the modem up and finally close the serial port.
One fequently asked question is whether a WAV file can be played after
initiating a dial out with a modem. No definitive answer has been posted, but
it appears you would dial out as above. Instead of a CONNECT string response
from the other modem, you could look at the return string which should
contain the "RING" string when the modem is in verbose mode and dialing out.
Once the RING string is not detected (or there are no other error messages)
then it may be reasonable to suggest that someone/something has answered. How
to play the WAV file is still an unanswered question apart from the inelegant
method of then initiating playing the file out the soundcard lineout into the
MIC of the modem.
Don't forget to send out a CRLF combination after every string you send
out. In other words strings would look something like: ATZ/r/n. Furthermore,
there needs to be a wait of at least 400mS for the "OK" return string after
initializing the modem with "ATZ" before attempting to dial with the "ATDT"
string.
There are also commercial toolkits available from Microsys Technologies
(see Other Links and Resources) and there is an article in the LabVIEW
Technical Resource (LTR, Vol 5(1)) that deals with sending messages to a
pager, but involves modem initialization and control aspects that would be
useful in setting up modem communications.
(back)
How do I use a modem to send an audio message?
<Jean-Pierre Drolet sinternaATtr.cgocable.ca>
(Sep 2000)
To send an audio message by phone you need a voice modem. Unfortunately
some of the commands required differ from one manufacturer to other. Thus a
VI done for a specific modem might not work for another type.
To have a modem independant interface you could also use the Windows
Telephony API (TAPI) on Windows systems. Unfortunately this would invlolve
delving into DLL calls from within LabVIEW (not for the faint hearted).
Indeed, some of the system calls required to get this to work are quite
cryptic. However at least on Windows, the telephone line of a voice modem is
configured as a Sound I/O device and LabVIEW recognizes it. Unfortunately, it
does not seem to be possible to use Sound VIs to send/receive audio messages
from LabVIEW to the telephone line (it would be GREAT!).
Below are the commands required for a Rockwell Semiconductor Systems
series of modems. The instructions were pulled from the "AT Commands for
RCV56ACx, RCV336ACx, RCV288ACx, and RCV144ACx Modems" Reference manual.
Hopefully they will guide you through the requirements for your specific
modem.
All the send commands should be preceded by "AT". The commands are shown
as send (SND) and receive (RCV) pairs.
SND: #CLS=8 Configure the modem for Voice Mode (still ADPCM).
RCV: OK The modem agrees, and is now set up for voice.
SND: #BDR=16 The DTE knows that compression requires a 38,400 bps speed,
so it forces this as the new speed.
RCV: OK This OK message is sent at 2400 bps, but the modem then switches
to 38,400 bps.
SND: #VLS=0 This ensures that the telephone line is selected.
RCV: OK The modem agrees.
SND: #VRA=45 The DTE allows 4.5 seconds for ringback to stop before
assuming that the modem thinks that the remote has answered.
RCV: OK The modem agrees with the DTE's assumption.
SND: DT6807 The DTE makes a telephone call, and the modem dials and goes
through call progress. BUSY or NO DIALTONE can be detected, but in this
example, the modem gets ringback.
VCON This message is sent 4.5 seconds after the third
ringback cadence is detected by the modem. The modem is in effect
assuming that the remote telephone was answered on the third ring because no
fourth ringback was detected before the #VRA time-out. The modem enters
Online Voice Command Mode, and DTMF and answer tone detection is enabled.
(Note that during this period, the modem might have detected answer tone from
a data modem. In this case, the appropriate <DLE> shielded code has to be
sent prompting the DTE to pursue a data handshake.)
SND: #VTX The DTE has a message to send.
RCV: CONNECT The modem says: "send it."
SND: <Data> The DTE sends the message: "Hi Dave. Your mother called."
RCV: <DLE><ETX> Procedure complete.
VCON DTMF still active.
SND: H The DTE has completed its forwarding task.
<Data> is the audio data stream of the message to send. 1,2,4 and 8 bits
"compression" (read resolution) are supported. This example is for 4 bits
compression , if the message data has 8 bit resolution, you packed the 4
MSbits of every two bytes in a single byte and send it. <DLE> (ASCII 8) is
the escape code for shielded codes; you have to send it twice when
encountered in the data stream. You end data stream with <DLE><STX>. 4 bits
compression requires at least DTE (computer) connection at 38400 bps, 8 bits
requires 115000 bps.
(back)
VISA
What is VISA and do I need one?
<Kevin Kent Kevin.KentATusa.alcatel.com>
(Timeless)
VISA (Virtual Instrument System Architecture) is an attempt to create a
standard I/O software package for VXI equipment. It also includes GPIB and
serial interfaces. It was created as part of the VXIplug&play System Alliance.
VISA is an API (application programmers interface) that provides a
uniform interface from a program to GPIB, VXI, GPIB-VXI and serial
interfaces. Instead of using separate API's for each interface the VISA API
can be used. This allows the programmer to generate code that can be easily
ported to the different interfaces. (ie interface independent drivers). VISA
can be incorporated into LabVIEW, LabWindows/CVI, Visual Basic or any ANSI C
compiler.
Do I need one? Probably. Most new drivers from NI are based on VISA and
all IVI drivers require VISA. Drivers that do not use any of these interfaces
will not need VISA, but others will benefit. Developing drivers is difficult
enough, if you have to develop drivers for each of the different interfaces
it becomes a real challenge. It is possible with VISA to develop one set of
drivers that will work for, say, both GPIB and serial. Once this is done
either interface can be used with no change to the higher level software.
(back)
What is National Instruments' current viewpoint on VISA?
<Dan Mondrik dan.mondrikATni.com>
(Timeless)
Several users have recently expressed disappointment at using National
Instruments VISA driver in LabVIEW. While we realize that VISA (or any API)
can't be all things for all people, it is our goal to make VISA suitable for
all T&M development -- instrument drivers and applications alike.
For those of you who don't know me, I am the lead VISA designer/engineer
at National Instruments. I have been involved with both the VISA
specification and its implementation here at NI for a number of years. Since
this posting is rather long, here's a summary of what follows:
- Initial reasons why NI created VISA
- Benefits that certain customers see in VISA
- Features of past/new versions of VISA
- Request for feedback
Initially, we set out to make an API that users of multiple T&M
interfaces could find commonality in. The best example of interface
independence that we could think of is where you have an instrument that
supports, for example, both GPIB and Serial connections. With a common API
(VISA) you need only one instrument driver, and that driver does not care
which connection you are using (except during initialization). Now as a
couple of you have pointed out, a device with multiple ports is not a very
common scenario. But most users do have more than just one device that they
are using -- at least one of them has a GPIB connection and at least one of
them has a Serial connection. Why is that important? Well, consider a new
user (who doesn't have ready-made drivers for his instruments) that can now
program his entire application with just one API. And for those of you
familiar with (and content with) NI-488 and the LabVIEW Serial VI's, consider
what might happen in several years when you need to replace an instrument.
Suppose that the manufacturer of your GPIB/Serial instrument no longer uses
that interface, but makes that same type of instrument for some other
interface (such as PXI). NI will ensure that VISA can access all major
interfaces for T&M instrumentation in the future.
VISA provides other benefits, too. Comments from certain users indicate
that they prefer the refnum-oriented session-based nature of passing VISA
handles from one VI to the next. Although this does complicate using
VISA-based drivers interactively, the program flow is easier to read,
especially in cases where you have more than one of a given instrument -- for
example, production test. In addition, the attribute node introduced with
VISA (now called the property node) allows you to set multiple configuration
parameters such as timeout, EOS character, etc., in one place. Both of these
technologies are becoming omnipresent in LabVIEW -- for example, VI server
and ActiveX. As the recent postings to info-labview indicate, however, there
is another group of users that would prefer a more traditional approach. We
would like to please both camps, and that is why we introduced Easy VISA VI's
in LabVIEW 5. We are interested as to whether this approach is beneficial.
Based on some of your posted comments, we acknowledge that we do still
have some work to do -- otherwise, I wouldn't be writing this. However, we do
feel that VISA is a mature product, and we are committed to continue
improving it, as we have done since its inception. The initial VISA
implementation (called VTL) had far less functionality than it does today.
Since that time, VISA 1.0 added serial support, asynchronous I/O, and
advanced features such as locking. Our VISA 1.2 release for Windows 95/NT
added new tools for configuration (T&M Explorer) and debugging (NI Spy). Our
next version of VISA (2.0 will be available later this year -- exactly when
depends on which platform) adds remote/local control for GPIB devices and
miscellaneous commands/queries for VXI devices. Our hope is that this release
should remove 'performance' from the NI-488 vs. NI-VISA decision. In
addition, we are adding serial support for all features that LabVIEW has that
VISA currently lacks. This is important because in a future version, LabVIEW
would like to provide all serial support through VISA. So rather than ignore
and toss out the VISA serial functionality, please let us know if you have
problems trying it. (Although this is not a call for VISA 2.0 beta users, let
us know if you would like to help test it. If you have the time, your lab
provides testing vectors that we'd never even dream of.)
If you've read this far, you're probably ready to respond. We do
appreciate your feedback and will truly evaluate it for inclusion in future
releases. Believe me, we'd like everyone to be happy with our VISA
implementation. We know it can be easier to use, but we need you to tell us
EXACTLY what you do and don't like about it now. Whether you have ideas for
improvement, or just want to let us know (if applicable) why you chose not to
use VISA, we'd like to know. Rather than consuming bandwidth on info-labview,
please respond directly to me (address below).
Thanks for reading this, and I look forward to hearing your suggestions.
(back)
Why doesn't my VISA session work?
<Clay Weston clayATwestontech.com>
(Timeless)
Did you open VISA sessions before trying to read and write? Did you get
any error messages when you opened them? Did you supply the correct session
IDs to the read/write VIs? You might want to report exactly what the error
message is and exactly when it is reported. Cycle instrument and PC power,
then use Probes or Simple Error Handler VIs to determine where the error
first appears. Try sending an example message from the instrument manual
verbatim. Verify that you are terminating your messages properly. Send your
message to a front panel variable with \ codes enabled to see that you are
sending exactly what you expect.
(back)
Parallel
How do I write out the parallel port?
<Bruce Mihura bmihuraATeden.com, Nick Moulton Nick.MoultonATpa-consulting.
com>
(Timeless)
You can use your parallel port as a free little DIO card! You get eight
bits of output and five bits of input.
If you can determine which address your port is using, it is a simple
matter to use the "In Port.vi" and "Out Port.vi" (except on WinNT) to read
from and write to your parallel port. WARNING!!! Be careful not to short
anything out, as this port is built in to your computer, and inadvertently
touching the wrong pins together for just a millisecond can destroy your
port! These pins, as output, can only drive a tiny amount of current, so you
would need additional circuitry to drive relays. I recommend buying a
parallel port card, which are only about $20, just to be safe.
First, you need to determine the port's I/O address. In Win95,
right-click on "My Computer", select Properties, then select the "Device
Manager" tab. Click on the + sign next to Ports, the double-click on any
"Printer Ports" you see. Clicking in the Resources tab of the window which
comes up tells you the I/O range, in hexadecimal. For the more primitive
Windows, try these addresses (all hexadecimal): 0x378, 0x278, then 0x3bc.
Once you know the port's I/O address, "In Port.vi" reads eight bits, and
"Out Port.vi" writes eight bits. Take advantage of LabVIEW's ability to
display any numeric in hexadecimal format (under the "Format & Precision"
menu) and show the radix on your numbers lest you forget. Show the address as
hexadecimal, and the data as hex, octal, or binary, for easier interpretation.
Here is the relationship of pins to bits on the 25-pin connector: Pins 2
through 9 correspond to output bits 0 (LSB) through 7 (MSB). Pins 15, 13, 12,
10, and 11 correspond to input bits 0 (LSB) through 4 (MSB). Pin 11 in
inverted. Most connectors manufactured today have tiny pin numbers embedded
in the plastic next to the pins.
If you want to know more, there are plenty of parallel port FAQ's on the
internet. One such resource that is valid as of 28/02/2003 is:
http://www.lvr.com/jansfaq.html
During the power on self test (POST) some BIOSs scan ports to check to
see if they're installed. On one machine I had the situation where the
external hardware was setting the IO lines such that the BIOS was not seeing
the port (hence LPT 1 was not installed and no printing was possible). If
this happens, make sure that your external hardware is disconnected when you
reboot the machine.
(back)
How do I access the IO ports under WindowsNT/2000/etc?
<Alex Le Dain alexATicon-tech.com.au>
(Feb 2003)
Unfortunately, or some would say fortunately, you cannot access the
port's (using IN PORT and OUT PORT) directly under operating systems suh as
Windows NT and Windows 2000. To access the port's under these operating
systems (and others like them) you need to download the AccessHW patch from
NI's web site. Simply navigate to http://www.ni.com and enter "accesshw" in
the search engine on the main page.
(back)
How do I print to a line printer?
<Alex Le Dain alexATicon-tech.com.au>
(Jan 2001)
You can use a line printer wuth LabVIEW, but you need to add a line to
your LabVIEW ini file first. Although this is a perfectly valid solution to
this problem you should read the excellent advice about this critical INI
file in the section entitled "Should I play with the undocumented LabVIEW
settings?".
First add the following as a single complete line:
serialDevices="COM1;COM2;COM3;COM4;COM5;COM6;COM7;COM8;
COM9;\\.\COM10;LPT1;LPT2;LPT3;LPT4"
using a simple text editor such as NOTEPAD.
Second, you need to access the printer just as you would a normal serial
device. In other words you must initialise the port (port 10 for LPT1) with
the Serial Port Init VI and use the Serial Port Write VI to send the string
to be printed direct to the printer. Note that this will pause your program
execution until the printing is completed. To avoid this feature you will
need to setup a separate process and pass the strings to be printed via a
queue or global.
If you want access to the line printer in a built application, then the
same rules for other LabVIEW ini file settings should be followed (see "How
do I include ini settings in my built application?").
(back)
GPIB
How do I release LabVIEW control over an instrument?
<Michael Porter mporterATarielcorp.com>
(Timeless)
It depends on what you mean by release control. A few instruments
incorporate commands that explicitly lock their front panels. If you are
using one of those, simply send the complementary command to unlock the
panel. Some other instruments automatically lock their front panels when you
send a GPIB command. For those, look up the unlock command (probably Local,
LCL or something similar) and send that. Most instruments however do nothing
to prevent local operation so there is no real need to "release control".
Also remember that if you are dependent upon some instrument-based way of
locking to secure the test system, be aware that all instruments will unlock
their front panels when you power cycle them. Therefore don't forget to check
the instrument to see whether it has been power cycled. Many instruments have
a bit in their status register that is set if the instrument has been
powered-up since receiving the last command, and since you should be reading
this status register to check for errors anyway, it is a low cost way of
verifying the instrument state.
(back)
TCP
(back)
UDP
(back)
DDE
(back)