Max Masters

[mechmike2]

I was under the assumption that the max masters setting referred to the physical number of devices on a network but as I sit here after wasting a day trying to get a bacnet network communicating it occurred to me that the max master setting may refer to the max MSTP address on the network which would explain why I can't discover some devices and have iffy comm. throughout my 5 networks. Can someone confirm or deny. I'm not looking to start another lon vs. bacnet debate.

[amigo]

max master = max mstp address, can go up to 127.
this is for token passing and auto discovery in BACnet.
A BACnet slave device is a different beast and can have mstp address beyond 127 but it is unlikely that you have slaves, you probably only have masters.
good luck.

[MatrixTransform]

max master = max mstp address, can go up to 127.this is for token passing and auto discovery in BACnet. ...

each Bacnet MSTP device is token passing .
it gets the token...talks some crap (lots of crap actually. Hmmm, prolly too much crap) and then passes the token on to another MSTP address.
not 100% sure of the precise protocol involved but it probably gets to the highest addressed device on your physical bus like MAC=50...
and then 50 goes...51 you there, I got a token for you?...psst 52, you there? ... 53...54?? anybody? ... and then there is some sort of reversion and device 0 says oh geez guys ... Ill just start at 1 again.
(or something like that!)

Set yr max master...(hmmm, yes set it on each device and the Workstation) ... to just over your highest MAC address. start yr MAC addressing at the low end rather than from 127 down. zero is normally reserved for the master controller/router/workstation/jace/whateverYourBacnetThingIsCalled

more idiocy brought to you by the land of BacNet and our friends at ashrae
Double your IQ or no money back...guaranteed.


...I'll prolly get hosed for trashing MSTP ... but man....I DO HATE IT SO MUCH!

[dracula]

Max Master is a MSTP data packet management concept that has been around long before BACnet was ever developed.

A very common cause of EIA 485 MSTP (Master-Slave-Token-Passing) discovery failure, is that one or more of the devices
(Masters) on the MSTP Buss, has their internal "Max Master" setting at a number that does not match all of the other device
"MaxMaster" settings. If you want effective token passing, all devices on the buss need to have the same
Max Master value put into their configuration settings.

Many manufacturers ship their MSTB devices with the default Max Master setting at 127 (the max number for the MSTP
device addresses on a MSTP buss). If you have only 10 devices on you buss, this default setting of 127 can slow you buss down.

I have seen some "out of the box" MSTP devices that have it default at zero. This will cause problems.

I would say, give a check of all you MSTP devices on you buss to make sure they are all set to
the same number, and that Max Master number would be the highest address plus 1.

If you want a faster buss, keep all you addresses in order, without gaps (1,2,3,4,5,6, etc)

Hope this helps.

By the way, BACnet did not design or develop any of the electronic comm busses that their BACnet data packets
and protocol ride on. They just created data sharing rules that allow BACnet data packets to co-exist within
the minimum functional requirements of the underlying electrical buss requirements.

[MatrixTransform]

By the way, BACnet did not design or develop any of the electronic comm busses that their BACnet data packets
and protocol ride on. They just created data sharing rules that allow BACnet data packets to co-exist within
the minimum functional requirements of the underlying electrical buss requirements.

Au contraire Monsieur Dracula,
the underlying bus is nothing but 2 wires....the rest was definitely designed by 'committee'.
The most annoying thing is having to explicitly set things like MM and MAC and even DevID
...that a clashing MAC will render the physical medium useless, why design a system where the MAC can clash and render the whole bus redundant. Its just silly.
...the ONLY way to find a clash is to either split the bus into smaller and smaller segments, OR visit every controller in turn with the laptop...again just silly
...Why enter MM at all? I should think a device would announce it self using part of the protocol that isnt MAC reliant, and then join the token-passing schema in an elegant way. Like merging into traffic.

Bacnet has some great features but Im afraid MSTP isnt one of them.

Polling at 78k would be near as fast for practical purposes as token passing...and no clash problems ... again just silly

A very common cause of EIA 485 MSTP (Master-Slave-Token-Passing) discovery failure, is that one or more of the devices
(Masters) on the MSTP Buss, has their internal "Max Master" setting at a number that does not match all of the other device
"MaxMaster" settings.

Pffft ... device in the bus that is getting messages to talk crap then pass the token...so that the rest of the bus can function ... and um, its just gonna sit there like a mute ... just silly

at least this thread will make people think about and understand some of the settings required .... wouldnt it be a lovely world if MSTP delivered on the promise to be simple, straight forward, fast like it promised

I would say, give a check of all you MSTP devices on you buss to make sure they are all set to
the same number, and that Max Master number would be the highest address plus 1.

LOL ... step 1 ... check each device and make sure the MAC and DevID are DIFFERENT.
Step 2 ... check each device and make sure the setting for MM in each device is the SAME.
Step 3 ... wait and see.

that definitely sums up MSTP!

[berg2666]

