RS485 Communication - Parity Error

[grimmy123]

I have an requirement to communicate with RS485 (in house power system).

I'm using an NI USB RS485 cable. (We made a custom connector since the pinout in
the power system is different).

The system uses 9 bit mode and they are using stop bit as their 9th bit. The
purpose of the 9th bit is to verify the address (0 0r 1).

In my program I'm using the parity bit as my 9th bit, this writes the command to the system and when I read the bytes in port i'm getting a parity error.

I've searched through all the related forums and tried their solution but nothing worked for me.

[RavensFan]

Please don't attach 7z files, not everyone has 7zip nor wants to download a 3rd party app to view them when regular zip files are natively supported in windows.

Does your serial port have the possibility of setting 9 data bits?  If this "in house power system" uses the "stop bit as their 9th bit", do they have an actual stop bit after that?  (I don't know how a serial protocol would work if they didn't.

You are going to get a parity error if if the value of the parity bit doesn't match what the port expects based on the previous 8 data bits.  There is no way around that.  If you ignore the error, do the first 8 bits come through okay?

You might be able to get a serial port to work with this bit stream, but it sounds like a really hacked together protocol.  If your serial port can be set for 9 data bits, that might solve the problem.  If you can't, the I'd try to fix the device you are working with  so that it doesn't behave that way or find another device that uses some standards on its data communication.

Other things you could do is set your serial port's partity to be "mark" or "space" rather than odd or even.  Then you can use the presence or lack of an error as an indicator whether that 9th bit is a 1 or a 0.    You might be able to set your port to 2 stop bits as well.  But that is very hacky also.

[grimmy123]

Hi Raven,

Sorry about that, here is the zip file.

Yeah they Power System uses 2 Stop bit, 1 for 9th bit and other is actual stop bit.

I tried the program with all different possibility like sending the command as 9bit by enabling parity to Mark, and whil receiveing if the parity is None / space / odd  don't receive anything in the buffer. If it's Mark / even Parity I get 15 bytes of data including the sent bytes with the parity error.

Actually this is my DUT to test the communcation, this is a part of my ATE system to validate the communication.

[RavensFan]

Can your serial port be set for 9 data bits?

(I tried for the RS-232 port built into my laptop, and it gave an error.)

Can you purchase an RS-485 card that is capable of 9-bit data?

If this is your equipment you are trying to communicate with, why can't you get whoever created this equipment to standardize on an 8 bit protocol?

One of the tricky parts about a 9 bit serial port is that the data you send it is based on a standard computery byte of 8 bits.  You send a string to VISA Write (or get one back from a VISA read) and that string is actually a series of bytes that are all 8-bit.  The underlying datatypes don't have a provision for a 9th bit without doing some hacking before or after a VISA write or read.  7, 6, 5 bit protocols (7 still being somewhat common, I've never seen 6 or 5 in my life) don't have that same problem because they can all fit in a 8-bit byte.  (ASCII character or U8).

When I googled "serial port with 9 bits", the top link took me to an NI article.

http://digital.ni.com/public.nsf/allkb/3BDC7FF03541F772862564990057F919

Read that, it seems to show some tweaks you can try to make 9 bit communication work with 8 bits and parity, and get it to return the data even with a parity error.

[grimmy123]

Hi Raven,

Since the system is responding for the command state that I write with Parity Mark, I assume that it's working as 9 bit communication.

The communication method is cannot be changed because the same method is used as a master / slave communication in legacy systems as well.

Regarding the ini file, that's the first step I tried when I got that error, but still no improvement. Even making the ini file to disable error replacement to 1 I was getting parity error.

[billko]

You're sure it's not a real parity error induced by the house-built cable?

[RavensFan]

When you disable the parity error replacement, do you get a byte that makes sense for the first 8 bits?

You can expect to get parity errors.  That is normal based on the fact that the device is not trying to make that bit a parity bit.  The presence of the error or lack there of will tell you whether the 9th bit (the 9th data bit on the device side, the parity bit on your computer side) is a 1 or a 0.  As long as you get the first 8 bits through okay even if there is a parity error, you can then join the U8 that is either a 1 or a 0, with the U8 that you get from the VISA read of 1 byte.  (you'll have to typeast the 1 string character to a U8 byte.)  Now you'll have a U16 to contain that contains your 9 bits of data.

[grimmy123]

Billko,

I hope it's not, The cable connection are as follows,

[grimmy123]

Raven,

I'm getting the bytes at port if the party is mark, with/ without updating the ini file. But the parity error is still there?

The system enginner says receive is only 8 byte (only sending the data is 8+1 bit for 8 bytes), so I tried to make the parity property to none before reading. If I make it to none I don't get the data. Only if the party is Mark I'm getting the data at port.

[RavensFan]

I suggest you read up on some resources on serial communication.  I feel like you don't understand what a parity error is.

Parity has nothing to do with your cable, jus the pattern of 1's and 0's that make up a byte.  (That image is too small to read anyway.)

"The system engineer says receive is only 8 byte (only sending the data is 8+1 bit for 8 bytes),".

Be careful on your wording.  You are talking about bytes and bits simultaneously.  A given message can be X bytes long.  Are you saying that each message is 8 bytes?

If your parity is none, you get a start bit, 8 data bits, and a stop bit.  If the device is sending 9 data bits, and you set your parity to none, you won't get a parity error.  You will probably get a framing error.  And you won't get any data.

Let's say you have a pattern of 8 data bits of 1010 1010.  If your parity is even, you'll get a 0 for the parity bit (to keep an even number of ones).  If your parity is odd, you'll get a 1 fo rthe parity bit (to make an odd number of ones.)  (This gets calculated for each group of 8 data bits.)

If your parity is mark, you're looking for a 1 no matter what the data pattenr.  If your parity is space, you're looking for a 0 no matter what the data pattern.

If the incoming parity bit doesn't match up with the expected pattern, then you'll get a parity error.  With normal devices, this would be a true error indicating something is wrong with the data pattern.  With your "legacy 9-bit system" (which should be taken out back and shot), you need to hack the protocol to use the parity bit as a placeholder for the 9th data bit.  If that bit doesn't match what is expected, you get a parity error.  But in your case it is not a real communication error.

If you get a parity error, and parity replacement is enabled, then whenever you get an error, the 8 data bits are discarded and replaced with something else like the null character 0x00.  You'll get an error message.  If parity replacment is disabled, but the parity doesn't match, the 8 data bits come through okay, but you'll still get an error that you can discard as an error, but use the presence of that error to indicate whether that parity bit (the "9th data bit" on your device) is a 1 or a 0.