Serial port CTS monitoring

I would like to know how to read the status of the Clear To Send (CTS) line.
I need this in order to implement a write with timeout vi, required when
using the RTS/CTS handshaking protocol.
Thanks
Gilles

Hallo, Gilles,
Du meintest am 21.09.99 zum Thema serial port CTS monitoring:
> I would like to know how to read the status of the Clear To Send
> (CTS) line.
advanced/memory/in port
If you run LabView under Windows NT, you need "hwaccess" from the NI ftp-
server for direct port access.
CTS is line 4 (2^4) at (port base + 6), the MSR (modem status register).
Ralf Browns interrupt list (especially the "ports.lst") shows many
details.
Viele Gruesse!
Helmut

Similar Messages

Reading CTS or DSR lines of Serial port

Is there a way to read the status of CTS or DSR lines of a serial port?
Also in what pins are these lines on standard PC?
Ori Idan
Helicon technologies LTD. National Instruments Alliance member in ISRAEL
Email: [email protected]
Home page: http://www.helicontech.co.il
Tel: +972-6-6262353 Fax: +972-6-6262405
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Things should be made as simple as possible but not simpler
Albert Einstein
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

On Thu, 04 May 2000 16:47:40 +0300, Ori Idan wrote:
>Is there a way to read the status of CTS or DSR lines of a serial port?
>Also in what pins are these lines on standard PC?
While looking for info on printing I found the following:
How can I control the DTR and RTS serial lines?
Serial Port Init.vi can be used to configure the serial port for
hardware handshaking; however, some applications may require manual
toggling of the DTR and RTS lines. Because the interface to the
serial ports is platform-dependent, each platform has a separate
mechanism to control the lines.
(Windows) The LavVIEW for Windows distribution contains a VI which you
can use to drive the DTR and RTS serial lines. The VI serial line
ctrl.vi, located in vi.lib\Instr\_sers
up.llb, can be used to control
these lines. The VI will toggle these lines according to the function
input. Valid codes for the input are:
0 noop
1 clear DTR
2 set DTR
3 clear RTS
4 set RTS
5 set DTR protocol
6 clr DTR protocol
7 noop2
(Macintosh) ..................
(Sun).............................
From LabVIEW User Manual page B-13
Hope this helps.
Regards,
Steve Drake

How do I monitor serial port activity without first sending a command?

In my application I am sending a command through the serial interface and I want to monitor the response. The response is not instant, in fact it is a timeout response indicating the requested action did not work. How do I monitor so I can parse what is coming in over the serial port without necessarily sending a command?

You can always place a loop where you monitor the number of bytes at the serial port.
After configuring your VISA serial port session, you can create a Property Node to get the number of bytes available at serial port.
You can then process this information, for instance:
1. Establish a timeout because you never get a response.
2. Do serial port read if there is data available.
You can exit the loop with a timeout condition or having processed the data.
-JLV-

Serial port monitor

Does anyone know if there's some code / a program which would allow me to monitor what is going on with my computer's serial ports. I have been asked to write a program to replace the current program being used, that commumicates with a piece of hardware on a serial port. I can only find out what the command codes are by looking at what is sent between the existing application and the port (as there is no documentation / source code / anything useful).
Many thanks,
JB

Please visit
http://java.sun.com/products/javacomm/javadocs/API_user
_guide.html
http://java.sun.com/products/javacomm/javadocs/javax.co
m.SerialPortEvent.html
javacom allows you to intercept traffic on a serial port?

Building a diagnostic tool to monitor serial port events

Hi,
I'm writing a diagnostic tool. I have two Windows machines communicating via serial ports. I need to treat the software on both machines as "black boxes." I would like to peek at both the sent and received data at one machine and save to a file without emptying the buffers.
Does have LabVIEW have access to these data? Can we look at it without emptying buffers?
Thanks,
FgH...

