How do I avoid a bus collision? A question for true experts.

Go To Last Post
44 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello everyone,

There are two devices which are trying to communicate via RS485 bus, half-duplex variant.

The point of issue is, a slave is always replies too early, thus causes a bus collission. It's clear that I have to delay replying. However, there's no access to firmware of the slave.

 

Any comments, ideas, please.

 

BR

 

Last Edited: Mon. Jun 17, 2019 - 01:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Rouska wrote:
The point of issue is, a slave is always replies too early, thus causes bus collission. It's clear that I have to delay replying. However, there's no access to firmware of the slave.

Not enough info to give you an answer other then, can the slave device be replaced with one of your own design, or can you contact the manufacturer of the slave device to discuss the problem? 

 

Can you give more context to the issue?

What type of slave device, line lengths, are proper line termination and biasing being used?

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rouska wrote:
a slave is always replies too early, t
Define too early? Surely it cannot start to respond until the last bit of the last byte has left the master to trigger its response? This is the whole reason AVRs have the TXC (versus UDRE) interrupt. So you can know the moment the last bit is out then you can switch the bus direction so it's immediately ready for the response.

 

Or are you saying the slave is attempting to be full rather than half duplex and is attempting to respond even while the master is still sending cmd/data to it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

 

Can you give more context to the issue?

What type of slave device, line lengths, are proper line termination and biasing being used?

 

Jim

 

 

The slave comprises 16-bit microcontroller with 2 UARTs on board, MAX485 at output, cable length is about 2 meters.

The termination and biasing have nothing to do with this kind of issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Rouska wrote:
a slave is always replies too early, t
Define too early? Surely it cannot start to respond until the last bit of the last byte has left the master to trigger its response? This is the whole reason AVRs have the TXC (versus UDRE) interrupt. So you can know the moment the last bit is out then you can switch the bus direction so it's immediately ready for the response.

 

Or are you saying the slave is attempting to be full rather than half duplex and is attempting to respond even while the master is still sending cmd/data to it?

 

everything goes half-duplex way. And slave's reaction is being triggered by last stop bit of the master's frame.

 

it's quite hard to explain, so please wait for a GRAPH. A few minutes.

 

Updated:

Attachment(s): 

Last Edited: Mon. Jun 17, 2019 - 01:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rouska wrote:
is being triggered by last stop bit of the master's frame.
Then if you write UDR and then just sit a poll loop waiting for TXC you should be able to get the direction changed before the last stop bit out is processed. As I say, this is why the UARTs have TXC alongside UDRE (which you would otherwise use in "normal" (ie non-485) comms).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

As I say, this is why the UARTs have TXC alongside UDRE (which you would otherwise use in "normal" (ie non-485) comms).

Well the OP has not said the master here is an AVR! 

OP, why does the master take so long to change directions after the stop bit is sent?  What AVR is the master?

Can you post your 485 tx code?

I can recall is similar issue with a beagle bone driving a 485, we had to change the RS485 driver chip to one that could change directions quicker, I'll see if I can find that info on what we used.

Never mind, it was a change in the kernel driver that was the solution to that issue!

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

Last Edited: Mon. Jun 17, 2019 - 02:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you sure you are sending the proper characters, and not too many?...Maybe you sent it too much & it is simply replying & happens to collide with the last byte you are sending.

Try removing the last byte you are sending..does it still reply & without collision?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

clawson wrote:

As I say, this is why the UARTs have TXC alongside UDRE (which you would otherwise use in "normal" (ie non-485) comms).

Well the OP has not said the master here is an AVR! 

OP, why does the master take so long to change directions after the stop bit is sent?  What AVR is the master?

Can you post your 485 tx code?

I can recall is similar issue with a beagle bone driving a 485, we had to change the RS485 driver chip to one that could change directions quicker, I'll see if I can find that info on what we used.

 

Jim

 

 

 

Guys, the master comprises not AVR at all, I think.

This question is just last hope. I tired to struggle with manufactures of both devices. smiley

 

The master's manufacturer wrote us a letter. "Since millenium we are producing that device, we never heard that anyone faced with such kind of issues.

 

The slave's manufacture says the same.

 

But the problem still persists!

 

 

 

So, I need either to speed up Master's going to idle state or to delay slave's query. There's no an access to both firmwares.

 

 

So, any ideas please. The Graph is provided at #5.

 

