Serial Read (RS 232) : No Data

[spandya2]

Hello,

I have a particular problem with reading RS 232 data into labview. I am providing the background, the exact problem, and the (failed) steps that we have taken.

Background: We have a custom designed board for a particular application on which we have a Xilinx CPLD. We are aiming for basic, low-level communication through serial RS 232 communication. On the PCB, we have two individual pins (XMIT & RECV) and not an actual serial connector. On the controlling PC with labview, we have a standard COM port controlled by a Labview VI. Eventually, we have a custom VI under design, but for now, we are using the Basic Serial Write/Read VI included with Labview. We are currently not using any flow control since we want to get basic communication working before we add advanced features such as flow control, sentinel signalling, encryption, etc.

Problem: We are able to successfully write by wiring the TX pin (Pin 3) to the RECV pin on the PCB. We are writing in ASCII (since we can't write in basic binary -- see http://forums.ni.com/ni/board/message?board.id=140&message.id=9912#M9912), but we are able to successfully decipher the ASCII on the CPLD. The problem occurs when going the other way. We are writing out a simple binary stream from the XMIT pin on the CPLD. We have a power conversion circuit that allows the voltage levels to be converted from 0 to 3.3 V (logic) to -10 to 10 (serial standard). The circuit also makes sure that the waveform is not inverted, thereby making sure that the stop bits are in the correct position. Even with this, we are not able to read any data onto the Basic Read/Write VI. We are sure that the data is appearing at the serial port on the RIGHT pin, but for some reason the Labview VI is unable to detect.

We have used Measurement and Automation Explorer to try Basic I/O on the COM port, and try to force a read. That is not successful either. Do we have to have flow control? Do we have to assert DTR to read? According to the basic VI, we thought that all this wasn't necessary.

Please offer any suggestions we may have. Please note that we are using custom PCB and not an NI DAQ (which we have used in the past). This is application-specific and so our hand was forced.

Thank you in advance.

Regards,

MASS Team

[spandya2]

Hello,

One more update:

We tried directly connecting Pin 3 of the Serial to the Pin 2 (Without the Board). In other words, we want to see if Labview can read what it writes. We tried writing a variety of ASCII characters out. None of them can be read! Is there a backend way to get this to work. Surely Labview should be able to read what it writes, given that the baud rate, the flow control, and all the other variables stay constant.

Please assist.

Thanks.

[LuI]

Spandya2,

your postings sound a little desparate ;-(.

Allthough I have never ever used a PCB as serial communications partner, let me try to jump in.
I have had a lot of projets communicating with µC based self-made devices on one side and LabVIEW on PC on the other.
We do produce medical devices, so we try to limit the direct connection wires to the absolute minimum, because each wire needs optical decoupling for safety reasons.

Depending on what we want to achieve, we try to get everything done by just using two wires, Txd & Rxd. We often use baud artes between 9.6 and 115.2 kBaud, 8N1.

My LabVIEW setup is than this:
1. 'VISA open' with defaults, except 'timeout' (for opening) is set to 100 (ms).
2. 'VISA configure serial port' with the 'VISA ressource name' as returned from 1., all others are defaults except 'timeout value' (for I/O) is 500 ms, 'flow control' is 'none' and 'Enable Termination Character' is 'false'.
3. Now I use the 'VISA ressource name' to write and read with the ressource.

There might be some pitfalls, especially when not using an UART on both sides. Remember, serial comm is restricted by some very tight time framings. A baud rate of 9600 baud means that a full character (8 bits) together with start & stop bit (10 bits), has to be transmitted within 1/9600th of a second (~104µs). This is usually be done with level changes, so there might be up to 20 level changes. So there is a time frame for each level change of 5 µs. If your PCB is not capabel of fulfill that level changes within the time frames of ❤️ µs, you might be better of using an UART Chip. Those have internal character buffers of up to 255 chars and take care for the serial transmission. So the real-time needs for your board is limited to about 128 chars * 104 µs, about 12 ms or even lower. This is much easier to do with interrupt service routines.
If your PCB does not support ISRs, you may as well try to communicate by sending every string from LabVIEW to it as a series of single characters. So use a for loop that takes one char after the other from your string and send it out with VISA write. This takes by far longer than writing the whole string in a single write operation. But it gives the PSB enough time to read the actual character before LabVIEW overwrites it with the next one.

You mentioned in your first posting that you can't write binary data. That's not true, at least on the LabVIEW side. VISA serial write & read use LabVIRÉW strings that are written or read from the device. LabVIEW strings are more like Pascal strings; they have a length value coupled with it and may as well contain any binary characters including ox00.

On more hint I might offer. There's a tool called NI-Spy that seems to be installed together with LabVIEW. On my system it is installed under /National Instruments/NI Spy/NISpy.exe. This one can trace all I/O operations down to a very basic level. It might help you determine where your comm is blocked.

HTH and
Greetings from Germany!
--
Uwe

[JoshuaP]

Looking at your second post, you are correct in trying to get the loopback to work. If LabVIEW isn't able to do that then you might try a Windows program like Hyperterminal. If the loopback is connected you should be able to see on the screen what is written out. If you don't see anything then some thing is wrong with your loopback or your RS232 port is bad. If hyperterminal does work we have problems.

-Josh

[spandya2]

Hi guys,

Thank you all for your help, but still no luck. I tried doing a basic loopback test, and captured the information in NI-SPY. I've posted a screenshot of the NI-SPY output. Notice that the write function successfully wrote 6 bits, but the read failed. I tried looking the error code (status) that it gave back, but with little success.

Any help would be greatly appreciated.

Thanks!

-spandya2

[spandya2]

One more update:

After reading documentation online on the readasync() function, I right clicked on the node to do asynchronous reading. NI-SPY now shows that the readasync() function starts and completes, but the error code still persists. Furthermore, the readasync function apparently doesn't read anything! (0 bytes)

[JLS]

Hello,

The following is what I suspect:

1. Your custom PCB is not sending back serial compatible frames.
2. You did not include a termination character when attempting the loopback test (and termination will be enabled by default if you use the Configure Serial Port VI in LabVIEW.

The solution to 1. will be to make sure that your PCB sends serial frames as dictated by the standard. The solution to 2. is to include a linefeed character (deimal 10 or 0x0A) as the last character you send out; the data you send will then be read in provided you specify to read at least the number of bytes you expect to read. You mentioned flow control, but you should not have to worry about this at the LabVIEW end; no flow control will be used by default.

In general, the following things will happen when attempting to read:

1. You receive a parity error if such an error was detected.
2. You receive a framming error, indicating that your sending and receiving baud rates are different.
3. You receive a timeout error, indicating that you did not receive a). the number of bytes specified before the timeout period, or b). if termination is enabled, the termination character specified.
4. You receive the bytes you specified to read.

The first two in the above list of four are irrelevant when performing a loopback test. I believe you are likely encountering the 3rd, while after including a termination character (or reading exactly the number of bytes written) you will be in case 4.

Good luck and repost if you continue to have problems!

Best Regards,

JLS