You can access to the data you like by wiring from the sent or
received data
bufferd line. But, cabablity of this way quite depends on the data
sampling rate
because the monitor is the most time consuming process on LV.
As I've experienced, you can do it in less than 100Hz rate per one data.
And saving to a file may be done after some interval repeatedly. The
files are
better smaller sized ones, so the data is to be storaged in a couple
of data files.
As for more practical method, i have to know your diagnostic tool in
detail
as far as possible. Tom
haibach wrote:
> Hi,
>
> I'm writing a diagnostic tool. I have two Windows machines
> communicating via serial ports. I need to treat the software on both
> machines as "bla
ck boxes." I would like to peek at both the sent and
> received data at one machine and save to a file without emptying the
> buffers.
>
> Does have LabVIEW have access to these data? Can we look at it
> without emptying buffers?
>
> Thanks,
> FgH...

"Example on reading combined signals from a serial port and separating them for display purposes". I am a beginner in Labview and would appreciate if anyone help with that

I am working on a wireless vital sign monitor. I have 3 signals; heart rate and temperature. I filter and amplify the signals before converting them into digital form. I then pass them via MAX232 before passing them to RS232 serial cable.
I am therefore working on a program to receive the combined signal and separate them.
I have come across serial read and write examples on ni.com but am looking for one where I can actually separate combined signals and display them separately.

Reading the serial port will give you a string. How you divide the channels depends on how the data was formatted before it was sent over the serial channel.
If you are designing the instrument, as it seems from your query, then you can set up any form you wish. If your data is always floating point numeric, you could use space or tab characters to separate data words. You could use and XML format. If the instrument is provided by a vendor, contact them for the protocol.
If tabs are used between words and returns between sets of readings, the resutlant string can be interpretted by the Spreadsheet String to Array function in LV.
Things to avoid are characters often used by serial communications systems as control characters. Carraige returns are
often used as command terminators by serial protocols, but may also be used by the port.
Lynn

Parsing data from Serial Port one byte at a time

Hi everyone,
What I want to do is read in from the serial port byte by byte and parse each byte that I am reading in. The size of the data read in varies. How do I do that? I can do using .dll but I want to learn how to do it in labview. I searched through the forum for something similar but no luck. I have seen some that puts the VISA read in a while loop and others that puts the property node, "bytes at Port" in a while loop. What is the difference in doing either way? I am using Labview 7.1 Can anyone point me in the right direction?
Thanks

Hi guys..
I'm still a beginner in using labview tcp/ip function. for now, i have a project to read the labview data with java programming language so that i can monitor that data using any devices that using java, such as PC or cell phone. my task for now is to determine the format of data that being sent (its type, length, etc), coz as far as i done until now, the data that read in the java is still a raw material so that i dont know how to gain the information from that data.
my question is :
- how does the type cast work in changing the data format from one to another?
- how does the bytes to read in tcp read work? coz when i'm changing the length of bytes to read constant from 4 bytes to another, the data is becoming mess up. As far as i know, the bytes to read only read the first "constant number" byte in the tcp read to determine the length and type of the data..
thanks

How can I read the voltage from a serial port

I am fairly new to LabView and I am having trouble figuring out how to read the DC voltage coming out of an RF Power Supply through a serial port so that I can monitor the voltage every few seconds. In order to do this do I need to purchase a DAQ card or anything like that?

You would not need a DAQ card to read data over the serial port. You would, however, need a serial port. That may sound sarcastic, but it's not, since many manufacturers are ditching serial ports on computers. If you don't have a serial port then you would need to get something like a USB<->serial adapter or a serial port card that you plug into an expansion slot in your computer.
Assuming you've got that then you need to find the command set for the RF Power Supply, and write drivers for it so you can send the command to read the voltage, and then read the resposen. I would suggest looking in the Instrument Driver Network to see if a driver for your supply has already been written.

How to transfer file from PC to PC via serial port using labview

I need to transfer files(.txt, .doc, .xls) from PC to PC via serial port using LabVIEW. Is it possible to transfer files, if so how to transfer?
Solved!
Go to Solution.

