| PM | Quote | Reply | Full Topic |
| Joined: | Friday Jan 18th, 2013 |
| Location: | |
| Posts: | 17 |
| Status: |
Offline
|
i did more tests now. I've confirmed that the last DIN node is not causing the problems. As you've mentioned that each learn process polls all nodes for their type, I did a few more rounds of learning by doing the replication procedure. I get mixed results everytime after a learn. Sometimes I get randomly more than 10 multichannel nodes showing as basic, sometimes less. The best i've managed is only 2 units of 2 channel switches returning as basic nodes. And you mentioned that if the nodes do not reply in due time they are automatically classify as basic nodes. I've did a few rounds of network rediscovery with the LRC14 and re-learn again, but again, best result is 2 random nodes labeled as basic when they should be multichannel. and when they are registered as basic nodes, response wizard does not work when i declare the 2nd channel under basic set command. Only channel 0 works.
is there a way to have guaranteed msg send and receipt when the ucm is polling for node information relating to types? Is there a configurable timeout setting to lengthen the wait period for node replies? Obviously, I would appreciate if a new patch can be made to the configurator to solve the Response multichannel bug.
thanks
| Close Window |