RS485: framing error (so called).

It's been a very long time since I've had to access these brain cells, but if memory serves my correctly (and that's a big "if"), the reason a word protocol (format is a better word) mismatch will give "sometimes correct, sometimes incorrect" responses has to do with the error checking. Error checking relies on some values being "known" with one of those values being the number of bits making up the packet of data. When the word protocol does not match between devices, the bits won't line up with regards to how the packet is assembled.
With regards to why short answers have errors and long ones (sometimes) don't, short answers will take up the entire transmission packet and if the word format is wrong bits will be out of place and the error checking will reject the packet (I.E. framing error). If the answer is long, then it will require two packets with the second packet having "fill" characters. Depending on what is in the data packet, adding those fill characters can cause the error checking sum to be correct even though the word format is wrong (I.E. no framing error). One of the things to be careful with this scenario is that even though the packet appears correct, sometimes they aren't, they just don't show an error. Having said that, sometimes the "payload" is correct even though the word format is wrong.
Again, It's been a very long times since I've had to dig this deep into serial data issues and it's possible I'm not remembering the details correctly however the concept is sound and I've seen the results EStufC is seeing many times (long ago). Each time I would see it it was almost always a baud rate or word format mismatch. The only other possibility that comes to mind is an actual protocol mismatch I.E. Modbus RTU to Modbus ASCII (for example). I have seen that one once or twice as well and depending on the equipment involved you sometimes can get communications between them (albeit very poor communications).
 
I would say that communication in one direction master ---> slave doesn't rise an issue at all. Hundred times I sent a query. I got hundred adequate answers where 95 of them had comprised distorted chars. True, it had correct number of chars. And only 5 of them receieved in correct form.:confused::confused::confused:







I'm afraid to find an answer will cost a fortune... $400...900:sick:

decode.png
 
Last edited:
You're saying two different things. You say that when you communicate from the master to the slave "doesn't rise an issue at all". I read that as there are no problems. In the next sentence you say "Hundred times I sent a query. I got hundred adequate answers..." which tells me the answers were correct ("adequate"). But the rest of the sentence reads as 95 out of those 100 answer are incorrect (distorted).
So I'm confused as to what you are or aren't seeing.
Having said that, I think you're digging to deep. This still reads (assuming you are getting framing errors) as a configuration issue. However, this is RS485, do you have a termination resistor on the last unit in the chain?
 
You're saying two different things. You say that when you communicate from the master to the slave "doesn't rise an issue at all". I read that as there are no problems. In the next sentence you say "Hundred times I sent a query. I got hundred adequate answers..." which tells me the answers were correct ("adequate"). But the rest of the sentence reads as 95 out of those 100 answer are incorrect (distorted).
So I'm confused as to what you are or aren't seeing.
Having said that, I think you're digging to deep. This still reads (assuming you are getting framing errors) as a configuration issue. However, this is RS485, do you have a termination resistor on the last unit in the chain?

Glad, you follow me. I was expecting this answer.

I have list of command and adequate answers for respective commands:

For example:

Command: ADR? implies an answer: 31CRLF. That comprises 4 Chars.
Command: BDR? implies an answer: 09600,1CRLF. That comprises 9 Chars.

SO, knowing which command you have sent and how many Chars (distorted) you have received. It's not too hard to guess what the answer is.
Moreover, I sometimes get characters in correct form, thus I have good samples.


A cable, termination, biasing: this stuff is just too simple answers for my particular case. There's something special that I'm missing. :confused:


BR
 
Last edited:
Is the bad short response always the same characters? If so. it could it represent a response from the slave indicating an issue with the command from the master.
Are there characters in the response that the master is discarding or is every character received copied into the array you've displayed? If the former it could indicate a problem with the algorithm the master uses to determine the pertinent characters in the response.
A cable, termination, biasing: this stuff is just too simple answers for my particular case.
That's a dangerous attitude to take when you're troubleshooting.
 
I stepped out of the discussion because I think it's firmware error generating a bad/wrong reply by the slave.


The master formats the message and the slave receives it, replying sometimes (infrequently) with a properly formatted reply message and more frequently with an improperly reply formatted message.


A 1 meter cable at 9600 baud should not require a terminating resistor (reflections at 9600 baud are not a problem).



I don't think noise with or without lack of biasing could cause the problem because the even parity checks would toss out bad bytes from false start bits due to biasing or noise but the replies seem to be the correct number of bytes.


Unless there's a significant electrical noise generator in the vicinity of the 1 meter 485 cable, I think it's a slave fault.



The slave is behaving badly.
 
Is the bad short response always the same characters? If so.
Yes it is.


it could it represent a response from the slave indicating an issue with the command from the master.
No, the slave understands all sent commands excellently. This is a fact.



Are there characters in the response that the master is discarding or is every character received copied into the array you've displayed?


every character received copyed into array.




That's a dangerous attitude to take when you're troubleshooting.


All mentioned above measures were taken once after it was realized that the problem persists. A long before I wrote here my first post.



BR

chars.png
 
I stepped out of the discussion because I think it's firmware error generating a bad/wrong reply by the slave.


The master formats the message and the slave receives it, replying sometimes (infrequently) with a properly formatted reply message and more frequently with an improperly reply formatted message.


A 1 meter cable at 9600 baud should not require a terminating resistor (reflections at 9600 baud are not a problem).



I don't think noise with or without lack of biasing could cause the problem because the even parity checks would toss out bad bytes from false start bits due to biasing or noise but the replies seem to be the correct number of bytes.


Unless there's a significant electrical noise generator in the vicinity of the 1 meter 485 cable, I think it's a slave fault.



The slave is behaving badly.


I agree with you... An idea, I have to compare the frames (distorted and not distorted) with modern oscilloscope. It's normal practice in serial communication world.
Moreover, most of oscilloscopes have an option for UART decoding and more.

Btw, I have two identical slaves. They have the same bad behaviour. :sick:


I'm missing something important...:confused:



BR
 
Last edited:
I'm curious. Did this ever get resolved?

I assume that in post #22 that the each of characters was received OK, but that "unreadable" or "error pattern" description is because the pattern is supposed to be ASCII and the hex characters have no ASCII equivalent.
 
I'm curious. Did this ever get resolved?

I assume that in post #22 that the each of characters was received OK, but that "unreadable" or "error pattern" description is because the pattern is supposed to be ASCII and the hex characters have no ASCII equivalent.

A tech. report: :)

