RS485 half-duplex ideas?
annuello
Junior Member
Hello all,
The context is with a lighting system (RS485 half-duplex) that seems to send out a "heartbeat" on the bus every 0.7 seconds, as well as additional data at irregular intervals. Up until now I have just send my strings to the bus regardless of whether another device is currently using the bus. I believe (though I can not confim) that some of my commands are creating collisions and as a result, are not being performed. All data from the lighting system is currently ignored.
I'm looking for ideas & suggestions on how to safely code for half-duplex RS485 busses. My initial guess is to set up a receive buffer that, when data is received, a "bus in use" flag is set, then cleared 0.1sec later. My code would then wait until the flag is cleared before sending data. Is this a good approach, or is there a more effecient way to handle the situation? Both Axcess & Netlinx ideas are welcome. I'm currently using an Axcent3, though it will be upgraded to an NI-700+Axcent3_slave in 12 months time.
Annuello.
The context is with a lighting system (RS485 half-duplex) that seems to send out a "heartbeat" on the bus every 0.7 seconds, as well as additional data at irregular intervals. Up until now I have just send my strings to the bus regardless of whether another device is currently using the bus. I believe (though I can not confim) that some of my commands are creating collisions and as a result, are not being performed. All data from the lighting system is currently ignored.
I'm looking for ideas & suggestions on how to safely code for half-duplex RS485 busses. My initial guess is to set up a receive buffer that, when data is received, a "bus in use" flag is set, then cleared 0.1sec later. My code would then wait until the flag is cleared before sending data. Is this a good approach, or is there a more effecient way to handle the situation? Both Axcess & Netlinx ideas are welcome. I'm currently using an Axcent3, though it will be upgraded to an NI-700+Axcent3_slave in 12 months time.
Annuello.
Comments
-
Not all RS-485 busses are created equal. Some operate with a "master" that polls the line and queries if any of the "slaves" have data to transmit, then manages said transmissions on a priority basis (I believe this is how Axlink works - it's also half-duplex 485). Others do as you describe - wait for the buss to settle, then transmit their data. This, of course, doesn't guarentee two devices won't decide to transmit simultaneously. Others simply send out data without regard to buss activity, and keep re-sending until acknowledged. In the first case, the master manages all collisions, and all you need to is wait for the query before sending. The latter two both require your data is acknowledged to be in any real degree reliable.
I would guess your lighting system is one of the latter two. I don't see any downside in waiting for the buss to settle, even if the rest of the devices do not - unless the buss is so chatty it never actually settles. But that is the route I would take. You could do it in Axcess by setting a flag in a named wait when you see activity on the buss. Any further activity would have to reset the wait (cancel it and restart) and the flag. When your wait times out without being reset, your flag drops and you can send. If your "master" on the lighting system doesn't acknowledge your data, you may want to send everything a few times to make sure it gets through.
It occurs to me that I have seen yet another way of managing 485 - where all the devices monitor the line and send their data sequentially. In other words, device 3 holds it's data until it sees device 2 report, unless a timeout occurs, whereupon it sends anyway. I believe this is how the Viewstat thermostats operate. -
Thanks Dave,
It's nice to know that I was on the right track.
Annuello.
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums