LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial Communication - Ignore Parity Error

Solved!
Go to solution

I have a question about the way LabVIEW opens a serial port for communication. I'm communicating with a device that uses a proprietary protocol; it sets and clears the parity bit to indicate the nature of the response. For example, commands are sent with parity bit high while responses are sent with the parity bit low (unless the response is the end of the transmission, in which case the device sets the parity bit high to indicate this).

 

My problem is the way that LabVIEW opens the serial port for communication. Using Portmon, I captured the control flags it sends to Windows to setup the serial communication:

 

IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: 1 Parity: MARK WordLength: 8

IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13

IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace:44 XonLimit:64 XoffLimit:64

 

 Notice the "Shake" and "Replace" values. I believe these are causing bytes with parity errors to be discarded. A separate RS232 Comm Debug tool I'm using successfully looks like this:

 

IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8

IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13

IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:0 Replace:80000000 XonLimit:128 XoffLimit:128

 

 Note the difference in values. Using this tool, Windows doesn't replace packets with parity errors - this is what I want. Is there no way to change the way LabVIEW is opening the serial port for communication to accomplish this?

 

I've tried switching the parity mode every time the bit is set differently, but I think I'm running into a race condition; LabVIEW can't execute the code and switch the parity mode fast enough before the next byte of data is sent by the device. 

 

 

Message Edited by Brad G on 04-08-2010 09:17 AM
0 Kudos
Message 1 of 4
(7,132 Views)

For reference, this seems to be the problem here: http://zone.ni.com/reference/en-XX/help/371361D-01/lvvisaprop/replace_char_serial_instr/

 

In the MSComm control, if you use an empty string for the ParityReplace property, the error replacement will be disabled altogether. Is it possible to mimick this behavior in the Instr class? 

0 Kudos
Message 2 of 4
(7,125 Views)

There is a property node called "Error Replacment Character" or "Replace Char" that determines which character to use as a replacment if there is a parity error.  I don't think there is a way to not replace the character.

 

But the question is, why would you not replace the character?  If there is a parity error, then the character that came in has no known valid meaning.  If you have a parity error, you've got bigger problems that are interrupting your communication.  And if you don't care about parity, then why turn it on at all?

0 Kudos
Message 3 of 4
(7,118 Views)
Solution
Accepted by topic author Brad G

Ravens Fan: The parity bit, in the proprietary protocol I have to use, isn't used for parity checking. Basically, the protocol is using a 9-bit serial communication. The parity bit has to be set or cleared depending upon what that byte is doing (if it's a command, if it's the end of transmission, etc.).

 

I found an old post on this page that seems to answer my question (my apologies for not thoroughly searching before posting... I'm learning the right phrases to use/search for as I find more information). I'm downloading the 3.4.1 version of VISA right now.

0 Kudos
Message 4 of 4
(7,112 Views)