Serial Parity Issues with VISA Read

[mfitzsimons]

I am having issues with NI’s VISA read routine used for serial communication.  I am using a protocol that extensively uses Mark and Space parity to signify different activities between the host and device under test.  The protocol can't be modified so I have to interface it as is.

The first issue is there exist a race condition when between sending data using Mark Parity and receiving the response using Space Parity.  This needs to be done in about 1 millisecond.  The issue is that about one in 50 messages get a parity error because the bytes comes into the serial port before it is changed from Mark to Space parity.  I am using the Parity Property to change the parity.  I believe I have no control over the timing because the byte is checked in the UART Hardware as soon as it arrives.

The second issue is that the NI serial drive replaces the data byte with 0x00 if there is a parity error.  This was a nice idea to protect the user from reading bad data but in this case the data is fine but the parity is wrong.  I found on NI’s WEB site this issue in their Knowledge base:

“With LabVIEW 7.0 and greater, when NI-VISA receives a data byte with incorrect parity, it completely replaces the frame with a parity error replacement byte. The only workaround would be to read each byte twice, once with Space parity and once with Mark parity. On the frame that doesn't return a parity error you would do the aforementioned check to determine the parity bit. LabVIEW 6.1 and previous does not replace a data byte with a parity error with a parity error replacement byte.”

This leads me to the third issue.  From what I read above even though there is a parity error I should be able to set the port to the correct parity and read the byte.  The problem is the parity error seems to be discarding the byte and can’t be read again.

It would have been very helpful to have data replacement as a configurable option.  There is a long list of people having this issue so why not change the drive so it can support all who need control over the 9th bit?  It is a good idea to protect the user but you should not lock out a user by not having it non-configurable.  My only option going forward if I can’t get this resolved would be use a DLL for serial I/O.  I have attached my code if you can find a better way to solve this issue.

Matt

Using LabVIEW 7.1 and NI's latest serial driver 8.0

Knowledge Base Link:

http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/3bdc7ff03541f772862564990057f919?O...

[johnsold]

Matt,

I have not tried this, and it is not normal practice. Could you use two ports, one for transmit only - configured for Mark parity, and the other for receive only - configured for Space parity? You would need to make a special cable with a split personality. This might get messy or impossible if handshaking is required.

Lynn

[mfitzsimons]

Lynn,

I have considered this option but it has an ugly side effect of synchronizing the messaging.  Without all the details, the first byte of a message is Mark Parity and all other bytes in the message Space Parity.  The messages do stream in so any misstep would cause the data to be unsynchronized and cause even a bigger issue that I have now.  It is a good idea that I may still try but would like to save it for a last resort for the moment.

Thanks,

Matt

[tbob]

You could try to use serial property nodes to get to lower level functions.  Create a property node and wire the VISA Resource Name output of the Serial Config to the property node.  This gives you access to several serial port properties.  You could experiment with properties such as Error Replacement Character and Serial End Mode.

Whoever designed a system using separate parities for the host and terminal transmissions has a screw loose somewhere.  There are much better ways to identify the different transmissions, like headers with IDs.  I feel sorry that you have to work with such an insane system.  Good luck to you.

Message Edited by tbob on 10-11-2005 05:20 PM

[mfitzsimons]

Yes, I am using the serial properties to control the port and yes the protocol is messed up.  We all get bestowed unfavorable task with no choice but make it work.  I have attached my code for anyone's inspection to see if there are any better ways to get past this issue.

Thanks,

Matt

[tbob]

Your code looks good to me.  Very elegant and straight forward.  Looks like you might have to write a DLL that makes low level calls to the UART to get the quick response you need.

[johnsold]

You might try removing all the controls and indicators from the loop. Having those in the loop may force that node to run in the UI thread. If it runs in UI, its timing may be perturbed by mouse and video OS activity, more so than if it ran in another thread.

There are others around who know much more than I do about threads. I may be wrong, but perhaps the idea will trigger someone's thinking.

Lynn

[Henrik_Volkers]

Another point: Sometimes you can speed up response time if you disable your FIFO buffer. In Windows somewhere in the system manager ...advanced settings

I don't know how deep the VISA driver goes, but by disabling the FIFO buffer your system instantly get the interrupts.

[mfitzsimons]

Thanks all for your comments.  I have tried removing all indicators that need to be update while the program is running and raising the priority of the thread using the LabVIEW and Windows setting.  Even in real time mode I still can get parity errors.  The issue created here is the race condition of sending out a byte using Mark Parity and switching it to Space to receive the character.

Seems my options are write a DLL to handle the serial communication so I could get around the VISA routines.  I am still waiting for someone from NI to chime in if the byte is discarded after a parity error or can it still be read by other means.  I do believe that this should be a configurable option to replace the byte,  The VISA routine does notify the programmer that a parity error has happened so why not give the decision to the programmer to use or discard the byte?

Matt

[mfitzsimons]

I disabled my FIFO for com1 with the same results, parity errors.  In the advanced com settings I tried symmetrical and unsymmetrical settings for speed verse accuracy for the Tx and Rx ports.  All attempts resulted in about 1 in 100 packets had a parity error and the byte was lost.