On 10/16/2013 02:03 AM, Mike Perkins wrote:> On 15/10/2013 19:35, Arlet Ottens wrote: >> On 10/15/2013 08:24 PM, Mike Perkins wrote: >>> On 15/10/2013 15:31, Grant Edwards wrote: >>>> On 2013-10-14, WangoTango <Asgard24@mindspring.com> wrote: >>>> >>>>> I've seen too many HI'Z network transceivers get stuck when something >>>>> "bad" happens. I'm kind of fond of the "Screw Auto detect" and go >>>>> with fixed addresses for special stuff and a couple BCD knobs for >>>>> everything else. Sure stops a lot of head aches, and if someone is >>>>> too stupid to know how to twist a knob, maybe they shouldn't be >>>>> installing the thing in the first place. >>>> >>>> That's fine, except that "a couple BCD knobs" can be _very_ expensive >>>> in many environments (e.g. explosion-proof or water-proof >>>> requirements). >>> >>> Except the address could be programmed using RS485 in a standalone >>> setup. >> >> It's also possible to come up with a design for auto detect that doesn't >> demand any additional reliability compared to normal communication. > > I was thinking of simplicity where peripherals are dumb units, where all > each unit needs to do is match an address and accept the data, and > possibly transmit a reply. > > The alternative is to program each peripheral with details of its > functionality, to tell the master what it is, and have the provision for > reducing effects of clashes and cope with power-downs / brown-outs > (forgetting address) etc. > > I've always liked the simple approach for overall system reliability. >Sure, reliable communications and setup require a bit of extra software. However, dip switches and other configuration require a bit of extra hardware, and manual configuration on the bench requires extra operator steps. Getting a human operator involved is likely to introduce more errors in the system than having an automatic procedure.
RS485 bus and auto-addressing
Started by ●April 27, 2013
Reply by ●October 16, 20132013-10-16
Reply by ●October 16, 20132013-10-16
On 16/10/2013 06:17, Arlet Ottens wrote:> On 10/16/2013 02:03 AM, Mike Perkins wrote: >> On 15/10/2013 19:35, Arlet Ottens wrote: >>> On 10/15/2013 08:24 PM, Mike Perkins wrote: >>>> On 15/10/2013 15:31, Grant Edwards wrote: >>>>> On 2013-10-14, WangoTango <Asgard24@mindspring.com> wrote: >>>>> >>>>>> I've seen too many HI'Z network transceivers get stuck when something >>>>>> "bad" happens. I'm kind of fond of the "Screw Auto detect" and go >>>>>> with fixed addresses for special stuff and a couple BCD knobs for >>>>>> everything else. Sure stops a lot of head aches, and if someone is >>>>>> too stupid to know how to twist a knob, maybe they shouldn't be >>>>>> installing the thing in the first place. >>>>> >>>>> That's fine, except that "a couple BCD knobs" can be _very_ expensive >>>>> in many environments (e.g. explosion-proof or water-proof >>>>> requirements). >>>> >>>> Except the address could be programmed using RS485 in a standalone >>>> setup. >>> >>> It's also possible to come up with a design for auto detect that doesn't >>> demand any additional reliability compared to normal communication. >> >> I was thinking of simplicity where peripherals are dumb units, where all >> each unit needs to do is match an address and accept the data, and >> possibly transmit a reply. >> >> The alternative is to program each peripheral with details of its >> functionality, to tell the master what it is, and have the provision for >> reducing effects of clashes and cope with power-downs / brown-outs >> (forgetting address) etc. >> >> I've always liked the simple approach for overall system reliability. >> > > Sure, reliable communications and setup require a bit of extra software. > However, dip switches and other configuration require a bit of extra > hardware, and manual configuration on the bench requires extra operator > steps. Getting a human operator involved is likely to introduce more > errors in the system than having an automatic procedure.I've never known a RS485 system put together by the client himself, and whilst my knowledge is limited to security, an installer will generally set the addresses as per the customer's needs on site. He'd also ensure that termination was appropriate to the wiring style of the network. The installer wouldn't leave the job unless it was all working. To be honest, the idea of plug and play automatic process on a RS485 network fills me with horror. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
Reply by ●October 16, 20132013-10-16
On 10/16/2013 09:15 PM, Mike Perkins wrote:>> >> Sure, reliable communications and setup require a bit of extra software. >> However, dip switches and other configuration require a bit of extra >> hardware, and manual configuration on the bench requires extra operator >> steps. Getting a human operator involved is likely to introduce more >> errors in the system than having an automatic procedure. > > I've never known a RS485 system put together by the client himself, and > whilst my knowledge is limited to security, an installer will generally > set the addresses as per the customer's needs on site. He'd also ensure > that termination was appropriate to the wiring style of the network. > > The installer wouldn't leave the job unless it was all working. > > To be honest, the idea of plug and play automatic process on a RS485 > network fills me with horror.It doesn't have to be any different. Installer comes to the site, plugs in RS485 unit, and verifies that it is automatically detected and that everything is working correctly.
Reply by ●October 17, 20132013-10-17
On 10/16/2013 1:37 PM, Arlet Ottens wrote:> On 10/16/2013 09:15 PM, Mike Perkins wrote: > >>> >>> Sure, reliable communications and setup require a bit of extra software. >>> However, dip switches and other configuration require a bit of extra >>> hardware, and manual configuration on the bench requires extra operator >>> steps. Getting a human operator involved is likely to introduce more >>> errors in the system than having an automatic procedure. >> >> I've never known a RS485 system put together by the client himself, and >> whilst my knowledge is limited to security, an installer will generally >> set the addresses as per the customer's needs on site. He'd also ensure >> that termination was appropriate to the wiring style of the network. >> >> The installer wouldn't leave the job unless it was all working. >> >> To be honest, the idea of plug and play automatic process on a RS485 >> network fills me with horror. > > It doesn't have to be any different. Installer comes to the site, plugs > in RS485 unit, and verifies that it is automatically detected and that > everything is working correctly. > >How many devices are usually in a building network ? How fast do those device enumerate with the master ? Is this discussion about a trivial function that takes a few minutes at most during install, and can be re-done automatically ever few hours with out intervention ? Seems like a problem that is not a problem. hamilton
Reply by ●October 17, 20132013-10-17
On 10/17/2013 05:01 AM, hamilton wrote:> On 10/16/2013 1:37 PM, Arlet Ottens wrote: >> On 10/16/2013 09:15 PM, Mike Perkins wrote: >> >>>> >>>> Sure, reliable communications and setup require a bit of extra >>>> software. >>>> However, dip switches and other configuration require a bit of extra >>>> hardware, and manual configuration on the bench requires extra operator >>>> steps. Getting a human operator involved is likely to introduce more >>>> errors in the system than having an automatic procedure. >>> >>> I've never known a RS485 system put together by the client himself, and >>> whilst my knowledge is limited to security, an installer will generally >>> set the addresses as per the customer's needs on site. He'd also ensure >>> that termination was appropriate to the wiring style of the network. >>> >>> The installer wouldn't leave the job unless it was all working. >>> >>> To be honest, the idea of plug and play automatic process on a RS485 >>> network fills me with horror. >> >> It doesn't have to be any different. Installer comes to the site, plugs >> in RS485 unit, and verifies that it is automatically detected and that >> everything is working correctly. >> >> > How many devices are usually in a building network ? > > How fast do those device enumerate with the master ? > > Is this discussion about a trivial function that takes a few minutes at > most during install, and can be re-done automatically ever few hours > with out intervention ?The answers depend entirely on the situation, of course. Some networks are pretty much fixed after initial installation. Others support hot plugging by the user, and require new devices to be recognized and running within seconds.
Reply by ●October 18, 20132013-10-18
In article <l3i1ro$53s$1@dont-email.me>, hamilton@nothere.com says...> On 10/14/2013 5:39 PM, WangoTango wrote: > > In article <87vc11iq2l.fsf@devereux.me.uk>, john@devereux.me.uk says... > >> "David K. Bryant" <dbryant_94585@earthlink.net> writes: > >> > >>> On 04/27/2013 08:14 PM, Michael Karas wrote: > >>>> The way I've implemented auto addressing in the past is to arrange the > >>>> serial bus connection to pass through the slave units on a gated pass > >>>> through. Initially all slaves wake up with the pass through gated open. > >>>> This causes just one slave to "see" the master. He gets the first > >>>> address and then after a confirmation step with the master closes his > >>>> pass through. The process repeats till the master realizes that no > >>>> further devices respond on the serial chain. This works like a champ and > >>>> is reliable. > >>> > >>> We have a winner! > >>> > >>> This is the best solution *AND* it remains within > >>> the original design specs.... unlike other ideas > >>> which ignore the original problem and start chasing > >>> collision detection, etc. And it can be built so > >>> that the Master does a periodic poll to see if > >>> any new Slave nodes have joined the network. > >> > >> Depends on the application doesn't it? And how the gating is done I > >> suppose. For example it looks like a node that is switched off or faulty > >> will bring down the whole network (or a big part of it). May be OK for > >> systems where everything has to be working at once anyway. But for > >> something like machine monitoring you need more flexibility. > >> > > I agree. > > I've seen too many HI'Z network transceivers get stuck when something > > "bad" happens. I'm kind of fond of the "Screw Auto detect" and go with > > fixed addresses for special stuff and a couple BCD knobs for everything > > else. Sure stops a lot of head aches, and if someone is too stupid to > > know how to twist a knob, maybe they shouldn't be installing the thing > > in the first place. > > > > I am looking at an RS485 network/buss. > > Does anyone have a good link for collision detect and timeouts. > > Google finds lots, but not very definative. > > thanks > hamilton > >It's really dependent on your application. Things like turn around time and maximum inter-byte spacing are just the beginning. How much data are you sending and how often at what rate. You know your problem domain better than anyone here.
Reply by ●October 18, 20132013-10-18
In article <akhp59tc925681mm78fcdvo4osckak5va5@4ax.com>, upsidedown@downunder.com says...> On Mon, 14 Oct 2013 19:39:42 -0400, WangoTango > <Asgard24@mindspring.com> wrote: > > >In article <87vc11iq2l.fsf@devereux.me.uk>, john@devereux.me.uk says... > >> "David K. Bryant" <dbryant_94585@earthlink.net> writes: > >> > >> > On 04/27/2013 08:14 PM, Michael Karas wrote: > >> >> The way I've implemented auto addressing in the past is to arrange the > >> >> serial bus connection to pass through the slave units on a gated pass > >> >> through. Initially all slaves wake up with the pass through gated open. > >> >> This causes just one slave to "see" the master. He gets the first > >> >> address and then after a confirmation step with the master closes his > >> >> pass through. The process repeats till the master realizes that no > >> >> further devices respond on the serial chain. This works like a champ and > >> >> is reliable. > >> > > >> > We have a winner! > >> > > >> > This is the best solution *AND* it remains within > >> > the original design specs.... unlike other ideas > >> > which ignore the original problem and start chasing > >> > collision detection, etc. And it can be built so > >> > that the Master does a periodic poll to see if > >> > any new Slave nodes have joined the network. > >> > >> Depends on the application doesn't it? And how the gating is done I > >> suppose. For example it looks like a node that is switched off or faulty > >> will bring down the whole network (or a big part of it). May be OK for > >> systems where everything has to be working at once anyway. But for > >> something like machine monitoring you need more flexibility. > >> > >I agree. > >I've seen too many HI'Z network transceivers get stuck when something > >"bad" happens. I'm kind of fond of the "Screw Auto detect" and go with > >fixed addresses for special stuff and a couple BCD knobs for everything > >else. Sure stops a lot of head aches, and if someone is too stupid to > >know how to twist a knob, maybe they shouldn't be installing the thing > >in the first place. > > While mechanical switches are OK in "friendly" environment (IP20), but > still there are problems with unreliable DIP switches for address > selection. > > However, in some harsh environment such as IP65, using an external > mechanical switch for address setting is problematic. Opening the > device in the field for address selection might (let the inert gas out > and) let moisture in, not to mention the risk of damaging the seals by > enclosure opening. > > So there are legitimate reasons for avoiding mechanical address > selection switches.Sure, but is this one of those cases? And I've seen some really nice 'O' Ring sealed and internally lubed BCD switches that would be pretty hard to screw up.
Reply by ●October 18, 20132013-10-18
In article <l3jjkr$j8i$1@reader1.panix.com>, invalid@invalid.invalid says...> On 2013-10-14, WangoTango <Asgard24@mindspring.com> wrote: > > > I've seen too many HI'Z network transceivers get stuck when something > > "bad" happens. I'm kind of fond of the "Screw Auto detect" and go > > with fixed addresses for special stuff and a couple BCD knobs for > > everything else. Sure stops a lot of head aches, and if someone is > > too stupid to know how to twist a knob, maybe they shouldn't be > > installing the thing in the first place. > > That's fine, except that "a couple BCD knobs" can be _very_ expensive > in many environments (e.g. explosion-proof or water-proof > requirements). > >OK, but *I* don't have to worry about that and the OP is pretty sketchy on just WHY this is needed, or maybe I missed that part of the thread. You can cherry pick specific reason why my suggestion won't work, but for a shit load of cases, it's just fine.
Reply by ●October 19, 20132013-10-19
On 2013-10-18, WangoTango <Asgard24@mindspring.com> wrote:>> So there are legitimate reasons for avoiding mechanical address >> selection switches. > > Sure, but is this one of those cases? And I've seen some really nice > 'O' Ring sealed and internally lubed BCD switches that would be > pretty hard to screw up.But have you paid for any of those switches? :)
Reply by ●October 20, 20132013-10-20
In article <l3u7np$a1k$2@reader1.panix.com>, invalid@invalid.invalid says...> On 2013-10-18, WangoTango <Asgard24@mindspring.com> wrote: > > >> So there are legitimate reasons for avoiding mechanical address > >> selection switches. > > > > Sure, but is this one of those cases? And I've seen some really nice > > 'O' Ring sealed and internally lubed BCD switches that would be > > pretty hard to screw up. > > But have you paid for any of those switches? :)Yes, I have, and we do. Small price to pay for a reliable system.