Au contraire Monsieur Dracula,
the underlying bus is nothing but 2 wires....the rest was definitely designed by 'committee'.
The most annoying thing is having to explicitly set things like MM and MAC and even DevID
...that a clashing MAC will render the physical medium useless, why design a system where the MAC can clash and render the whole bus redundant. Its just silly.
...the ONLY way to find a clash is to either split the bus into smaller and smaller segments, OR visit every controller in turn with the laptop...again just silly
...Why enter MM at all? I should think a device would announce it self using part of the protocol that isnt MAC reliant, and then join the token-passing schema in an elegant way. Like merging into traffic.

Bacnet has some great features but Im afraid MSTP isnt one of them.

Polling at 78k would be near as fast for practical purposes as token passing...and no clash problems ... again just silly



Pffft ... device in the bus that is getting messages to talk crap then pass the token...so that the rest of the bus can function ... and um, its just gonna sit there like a mute ... just silly

at least this thread will make people think about and understand some of the settings required .... wouldnt it be a lovely world if MSTP delivered on the promise to be simple, straight forward, fast like it promised



LOL ... step 1 ... check each device and make sure the MAC and DevID are DIFFERENT.
Step 2 ... check each device and make sure the setting for MM in each device is the SAME.
Step 3 ... wait and see.

that definitely sums up MSTP!

Please read step one above. Now that you have read it I have a question.

Why does the Mac and DevID HAVE to be different.....

I like to put the MAC address as the last two numbers of what I use for a DevID.

Are you saying that if the MAC is 12 then the DevID needs to be something other then 12?

[willf650]

The MAC and device id don't have to be different.

The MAC has to be unique on the MSTP segment.

The device id has to be unique in you BACnet internetwork which can be composed of multiple MSTP, Ethernet, IP networks.

If your entire BACnet network consists of nothing but one MSTP segment there is no reason they can't be the same.

I assume he may mean that they have to be unique to the network and not different from each other on the same device.

[MatrixTransform]

Please read step one above. Now that you have read it I have a question.
Why does the Mac and DevID HAVE to be different.....
I like to put the MAC address as the last two numbers of what I use for a DevID.
Are you saying that if the MAC is 12 then the DevID needs to be something other then 12?

Semantics ...I think yr misunderstanding me...maybe I could have put that better

MAC must be different on each device.
DevID must be different on each device
MM should probably be the same on each device

The DevID is intended to uniquely identify the device in the system whereas the MAC is meant to uniquely identify a device on a particular segment of wire.
I suppose the DevID and MAC could be the same on any given device ... makes you wonder why you'd need both in the first place though and I suspect that different Bacnet Application software will handle messages from duplicate DeviceIDs in different ways. Somebody with more broad bacnet experience will be able say, Im sure.

In Lon-land the NeuronID is equivalent to Bacnet DevID ... except that in Lon-land the Neuron is fixed and (supposedly) unique.
The NodeID is equivalent to MAC
as far as I know KMC ship each device with a different DevID and their auto addressing mechanism assigns each node its own MAC (still doesnt set MM though)...which is very lon-like.

Other bacnet controllers Ive seen needed the DevID set on each individual controller cos they come outta the box with '0'
Sometimes the MAC needs setting too cos they all come from the factory set to '0'.... Some have dip switches which makes it just a little easier.
*... hook 2 of them on an existing mstp bus and see what happens.

I despise MSTP simply because I know LON ....where you hook the wires in and basically press the button to have a nodeID set by Lonmaker or JACE or something similar.

All Im saying is that MSTP is annoying ... and that there is much confusion out there about it.

I especially resent going to site to add 3 MSTP controllers to a bus and being compelled to verify and check each and every MAC, DevID, and MM setting in every other device already on the bus ... one simple mistake ... and boom...no more comms to everything.

...its just silly... and its about time ashrae fixed it.
Too late ... its like a racehorse designed by a committee for stamina that turns out more like a camel ... lots of stamina but nowhere for the jockey.
...get rid of the hump ashrae ... you lot put it in ... now take it out.

[amigo]

I'm not looking to start another lon vs. bacnet debate.

Like OP says, let's stick to answering his question.

[MatrixTransform]

Like OP says, let's stick to answering his question.

well mate ... in a round about way it is answering his question innit?

if the process and pitfalls are understood then its easier....gotta know the beast to kill the beast.

sorry if compared to LON that MSTP looks stupid...not my problem.

[mechmike2]

I do prefer lon but you gotta do what you gotta do.

How about the max info frames, is there a different setting for each manufacturer?
I have been trying to find a spec to determine what that should be set for but all I get is leave it at default.
For a York RTU the default is 1 which seems to me would cause tons of traffic. Carrier RTU Open defaults to 10. Honeywell Spyder defaults to 20. Functional Devices bacnet relay default to 1. I would think the more info a device can transfer while it has the token the better the network as a whole would operate, but finding the pertinent information seems difficult.

[MatrixTransform]

... How about the max info frames ... finding the pertinent information seems difficult.

Now there is a question that Id like a succinct answer to as well ...

and what about APDU timeout ... what is that exactly?

anyone??

[Igotworms]

Now there is a question that Id like a succinct answer to as well ...

