Navigation
Rating 
Thanks 1
2 Entries
| 10/3/2009 3:09 PM | |
Joined: 10/7/2005 Last visit: 1/16/2026 Posts: 3054 Rating:
|
Hello Simotion plenty of questions, let me try to answer:
It makes no difference performancewise whatsoever which addresses you use. Let's say you have for example one DP Master and eight DP Slaves: A configuration with Master at address 2 and Slaves at addresses 3,4,5,6,7,8,9&10will perform as well aswith Slaves at addresses 30,40,50,60,70,80,90&100.
I presume you are referring to the HSA (Highest Station Address), correct? If so the HSA isONLY relevant for DP Masters and has NOTHING to do with the highest used DP Slave address (this is commonly misunderstood/cause for confusion). You could set the HSA to 2 in both of the the above examples and they will work without problems (you couldn't however add a Master with address 3 or higher to the bus in this case)
I'm afraid I'm not aware of this "rule", where did you hear or read this? (perhaps others may know this and answer you). Last but not least, a (very minor) performance gain (reduction in bus scan time) can be achieved by making sure that you have successive addresses for ALL Masters in your system. The reason for this is that everyMaster will search for another Master after it finished polling all its DP Slaves(if the so called GAP factor is set to 1, if set to 10 it will for example do so after 10 DP Slaves polling cycles). This "search" means that the DP Master will "ping"one address (a different one each scan) and then continue doing what is has to do (e.g.pass the token to itself or to another already known Master that it has in its list of active stations). Note further that each DP Master will only "ping" addresses that exist between its own address and the one of the next Master. By using successive DP Master addresses, you'll "save" the Masters with lower addresses from doing this "ping" andtheywill instead pass the token straight onto the Master with the address one above themself. I hope this helps |
Last edited by: fritz at: 10/6/2009 12:51 AMfixed up typos Cheers |
|
This contribution was helpful to
|
|
Follow us on