Yes, it is possible to transfer files with the serial port using LabVIEW. Files are just collections of bytes and the serial port is pretty good at shipping bytes from one PC to another. You need to connect the serial ports together with a null modem cable.
First, take a look at the example for serial communication. In LabVIEW, go to the Help menu and select "Find Examples...". From there you can search for "serial" or navigate to Hardware Input and Output >> Serial. Select the "Basic Serial Write and Read.vi". Experiment with that example to gain confidence on the serial communication methods.
Next, it's time to learn about how to read and write files. For that, the examples could be somewhat confusing since they all deal with files that are presumed to have data of a specific type in them. I would recommend just getting familiar with the functions on the File I/O palette. Specifically, get to know the following functions.
Open/Create/Replace File - On your destination side, you'll need to create the copy of the file that you are trying to transfer
Close File - When you are finished reading from or writing to a file, you should close it. It cleans up the memory being used and finalizes any write operations that are still floating in the write buffer.
Read From Binary File - The best way to read from a file when you do not really care what type of file it is. In your case, you just want to get those bytes read and sent out so they can be written down at the destination.
Write to Binary File - At the destination side, this is what will store those bytes to the file you created with number 1.
Get File Size (under the Advanced File Functions sub-palette) - You need to know how big the file is so you know when you are finished.
OK, so once you are able to create files, write bytes to them, and read bytes from existing files you can move on to transferring.
The basic method I would suggest is to have the user specify a source file on the source PC and a destination folder on the destination PC. Then, find out the size of the source file using number 5. Divide that size number by the number of bytes you feel like transferring at once. The serial buffers are usually around 32k (if I remember correctly) so do not exceed that. Now begin sending data by reading some number of bytes and wiring that string output to the VISA Write function. On the destination side, you'll want to be monitoring the serial port for bytes and reading them when they arrive. Wire that string to the Write to Binary File function to add them to your destination file.
That is the basic outline of how to do it. You have to be careful not to overload the write and read buffers on the serial ports. Initially you can use delays on the sending side to make sure the reading side has enough time to digest. To get things moving faster, you can bring in some flow control.
If all that sounds a bit intimidating, there are Alliance Member companies out there (such as PrimeTest Automation) who can write such code for you and even provide a turnkey solution for you.
Happy wiring,
Dan Press
Certified LabVIEW Architect
PrimeTest Automation

The "VISA Configure Serial Port" VI will only run at 9600 Baud

I have written a Serial Port monitor "RS232 RW.vi" that works for the most part. The problem is that it will not respond to alternate port configuration settings.... For instance: the default RS232 Serial port configuration is:
(COM1,9600 baud,8 data bits,1 Stop bit, None no parity)
As a test, I am using a Null Modem Cable to connect From my LabView Com1 port to another PC running RealTerm Serial Port Monitor.. Using my newly designed "RS232 RW.vi" With port settings of (COM1,9600 baud,8 data bits,1 Stop bit, None no parity), I can send and receive data back and forth all day long no problems....
However, if I configure the "RS232 RW.vi" port to any other configuration, such as (COM1,2400 baud ,7 data bits,1 stop bit, Odd parity).. It will not take the expected chances and continues to operate @ 9600 baud etc.
I then changed the "RS232 RW.vi" default settings to (2400,7,1,Odd)
it still refuses to deviate from (COM1, 9600,8,1,None...)
I also went into the Win XP Device Manager on the LabView system and manually configured Com1 to 2400,7,1,Odd
and still,.... the "RS232 RW.vi" will only operate @ 9600,8,1,None
Can anyone else test drive my VI and see if they have the same problem of not being able to see new changes in the Port configuration settings ..other than (COM1, 9600,8,1,None...).... ?
FYI.. Unfortunately my LabView is running on Version 6.0 so you may need to up-convert the attached vi
Solved!
Go to Solution.
Attachments:
RS232 RW.vi ‏102 KB

Instead of just appreciating the comments, you need to implement them.
Having the VISA close inside the loop is definitely the problem. And Crossrulz is 100% correct about the problem being that the serial port gets reset to the default baud rate after closing the port. Here is the proof.
Note that while you may have set the port settings manually in device manager, those settings are revised by the VISA driver. If you look in Measurement and Automation Explorer under Devices and Interfaces >> Serial and Parallel, you'll see the default settings that the VISA driver uses. If you change the setting there, your program will work the way you want. But that is not the correct fix. The correct fix is to get the VISA close out of the while loop.
The port settings are established in this order.
1. By the Windows device drivers.
2. By the VISA driver as established in MAX. Since you are useing VISA, these settings will automatically override #1.
3. By the port settings you set programmatically in your LabVIEW program.
Attachments:
Example_VI.png ‏18 KB

