I don't think waiting for token retry would make ZeroConfig any "safer": if there is a device with a fixed MAC at the chosen address, that device should have answered the PFM as well.
You might consider making the ZeroConfig node wait for MORE THAN ONE PFM of its chosen address before it takes the token. That would take longer (several PFM cycles), but in my view the delay might be a good thing: if a bunch of nodes from various vendors have just powered up after a building power event, they are likely to have different boot times. Waiting longer before "stealing" an address gives all nodes more time to boot up monitor or join the link under their pre-assigned addresses before the ZeroConfig free for all.
I have a number of problems with the proposed ZeroConfig in general (I like the you-are proposal much better):
1) The algorithm stretches the current state-machine description beyond the breaking point. The Extended Frame addendum makes things complicated, but ZeroConfig is beyond that. If we want to go with ZeroConfig, I think we need a new method of description. Maybe pseudo-code. There must be other standards with a format we could use.
2) Once a node starts talking at an address, my experience leads me to be skeptical of a node reliably detecting that there is someone else at the same address. If the node has any kind of protection circuitry (series PTCs or the like), it typically won't see conflicts while it is transmitting. When a token is sent to an address, any and all nodes that think they own the address will begin talking more or less at once. When they send, the recipient(s) MAY see CRC errors due to collision. Or they may see the message from the node next door swamping out the message from the guy at the other end of the long cable.
I presume that the purpose of sending the Test message is to hope for a collision. I guess we would get a chance to see how many people have actually IMPLEMENTED Test...
I suspect that you already have an implementation of this running. And with a bunch of devices from one vendor, it might even work pretty well. But with nodes from various vendors I am skeptical.
] On Behalf Of Steve Karg
Sent: Monday, July 23, 2012 11:01 AM
Subject: Re: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?
Hi MS/TP working group!
Since we are discussing Token retries...
I received some comments a week ago from an engineer (Bill) at Siemens
(via Bernhard) on the Zero Config MS/TP proposal that is sitting in
SSPC. He had some of the usual critique that we have already
discussed in our working group, but he also had a small suggestion.
He suggested having the ZeroConfiguration nodes only respond to the
Token on the Token Retry, allowing any legitimate fixed MAC nodes
access to the first Token. My thoughts were that this practice would
make the MS/TP network sluggish and prone to dropped Tokens for
ZeroConfiguration nodes, but it would provide better protection for
fixed MAC nodes (it could even offer the full range of Master Node MAC
addresses for ZeroConfiguration nodes).
Yahoo! Groups Links
The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.