Last Edited: Mon. Jun 17, 2019 - 02:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems clear from your graph that the master is at fault for not switching off its driver quickly enough.  Not sure what you can do about that if you have no access to either firmware.  One approach would be to lower the baud rate and see if that fixes the problem (but then you're stuck with a lower baud rate...).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:

Seems clear from your graph that the master is at fault for not switching off its driver quickly enough.  Not sure what you can do about that if you have no access to either firmware.  One approach would be to lower the baud rate and see if that fixes the problem (but then you're stuck with a lower baud rate...).

 

the manufacturer doesn't consider that as an issue at all. smiley

 

It doesn't matter low baud rate or high, the problem persists within a whole range of BDR.

 

Last Edited: Mon. Jun 17, 2019 - 02:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What are these devices?, give links to the datasheets..you say these are something purchased?  Maynbe there is some option.

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, if you don't have access to anything, I guess you will have to put some kind of buffer between the devices.

 

That is: Master -> delay -> Slave / Slave -> no delay -> Master

Last Edited: Mon. Jun 17, 2019 - 03:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

more an arbiter

https://en.wiktionary.org/wiki/arbiter#Noun (scarce is time, there's a timing issue)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rouska wrote:
The slave comprises 16-bit microcontroller with 2 UARTs on board, MAX485 at output, cable length is about 2 meters.

what happens of you add a kilometer to the cable length?

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Well the OP has not said the master here is an AVR! 
Sorry, my misguided assumption was that a question about 485 on an AVR board might actually involve an AVR - silly me! blush

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Rouska wrote:
It doesn't matter low baud rate or high, the problem persists within a whole range of BDR.

That tells me that the excess master delay is tied to the baud rate, not just e.g. interrupt latency in switching the bus driver.  Is the master configured for two stop bits?  If so, configure it for one stop bit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:

Rouska wrote:
It doesn't matter low baud rate or high, the problem persists within a whole range of BDR.

That tells me that the excess master delay is tied to the baud rate, not just e.g. interrupt latency in switching the bus driver.  Is the master configured for two stop bits?  If so, configure it for one stop bit.

 

Master 9600, even, 1 stop = Slave 9600, even, 1 stop bit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where are your links to the devices datasheets?....there will be information to understand the culprit & make the needed changes.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rouska wrote:

So, I need either to speed up Master's going to idle state or to delay slave's query. There's no an access to both firmwares.

 

I can't see how you can do that with no access to the firmware at either end.

 

The best you can do is make something that sits in the middle, receives the data from the master, waits, sends it to the slave, receives the data from the slave, waits, and sends it back to the master.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Totally looks like the TX Enable of the master is staying active too long.

 

Is the master using a crappy USB to RS485 adapter that simply uses  an RC-Diode time constant to decide when TX-EN is active?

 

What does the schematic around the RS485 transeiver look like?

 

If you can hack the slave hardware with some "blue wire" then you could also add some delay to the slaves TX line.  Maybe an 8 bit shift register clocked at 4x the baud rate.

Last Edited: Mon. Jun 17, 2019 - 07:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

andrewm1973 wrote:
Is the master using a crappy USB to RS485 adapter that simply uses  an RC-Diode time constant to decide when TX-EN is active?

 

Then the problem should go away at lower baud rates, where the fixed RC time becomes less of a single bit time, but OP says lowering the baud rate gives no improvement.  That does seem odd, because whether the delay in reversing the driver is related to software (interrupt response time) or to an RC time constant, lowering the baud rate should eventually fix the problem (even it the slower rate may be unacceptable for other reasons).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rouska wrote:

The master's manufacturer wrote us a letter. "Since millenium we are producing that device, we never heard that anyone faced with such kind of issues.

 

The slave's manufacture says the same.

 

But the problem still persists!

 

So!  Show them the issue, with scope traces and explain the issue again, just because no one else has had the problem, does not mean it does not exist....

Example, no BA 737 max had ever crashed, until it did (twice)!  How many of these (defective) devices do you buy/yr?  Time to put the pressure on them!

 

Jiim

PS: did you try adding some length of wire to see what happens as suggested above?

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

...I was going to say to look carefully both ways before stepping on the road to make sure a bus or any other vehicle is not going to run you over.....

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had issues in the past with certain PLCs not liking the response too fast. This was with modbus protocol. I wrote the slave, so i needed to delay the response. The diagram posted is confusing as the terms ‘idle’ and ‘mark’ aren't used correctly. A stop bit is an idle level and a start bit is mark level.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't worked much with RS-485, but it seems that, given all the different master and slave hardware possible to hang on the bus, some sort of configurable delay before responding (in either direction) would be an absolute must.  Just ruminating here.

Last Edited: Mon. Jun 17, 2019 - 09:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW, does a collision show up on a scope on the data line(s)?  Something like a half-voltage when the master is sending a 1 and the slave is sending a 0?  Otherwise I guess watching both master and slave driver direction bits would show the same info, or inserting a small series resistor to generate a voltage when one driver is driving hi and the other is driving lo.  I'd sure want to explore the relationship between the collisions and differing baud rates.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

my small input:

 

Can you get the master to make 2 stop bit's ? (perhaps that can help depending of what the real problem is).

 

Delay the signal from slave (and only that way I guess), with a long cable (100m+ ). 

 

And the stupid one that will work, is to delay the output from the slave with a small micro, even a tiny4 can do that job. (something like a 30kHz timer ISR, that sample output from slave, and output it 4-6 ISR's later)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
And the stupid one that will work, is to delay the output from the slave with a small micro, even a tiny4 can do that job. (something like a 30kHz timer ISR, that sample output from slave, and output it 4-6 ISR's later)

Interesting and clever idea.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hello everyone,

 

ki0bk wrote:

 

So!  Show them the issue, with scope traces and explain the issue again, just because no one else has had the problem, does not mean it does not exist....

 

Example, no BA 737 max had ever crashed, until it did (twice)!  How many of these (defective) devices do you buy/yr?  Time to put the pressure on them!

 

Jiim

PS: did you try adding some length of wire to see what happens as suggested above?

 

 

You know... A large world known company. Which way works its support system. There's a person having an Email e.g. Automato-tomato.support.com. If you are lucky it won't be a moonlighting student or sales manager.

When he or she got an email from you, he, at best, runs or makes a call to technical level to ask what he should answer on this issue or just resends your email further. At worse, he runs to sales manager and writes you that bullshit which one manager told him(her). Now, ask yourself what can say useful a moonlighting student or a sales manager in this particular case?

That's the modern system of support. You are no at communication with true experts. It's almost not possible due to their busy schedule or so.

 

We bought for this new project a couple of masters and slaves. Since it's just a test project, nobody was going to purchase a few dozen of this devices.

 

if the 20 feet cable could make 100-200us delay at least theoretically, we would use it. smiley

 

 

sparrow2 wrote:

my small input:

 

Can you get the master to make 2 stop bit's ? (perhaps that can help depending of what the real problem is).

 

Delay the signal from slave (and only that way I guess), with a long cable (100m+ ). 

 

And the stupid one that will work, is to delay the output from the slave with a small micro, even a tiny4 can do that job. (something like a 30kHz timer ISR, that sample output from slave, and output it 4-6 ISR's later)

 

I've tried to add second stop byte, just out of curiosity. it was really seen that idle state became longer exactly per 104us by 9600 bdr. The point is that I've noticed no difference, the same collission.

Concerning 30kHz timer ISR, could you shed light on that in more details (shematics, description?). It may consider that so-called stupid-working stuff for slave's programming mode only. An operation mode must be without any delayings, naturally.

 

An Update: see true diff. bus traces.

 

Attachment(s): 

Last Edited: Tue. Jun 18, 2019 - 07:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

So, if you can set stop bits, configure the master for 1 stop bit and the slave for 2 stop bits.

This will make the slave think the delay from master is a 2nd stop bit and everything should be fine, right?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
What are these devices?, give links to the datasheets..you say these are something purchased? 

 

Agreed!  Post links to these devices you are using!  MAybe someone here will know something about them and can provide a solution.   THis is more like waving a carrot in front of the horses nose.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Um. Did anybody suggest, "Look both ways before crossing the street"?

The largest known prime number: 282589933-1

In my humble opinion, I'm always right. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

So, if you can set stop bits, configure the master for 1 stop bit and the slave for 2 stop bits.

This will make the slave think the delay from master is a 2nd stop bit and everything should be fine, right?

 

Does the receiver cares about one or two stop bits ? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rouska wrote:
Concerning 30kHz timer ISR, could you shed light on that in more details (shematics, description?).

I didn't make this suggestion, but the concept is simple.  Get any micro with 1 input and 1 output.  Read the serial input on the logic-level side of the slave driver chip, delay it, and pass it along to the slave micro.

 

For timing I would want a sampling rate of something like 10x the bit timing, so for 9600 baud (104us) I'd want around 10us sample time.  But then you need to delay the bit for perhaps 1 bit time, so you have to store at least 10 input samples before outputting them.  A 16-bit software shift register would do the trick, and you could delay up to 160us for a bit of extra margin.  You don't need a timer to set the timing (simple cycle counting would work), but a timer may make things a bit easier.

 

Assuming you have set a timer for a 10us tick, the pseudo-code could look something like this:

 

forever
{
    wait_for_timer_tick
    output_delayed_bit_from_shift_register
    input_new_bit_to_shift_register
}

 

If you were running an 8 MHz clock, you have 80 cycles to perform this loop.

Last Edited: Tue. Jun 18, 2019 - 05:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

angelu wrote:

Does the receiver cares about one or two stop bits ? 

 

It should care, if you say 2 stop bits, then the receiver should at least wait that time before continuing.

 

 

edit:

Regarding the delay line theme, I recall this thread: https://www.avrfreaks.net/forum/...

It contains some useful ideas and  (quite elegant and optimized) sample code about implementing a delay line with an AVR micro.

Last Edited: Tue. Jun 18, 2019 - 08:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

perhaps the driver of the slave need to have the same delay line.

 

Just short have you remembered to give them the same ground ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did anybody suggest, "Look both ways before crossing the street"?

See #24....

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just short have you remembered to give them the same ground ?

Well, ideally you don't need to & doing so can cause severe ground loops*.  However, the actual chips have a limited common mode range, so you aren't completely off the hook--transformer interfaces are much better in this regard.

 

https://www.planetanalog.com/author.asp?section_id=483&doc_id=562062

 

*Say transmitting to the steel mill next door whose gnd is 2V above your house ground (due to the 1000''s of amps of large equipment running)....If you tie your house gnd  to the steel mill gnd via the rs485 cable, there will be a tug of war between your house & the steel mill & lots of amps will be involved!!!   Probably your cable or pcb or house will simply burn up.

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

Just short have you remembered to give them the same ground ?

 

There are a few scientific opinions in this respect. We've tried at least two.

 

Yes, both variants behave same way. It doesn't matter, whether they have common ground or not.

Last Edited: Wed. Jun 19, 2019 - 06:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

what you call 'shutdown' is the bus being released ie- not actively driven by anyone. The bias resistors determine the level. For a commercial solution, two serial<-> ethernet boxes would probably solve the issue. The likes of Perle methinks. Be sitting down when you see the price, but then again, your current commercial boxes probably aren't cheap either  There maybe cheaper serial to ethernet modules available.

 

You might want to tell us what the equipment is so we can be aware of it in the future.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

what you call 'shutdown' is the bus being released ie- not actively driven by anyone. The bias resistors determine the level. For a commercial solution, two serial<-> ethernet boxes would probably solve the issue. The likes of Perle methinks. Be sitting down when you see the price, but then again, your current commercial boxes probably aren't cheap either  There maybe cheaper serial to ethernet modules available.

 

You might want to tell us what the equipment is so we can be aware of it in the future.

 

 

The shutdown mode is a certain mode of a few MAXIM drivers. You can find a description in Maxim's manuals.

 

They are OEM highly specialized devices (PCB), so most of you will never deal with them.

 

P.S. Still nobody evaluated my masterpiece at #30. Probably there are not any issues at all. It just may be so! smiley Both are applicable for serial production.

Last Edited: Wed. Jun 19, 2019 - 10:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rouskas

 

They are OEM highly specialized devices (PCB), so most of you will never deal with them.

Can you provide links to the devices you are working with?  You might be surprised that maybe some of us might know what they are.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Wed. Jun 19, 2019 - 01:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rouska wrote:
The shutdown mode is a certain mode of a few MAXIM drivers. You can find a description in Maxim's manuals.

 

The datasheet tells me shutdown affects power consumption as both the receive and transmitter are disabled. What your picture (#30 )shows is the bus not being driven unless the trace is showing the transceiver current.

 

Rouska wrote:
They are OEM highly specialized devices (PCB), so most of you will never deal with them.

 

How do you know someone here didn't design them? I've got plenty of devices out in the field which are rather niche market. Even the company that sells them would have trouble understanding any specific engineering query about them because the designer left the company. And yes, the respond rather fast - the actual response depends on where in the actual processing cycle the request occurs, so you get a bit of jitter. I expect other devices exhibit similar behaviour.