and what about APDU timeout ... what is that exactly?

anyone??

I believe is has to do with how the controller responds. Some third party devices take longer to respond than others. I've had problems with controllers going on and off line randomly, all I had to do was increase this time. Its just another variable to make the ms/tp trunk even more vulnerable than it already is.

[MatrixTransform]

nice brief doc from Carrier... http://www.xpedio.carrier.com/idc/gr...808-417-01.pdf

MM looks like a way to not waste time looking for nodes that arent there...
APDU looks like how long to wait before deciding to move on because on no answer...
Max INFO frames seems like a limit on how much crap an MSTP device is allowed to talk before being compelled to pass the token.

Heres the thing ...Like every polling or master-slave or token passing bus, the physical medium must be solid or the whole system is going to fall down and not work
assuming the physical is correct and the comms is robust it makes me wonder WHY arent things like MM set automatically by the network?

Adding a new MSTP device should beautomatic in my opinion too. Considering that there is already a net-wide unique devID... should be able to hook it on the bus...everybody goes 'whoa dudes...new device here" and comms moves on...in fact why have a MAC at all?? why not shunt around the whole devID its only 2 or 3 bytes bigger than the MAC...ah, but of course because somebody in the committee needs a way to ID a device on the bus with a DIP switch ... so MSTP needs just one more little address space.

[CountryBumpkin]

I was under the assumption that the max masters setting referred to the physical number of devices on a network but as I sit here after wasting a day trying to get a bacnet network communicating it occurred to me that the max master setting may refer to the max MSTP address on the network which would explain why I can't discover some devices and have iffy comm. throughout my 5 networks. Can someone confirm or deny. I'm not looking to start another lon vs. bacnet debate.

What kind of controllers are you using? I just recently had a similar problem and it ended up being controller specific...

[kc2dnw]

The issues addressed here with MS/TP here are issues of lack of understanding of basic networking in the field. Most of these issues have nothing to do with MS/TP but are issues of RS-485 and token networks. Most of the parameters discussed should be set to defaults which are typical for your style networks and layouts. The reason I have to say your style is because everyone build network differently and will have a different typology based on their design. They also have a tendency to stick to these designs over all there projects because they are familiar with them. There is no right or wrong, just familiarity. The reason these parameters are available is for flexibility in designing networks and typologies. LON has the similar types of parameters but they are built in the chip from Echlon and the user has no access to them, so as long as you follow the rules the network designers laid out when they set the chip parameters you are all good. If you can not meet their design then too bad rewire the building.

In a typical network in a Building automation world you should like never need to set most of the a parameters (besides address) unless you are pushing a network to the limits or designing a network "outside the box"

-Jeremy

[digo]

LON has the similar types of parameters but they are built in the chip from Echlon and the user has no access to them

By similar types of parameters you must mean the min/max send/receive and send on deltas - for TP/FT-10 nodes, or you might be talking about channel timeouts, packet reorder timer, and channel delay - for IP channels.

Or perhaps what you're smoking is a little strong, because those parameters are all adjustable.

[kc2dnw]

Sticking with a pure bus network (MS/TP or TP/FT-10), which is what the parameters that are being discussed are for, you can adjust the packet latency, burst data frequency, channel capture timer, etc which are all labeled as things like APDU, Max Master, etc in the BACnet world. These do not exist on the LON bus network. Once your cross into IP that is a whole different network typology on both sides of the world. I am talking about network parameters that are not protocol specific but hardware design based. These parameters in any protocol are often relabeled and made available to end users but in the case of LON they are not. This isn't always a bad thing as most people don't understand networking hardware and design enough to know what to do, it just means it's less flexible. Less flexibility translates into easier to use for the end user, until it doesn't work

-Jeremy

By similar types of parameters you must mean the min/max send/receive and send on deltas - for TP/FT-10 nodes, or you might be talking about channel timeouts, packet reorder timer, and channel delay - for IP channels.

Or perhaps what you're smoking is a little strong, because those parameters are all adjustable.

[digo]

The Lon parameters you speak of either exist and are hidden from the user or they don't exist. Which is it?

Lontalk is not a token passing protocol, so it's pretty obvious why a "Max Master" setting doesn't exist there.

[kc2dnw]

They exist within the the Echelon chip which is only modifiable by they copyright owner. All networks have these parameters, they are a function of the hardware. It is the protocols choice whether to make them modifiable or available. JCI N2 is the worse for setting parameters very low then making none of them adjustable by anybody, making network management & modification a nightmare but make it very stable.

There is no right or wrong, only different when it come to networks and protocols. Between the different applications and people different experiences you get opinions about network, but that is all they are. LON is no better then BACnet and no better then any proprietary protocol when it is looked at from a networking perspective, with a properly designed network for the protocol. When discussing application of a protocol then a whole new field of discussion opens up but it is all subjective.

-Jeremy

The Lon parameters you speak of either exist and are hidden from the user or they don't exist. Which is it?

Lontalk is not a token passing protocol, so it's pretty obvious why a "Max Master" setting doesn't exist there.