Serial port: Input/output signal errantly combined

I am currently in the process of using LabView to replace another user interface for a scientific instrument.
LabView is connected to this instrument through a serial port. The instrument streams 25 bytes of binary data every second to the computer. I can read the binary string (VISA Read) and save contiuously to disk using a while loop. In addition, there are a few instructions I can send to the instrument that will do various functions (start logging, turn LEDs on/off, etc). I can successfully send these instructions to the instrument using the previous interface, and in a stand-alone vi using VISA Write, but when I place the VISA Write function into the larger interface vi, signals go haywire. Specifically, there are two separate LEDs that I can toggle with two different commands, but when in the larger interface vi, both commands toggle the same LED. Also, it appears that the singal I send to the instrument (a single ASCII character) immediately bounces back to the computer into the 25 bytes of streaming binary data. In other words, after I press the LED "on" key, one column of my streaming data changes when it is not supposed to (ex: after Binary to ASCII conversion, it changes from a single digit to a twenty digit value).
Initially, I thought the problem was the sequence of VISA Read/Write. In the current configuration, I read all data, then allow for Write commands. Both the VISA functions are within the same While loop to continuously monitor the data. Is it possible the Write signal output is not leaving the while loop and being read as input? What would make the instrument read two different commands as the same one? My goal is to run an interface that displays the streaming data as ASCII, and allows for a few different toggle options while the interface is running - is there are more efficient/elegant way than a while loop?
~Going Bananas
Solved!
Go to Solution.

New replies now in gray.
CodeMunkee wrote:
1. If you keep giving me good advice like this, I'll be tempted to change the background to Baltimore prison purple.
I'll ignore this statement.
2. The buffer now lives outside the loop. I understand clearly. Part of the problem might be my instrument - when I cycle power the 19 digit number that was 'echoed' disappears. Forget about that display stuff, it works properly - I accidentally removed the time delay when editing the vi. But you do bring up an interesting point...
Without the delay, the loop ran much faster. If the bytes weren't at the port, the read statement would have returned nothing when it read zero bytes, thus blanking out the indicator rather quickly.
Yes, Hexadecimal display shows 04 to indicate the end of the 25-byte data sample.
Doing a bytes at port read is not always a good idea. If not all the bytes had arrived yet when you ask for the read, you won't get all the data. The remaining data being sent in that stream from the instrument will show up at the front of the buffer on the next read command.
While this isn't a common occurence, it does happen. How can I prevent this from ever happening?
Since you know each commands ends with a hex 04 (ASCII character for EOT), you could enable the termination character when you configure the serial port. Set the termination character to be 4. Then when you execute the VISA read, read a large number of bytes such as 25 or more. The read will terminate at either the timeout, the requested number of bytes, or when the termination character is read. With this setup, you could eliminate the wait statement and also not request the number of bytes as the port. The VISA read will control the pacing of the loop. Any extra bytes after the termination character are part of the next frame of data and will wait around until the next time you read the VISA port.
3. Implementing your ideas for the latch button works better. I am still encountering issues with these commands however. Attached is the new vi. There are two commands I want to send, 't' turns on the LED light (they blink for 30 sec then time out), and the latch works perfectly for that, 'p' turns on the magnetometer light (an additional 'p' is required to turn it off), but I cannot get the command sent to the mag while the loop is running. It turns on either at the beginning of the vi, or at the end of the vi (after Finish button is pressed). This leads me to think the command 'p' is stuck inside the loop. I tried adding another film strip (see attached vi) for the toggles to force the issue, but it didn't work. Additionally, the 'p' command effectively works as a 't' command, and the LED lights begin to blink when I press the 'p' button. This isn't supposed to happen, and leads me to believe the 'p' command does in fact exit the loop but in the wrong manner.
The "film strip" is another frame of a flat sequence structure. It enforces the order of execution. The next frame can't execute until everything in the prior frame has completed. It isn't necessary in your case because the Error and VISA wires determine the order of execution with respect to the other VISA statements. But it shouldn't hurt.
There is no reason the "p" case structure should behave any differently than the "t" case structure. Although you should wire the error wire through in the False case of the "p" structure like you did for the "t" structure. There is no "exiting of the loop" in either case. The loop runs until the stop button is pressed. I would check the manual to see that t and p commands do what you think they should do. Do they need a termination character of their own when they are sent? Should they be upper case letters rather than lower case? You can run NI Spy on your serial port and see the operations occurring with it and see the data coming in and what data is going out. I would be suspicious that the device is not handling the command properly.
Any ideas? I think I've tried to put the toggle buttons outside the loop before, but then could only toggle once before the loop took over. Ideally, these toggles would be available at any time while the data is streaming, so therefore inside the loop?
The toggle buttons need to be within the loop so that they can be read on every iteration of the loop. Outside the loop, as you discovered, they are only read once at the very beginning before the loop is started.
4. Thank you for the suggestion about the Selection Mode for the Open/Create File option. It is annoying to create a file first. I made the change, but I still get error messages when I use a file that does not yet exist. LabView takes me to the first Open/Create/Replace vi when the error occurs. Is there something else I must do?
On the open file VI, there is an input that is Open as default when unwired. Create a constant there and change to Replace or Create.
Remember, if you have any questions about the way LabVIEW is handling something with serial ports, close the port within LabVIEW. Open Hyperterminal and try the commands from there.
Message Edited by Ravens Fan on 01-13-2009 03:55 PM

