Reading and writing at the same time thru the same serial communication port in LabWindows

[qsa301]

Hi,

I am trying to read and write my data through the same serial communication port in LabWindows. What I am trying to  do is: I am sending a command to the UUT (writing) and then trying to get a response (read) from the unit right after that. For example, send a command to the unit to log or display all of its tasks/activities and then receive the response from the unit right after sending the command. So it not exactly reading and writing at the same time but reading a response right after I write something to the unit. I want to be able to do this at any given time. I would really appreciate if you could give me some pointers as to how I can achieve this.

Thanks!

[MJF]

This is all simple, basic stuff you want to do here. You basically have two main options, either use the functions in the RS-232 library or the functions in the VISA library. I personally prefer the VISA library because I often deal with instruments that may have multiple interfaces and VISA allows me to write code that works across multiple interface types without having to use a different library and with only minor changes in the initial setup based on the actual interface type in use.

If using the RS-232 library, the basic function call sequence is like this (I am not providing parameters, you will need to look up how to use the functions)::

OpenComConfig()
ComWrt()
ComRd()
ComClose()

If using the VISA library, you will need to do the following:

viOpenDefaultRM()
viOpen() // For the serial port
viSetAttribute() // For each attribute you need such as baud rate, etc.
viWrite()
viRead()
viClose()

While the VISA approach may require a few more calls to do the basic setup, it is more flexible and the programming model is much more consistent across interfaces. It is worth looking into, it is definitely a more modern approach to doing this sort of thing.

And just for the record, it is indeed possible to actually receive and transmit data simultaneously on a serial port, it's called full-duplex mode and the hardware helps you do that by providing a FIFO buffer for the received data and one for the transmit data. As long as you can service both buffers fast enough with your program (not an issue on modern PCs at most, if not all baud rates), you can communicate in full-duplex mode with no loss of data.

[RobertoBozzolo]

I just want to add two litle suggestion to Martin response.

Whichever is the method you choose, either the RS232 library or VISA, be sure to add some pause between write and read operations: your device may take some time to react to the command it receives and if you don't consider it you may be missing its response just because you were expecting it too early. A simple read with a adequate timeout could be what you need for it.

Second, in case you are using RS232 library I suggest you open your serial port with OpenComConfig passing a negative value for output buffer lenght: doing this way will exclude the use of Windows buffer and write directly to the port, otherwise you cannot really be sure of when exactly the message goes out of the port and you may suffer unpredictable and not-easy-to-debug timing problems.

[MJF]

Good points there Roberto.

I've been doing this stuff for so long I don't even think about those little details anymore, it's all second nature to me now.

[Mert_A.]

I just want to make a clarification regarding bypassing the output queue.  It is unlikely that passing -1 as the output queue size actually bypasses the Windows serial output buffer; according to their documentation:

The device driver receives the recommended buffer sizes, but is free to use any input and output (I/O) buffering scheme, as long as it provides reasonable performance and data is not lost due to overrun (except under extreme circumstances).

From what I have seen, Windows likes to impose a minimum output buffer size of 4096.  However, passing -1 as the output queue size will bypass the RS-232 library's own output buffer, causing each ComWrt to pass its bytes directly to the Windows serial driver.  If you use a non-negative output queue size, ComWrt will queue the bytes in an intermediary buffer, and a separate thread will empty the buffer to the Windows driver in the background.

Mert A.
National Instruments