It's still not resolved. I'm continueing an investigation. It's impotant stuff and I have to exert maximum efforts to get what a reason(s) is.

You know, this (I thought it will be just an usual commissioning) turned into quite serios laboratory work. As it was in Uni. :) So, I had to order some additional quite complicated facilities to continue that. Currently I'm at phase of remembering and studying how to use that and so forth.

As a side note, the both devices' manufactures said nothing useful and at the moment keep silent. I would say I'm slightly shocked. It's my normal state since I began to deal with electronics and automation, though.


If you want it will be continued here.
 
Last edited:

Similar Topics

Hi, Seeking consultation on an implementation matter, and have a question about Modicon Compact 984 communication through RS485: Three Modicon...
Replies
2
Views
76
i have an device which can support serial (RS485,RS232),CAN protocol . i want to connect it to an existing MIB 1553B bus ,what device will I need...
Replies
0
Views
55
Hi all, I am trying to do Modbus communications via the CB1241 RS485 Communication Board on a Siemens S71200 PLC. I am using a 1215C CPU. After...
Replies
6
Views
177
I'm trying to use a Red Lion Cub counter (Cub5B00) as a counter and give the cub's counts to a Graphite G12 PLC/HMI to display. After about an...
Replies
1
Views
85
Hello, I'm working on a protocol named "BitBus" which use a SDLC protocol for encapsulation. This protocol contains start & End Flag, but when i...
Replies
1
Views
138
Back
Top Bottom