|
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.cybermetrixATflexcell.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)
|