Serial Port Overrun

Hello All,
I am developing Teststand sequences which run Labview code. I use 1 labview vi to configure and drive the serial port, the first call configures the serial port. The second call writes a message and reads the response, the last call releases the resource. When running the call write&read I intermittently receive the error shown in the attached jpg, this causes my whole sequence to lockup till I return to restart the test. I need to run this repeatedly overnight so its a problem. I have a feeling this isnt so much a serial port overrun problem as a hardware clash ( i also configure and run a camera ).
I have spotted a number of posts a on this same topic but I havent yet found a soultion only advice, which I have already tried.
Help greatly appreciated
Regards Chris
Attachments:
Serial Port Error.jpg ‏63 KB

Are you familiar with handshaking? There were several posts on this subject recently. The end device is sending data faster than your computer and Labview program can handle. You need to implement handshaking. There are two types of handshaking, software and hardware:
Software, also called XON/XOFF. With this setup, when the computer serial port incoming buffer gets nearly full, it automatically sends an XOFF command (don't worry about what it is since it is automatic). The XOFF command tells the endpoint device to stop sending data. When the buffer gets near empty, the computer sends an XON command. The endpoint device then starts sending data again. For this protocol, the endpoint device must be able to support this, and must be configured to use this type of handshaking. You would have to read the manual to find out how to set it up. For the computer end, you can set it up with an option for the configure serial port function on the input labeled "Flow Control". Right click on this terminal and select Create - Constant. A text ring will be created. Select XON/XOFF in the text ring.
Hardware, also called RTS/CTS. Same principle in that the computer signals the endpoint when to stop sending data and when to start again. However, instead of sending a command, the computer drops the CTS line (Clear To Send). Actually, the endpoint device raises the RTS (Request To Send) when it wants to send data, and the computer responds with raising CTS if it is ready to receive data. When the buffers get full, the computer drops CTS which tells the endpoint to stop sending data. When the computer is ready to start receiving again, it raises CTS. Again, both sides must be configured for this. The text ring has an RTS/CTS selection.
You will have to read the manual on your endpoint device to see what it supports and how to configure it. Warning: If sending binary data, DO NOT use XON/XOFF. The binary data may just happen to form a pattern that looks like XOFF, and everything will lock up because XON will never be sent. So if binary data is being transferred, use RTS/CTS. If normal ASCII characters are being sent, you can use either protocol.
- tbob
Inventor of the WORM Global

Multiple serial ports reading from a shared USB port

I have a program that reads from 4 flow controllers, which send data through RS232 serial ports. Because the computer is located pretty far away, the vendor suggested to use an Edgeport box to convert RS232 to USB, then convert to ethernet port using a SuperBooster converter. The signal travels long distance in ethernet cable to the computer and get converted back to USB, then to the computer. In MAX, I was able to see 8 com ports from the Edgeport box, and I was able to communicate with my flow controllers.
The problem is, it will give me some error message occasionally. Sometime it's a VISA Read error, sometime it's a VISA framing error. Could this be caused by the way the signal is transmitted?
In the program I have four parallel WHILE loops that constantly do READ and WRITE to the 4 flow controllers. Could this be causing the errors? If so, what is the best strategy to design this program?
Thanks

I agree with Mike, you will need an error handling strategy that accounts for these errors. And retries the communications. This can be a little tricky, but very doable. I believe some sort of statemachine approach will work best for this.
As for your heated probe. I would make some sort of hardware interlock that will shut it down in case of a coolant failure. NEVER, EVER trust the computer to be running where safety is concerned, either for personal or hardware. There are plenty of ICs that can monitor temperature, and have warning, and alarm outputs! Another option is some sort of watchdog on the communications bus for the coolant control, but I think this is a bit more tricky.
Paul <--Always Learning!!!
sense and simplicity.
Browse my sample VIs?

Serial port for an alarm system

I have an alarm system set to receive inputs from LabVIEW-controlled digital I/O cards. All the digital ports are fully utilized for data input. When an alarm state is reached, we would like to use the serial port to relay the alarm condition to a global monitoring system. I don't know if the serial ports can accomplish this as the global monitoring system typically looks for a dry contact or a relay to be tripped. What are the capabilities of the serial port along these lines? Can I have it set to constantly send a 5V signal of dummy data and then drop that data transmission when the alarm condition is reached?

RS-232 can be +-12V or more depending on how the physical drivers are configured. However, if you can handle these voltages, then you can simply assert or deassert one of the modem control lines (RTS or DTR) to indicate your alarm state. If you want to use the TX line, you can set and clear the break condition. If you hook up a multimeter to one of these signals and experiment with NI-VISA in LabVIEW, you should be able to create a signal that will work in your system.
However, if you need +5/GND, you can use an RS-485 port which generates (well, in a way) signals between 0 and 5V (or 0 and 3.3V depending on the system). RS-485 is a differential signaling system, but you can just throw away one of the lines. In this case you'll use TX+, TX-, RTS+, or
RTS- depending on what you need.

Pb with the serial port

hello
I'm making a programme that deal with the serial port
when i press on the button sennd of my serial device ,I get nothing .
infact i have to press about 4 times to get the output
I will get 4 outputs result at once
I believe that my problem come from
fluxLecture.readLine();I think that my machine is not sending the end of line
what is strange that the "while" will stop but it wont execute the next line
System.out.println("I'm ouside ");any idea ?????
thank you in advance
try {
               fluxLecture =
                    new BufferedReader(
                         new InputStreamReader(serialPort.getInputStream()));
          } catch (IOException e) {
          }then somewere else in my class I use this
public void serialEvent(SerialPortEvent event) {
          switch (event.getEventType()) {
               case SerialPortEvent.BI :
               case SerialPortEvent.OE :
               case SerialPortEvent.FE :
               case SerialPortEvent.PE :
               case SerialPortEvent.CD :
               case SerialPortEvent.CTS :
               case SerialPortEvent.DSR :
               case SerialPortEvent.RI :
               case SerialPortEvent.OUTPUT_BUFFER_EMPTY :
                    break;
               case SerialPortEvent.DATA_AVAILABLE :
                    try {
                                    while(fluxLecture.ready())
                                        result_output = result_output +" "+ (String) fluxLecture.readLine();
System.out.println("I'm inside");
System.out.println("I'm outside");

sorry for being late but as I have alot of work ,so ......
Are you using package RXTX or javax.comm?javax.comm
I tried to chek if the readline is null ,the answer is no
so my while stop but does not execute the next line
strange ????

Serial port CTS monitoring

Similar Messages

Maybe you are looking for