Parity Error with specific bit sequence

[MartyG]

I am receiving VISA error -1073807254 (parity Error) from the VISA Read VI when the following hex data is received: F7 90 02 2D F3.  The bytes at port states 5 bytes availabe, but when VISA read attempts to get the buffer, it returns F7 90 02 2D 00 with the parity error.  Due to the data returned, I assume that it is the last byte (F3) that is generating the parity error.  This is the only bit pattern giving the error.  The serial port settings are as follows: 19.2K baud, 8 data bits, Even Parity, 1 stop bit.  Space parity also gives the error, but None, Odd and Mark all work properly with the same bit pattern.  I have tried NI-VISA 4.2 and 4.5 and both give the error.  If I change the baud rate tp 38.4K, the error is no longer generated.  If I use a LabVIEW 6i program using the Serial VIs instead of VISA accessing the serial port, I never get the pairty error no matter what the parity or baud rate.  In short: using the exact same hardware (cable, NI-485 board, computer) and receiving the same bit pattern, the VISA VI software gives a parity error with the Even and Space parity settings at 19.2K baud and the Serial VI software does not.  I have verified my terminations are correct & that the line biasing is correct for RS-485.  Due to the LabVIEW 6i version working, and the fact that parity error only occurs when the parity bit is a 0 for this pattern at this baud rate, I tend to believe this is an issue with VISA and not the code / hardware.  I also noted that if the data F3 is elsewhere in the data stream, no parity error is generated. This makes me believe that there is some interaction with the receiver.  I would want to blame NI-Serial, but the LabVIEW 6i software is using the same drivers and it works fine.

Any thoughts would be welcome.

[Wayne.C]

Marty,

Is the 485 in 2 or 4 wire mode?  What is transmitting the 485 data to your computer?

[MartyG]

The port in use is in 4 wire mode.  Both the Rx and Tx lines are terminated at both ends of the line (only a master & 1 slave) and biased to assure slightly greater than 200 mV in the idle state.  The device communicating with the PC is a product developed in house using a PC/104 board.  The protocol being used is MODBUS.  We have used this configuration for years and I have never seen a parity error before.  I tried to replicate the bit pattern by using other MODBUS commands.  I was able to get the pattern (hex) 90 02 2D F3 received without issue many times, but these bytes were inside a data packet, not at the end of the transmission.  MODBUS performs a CRC on the data packet and appends it to the packet for transmission.  I believe the issue has something to do with the specific bit pattern occurring at the end of a transmission with the transmitter going into the idle state.  The port receives the data without issue - the bytes at port property does not generate the error, reading the data does.  As I noted, I would typically want to blame NI-Serial, but the same hardware setup (computer, cable, termination, NI-Serial, 485 card...) using a prior LabVIEW application (LV 6i) using the serial VIs instead of VISA receives the data without a parity error.  I have not received a parity error for any other bit pattern - just this one and just at 19.2K baud.  Unless I have missed something, this means that the only difference between the two applications is that one is using the VISA VIs and the other is using the Serial VIs.

Thanks for any help you can offer.

Marty

[Wayne.C]

MartyG,

Seems suspicious that the parity bit of the last byte of transmission is causing problem.  I think I would start at the beginning and hang an O-scope on this and compare waveforms of good vs bad transmisisons.  Make sure there are no differences.

According to end of this thread http://forums.ni.com/ni/board/message?board.id=170&thread.id=146527&view=by_date_ascending&page=2 there is a way to disable the character replacement ( by default x00 ) when an error occurs and allow the questionable data to pass.

[MartyG]

Thanks again, I will disable the data replacement for VISA and retry.  I will try viewing the data with a scope, but what bothers me is that the LabVIEW 6i application performing the same MODBUS transaction receives the data packet without a parity error.  In addition, I perform a considerable amount of serial communications and this is the only pattern generating the error.

Thanks for the help - I appreciate it.

Marty

[MartyG]

Wayne,

I disabled the VISA data replacment on error per your link.  When I try the same MODBUS transaction, VISA Read now returns the correct data, albeit with the Parity Error.  I can work around the issue by verifying the CRC & ignoring the parity error if the CRC checks out.  I will take a look at the waveform with a scope to see if there is an issue causing the parity error.

Thanks once more for your help.

Marty

[JasonSmith]

Marty-

Are you able to reproduce this problem without your instrument connected, by sending this same data pattern from one port to the other? If so, I would really like to try to reproduce it here in order to see if we can tell what is going on. The following information would all be very helpful:

1. Model of 485 interface being used (e.g. PCI-485, PCI-8431, etc...) If this is an NI board, there should be a model number of the form NNNNNNA-NN (N = number, A = letter) which could tell us exactly which board is in use.

2. Version of NI-Serial, NI-VISA, and LabVIEW being used. These can be determined by expanding the software section in Measurement & Automation Explorer.

Thanks,

Jason S.

[MartyG]

Jason,

I have not tried to go between the two ports.  At this time I simply do not have the time to build a cable for the test.

I am using an NI PCI-485/2 (Isolated) board.  We have always used NI boards (ISA, PCMCIA, PCI) and have always had good luck with them.

At present I have NI -Serial 3.3 and NI-VISA 4.5 installed.

If I get some time, I'll try the port to port communication to see if the problem persists.

Marty

[JasonSmith]

Sorry, I am now thinking of a couple more items that could be significant if you could provide them:

1. Version of Windows used

2. Is the version of Windows 32-bit or 64-bit

3. Is the computer multi-processor, multi-core, or hypterthreaded?

4. How much physical memory is installed in the computer?

Thanks,

Jason S.

[MartyG]

The machine in running 32-bit XP Professional with hyper threading enabled.

It has 1 G RAM with approximately 550 M available.

I am running / debugging the VIs from within LabVIEW.

Marty