RS485 Communication - Parity Error

[billko]

---

@RavensFan wrote:

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.

---

Well, parity does have something to do with the cable.  How else do you end up with a different pattern of bits than was expected?  Of course, this is assuming that the data was interpreted correctly in the first place, which, as you point out, may be suspect.*

Edit:

* The cable would have to be really bad, like poor shielding and/or not twisted pair.

[RavensFan]

---

@billko wrote:

Well, parity does have something to do with the cable.  How else do you end up with a different pattern of bits than was expected?  Of course, this is assuming that the data was interpreted correctly in the first place, which, as you point out, may be suspect.*

Edit:

* The cable would have to be really bad, like poor shielding and/or not twisted pair.

---

True.  But a wiring diagram of the cable is going to prove it is a a problem.  (Especially in this case where the problem as stated was a device that doesn't adhere to common RS-xxx standards.)   It would either be a correctly wired cable and basically works unless there are other problems.  Or an incorrectly wired cable which  won't work at all.  You would only get a parity error based on a cable if it is otherwise wired correctly, but is poorly constructed, i.e. flaky.

[grimmy123]

Raven & Bill,

I had a KB of what parity is when I start having this error, anyway I'll go through again.

Here's what I'm doing,

Sending this 8 byte by U8 to String function, with Parity Mark,

Byte0  0x01   0b 1 0000 0001

Byte1  0x00   0b 0 0000 0000

Byte2  0x00   0b 0 0000 0000

Byte3  0x02   0b 0 0000 0010

Byte4  0x03   0b 0 0000 0011

Byte5  0x21   0b 0 0010 0001

Byte6  0x00   0b 0 0000 0000

Byte7  0x00   0b 0 0010 0001

The unit respond with 8 byte of data with Parity Error.

Attached the Pin diagram

[billko]

---

@RavensFan wrote:

---

@billko wrote:

Well, parity does have something to do with the cable.  How else do you end up with a different pattern of bits than was expected?  Of course, this is assuming that the data was interpreted correctly in the first place, which, as you point out, may be suspect.*

Edit:

* The cable would have to be really bad, like poor shielding and/or not twisted pair.

---

True.  But a wiring diagram of the cable is going to prove it is a a problem.  (Especially in this case where the problem as stated was a device that doesn't adhere to common RS-xxx standards.)   It would either be a correctly wired cable and basically works unless there are other problems.  Or an incorrectly wired cable which  won't work at all.  You would only get a parity error based on a cable if it is otherwise wired correctly, but is poorly constructed, i.e. flaky.

---

I pretty much agree with what you said.  In fact, your post is pretty much a re-iteration of what I said.  Which is fine, because the more different ways of saying the same thing, the better chance of everyone understanding everything.  To me "flaky" would include a cable constructed without twisted pair for an RS-485 cable.  And the diagram doesn't call out for twisted pair, so I can only guess.  That's why satin RJ-45 (flat ribbon) is improper for a network connection.

But now that that is out of the way, I agree that it looks like the problem is not with the cable.  I'm not sure how you can set up a serial port to have unique parameters for input and output.

[RavensFan]

With those 8 bytes that you receive, do you care at all that the first byte as a 1 in the 9th bit and that the other 7 bytes have a zero?

First, make sure you have parity error replacement DISABLED.

If you do not care about that 9th bit, then just read 8 bytes (do not use bytes at port), and ignore the parity error that you are guaranteed to get.  Somewhere there is a function called Clear Specific Error.   You could also use the general error handler.  Or unbundle the error code and feed it to a case structure that sends no error if it is a parity error, and passes through all other errors and warnings.

If you do care about the value of the 9th bit, then you need to read that serial port 1 byte at a time, determine if that byte is a parity error.  I would set the parity to Space right before the VISA Read.  With the data stream you have, you'd only have an error with the first byte which has a 1 as the 9th bit.

[grimmy123]

Raven,

I suspect the receiver has 8 bytes with 8 bit of data / byte and not (9 bit). I need to probe in the signal to make it sure.

Actually i'm just clearing the error as of now, but I read in some forums that if there is parity error clearing error is not a good way. So I posted here to upgrate if something I'm missing.

There is no error when writing the bytes, the error is generated only while reading the bytes. I just tried space / none / even / odd parity setting before read (as you can see in the code) but i'm not getting the data when I read it. So I stick with Parity Mark where I atleast receive the data correctly.

I'll also try the other solutions and will update you.

[RavensFan · Accepted solution]

---

Actually i'm just clearing the error as of now, but I read in some forums that if there is parity error clearing error is not a good way. So I posted here to upgrate if something I'm missing.

---

I'd have to see those particular messages myself.  I believe that statement would be correct if you were getting parity errors because of the wiring or noise problems corrupting data, but otherwise would not have any parity errors.

In your case, you can expect a parity error has normal part of operation because of the abnormal 9-bit protocol the device implemented.  So just you can just safely clear the parity error you do get.

[grimmy123]

Hi Raven,

I have analyzed the data, it's the same 9bit data / byte with first byte is Mark (1) and remaining 7 byte is space (1).

I'm gonna read the port byte by byte and check for any error's.

I'm gonna use for loop with parity changing from mark for first byte and space for the second byte. I'll post the findinds soon. 

[SSPTest]

Hi Grimmy,

Whenever you get a chance to post your findings we will be able to troubleshoot further. Any additional information you can think to share is always encouraged!

[grimmy123]

Hi SSPTest,

I hope I should clear the parity error. I didn't find any options, I have modified all the possibilities like writing into bytes or reading in bytes nothing worked.

Appreciate all your support...