Toolkit errors when saving to network

When trying to save a change to the dlts on my network, i get an error - it doesnt complete and doesnt save.

It loads the info all ok from the network (as well as the local db) - gets to 65% and says "Unit failed to save to the physical unit"

Tried on a few dlt's happened in toolkit 1.5 as well (now using 1.6)

Saving to a 4 button saturn works ok. Tried also changing the dlt text - same thing.

Created a blank new network, copied the information from the network to local - tried to change - same thing (so im assuming local db is ok)
Tried unravelling - nothing.

Any ideas how we can troubleshoot this ? Cant program the damn things !

Ta

ps this shows up in the local toolkit log window thing - i cant see a conflict there to resolve (hence the unravel above). Unit 13 is the 4 button saturn which seemed to work ok

20070128-231232 840 //PLCBUS/254 cb3befe0-8ddc-1027-9b69-917f11dd69c2 Orphaned c
ommand reply for unit 13 (suggests unit address conflict)
20070128-231232 840 //PLCBUS/254 cb3befe0-8ddc-1027-9b69-917f11dd69c2 Orphaned c
ommand reply for unit 13 (suggests unit address conflict)
20070128-231233 840 //PLCBUS/254 cb3befe0-8ddc-1027-9b69-917f11dd69c2 Orphaned c
ommand reply for unit 13 (suggests unit address conflict)
20070128-231406 751 //PLCBUS - Tag information changed at tag address: //PLCBUS/
!76b59170-9f01-1027-8a99-bd6a9f6c47e8 oldtag: LOUNGEDLT newtag: LOUNGEDLT
20070128-231406 751 //PLCBUS - Tag information changed at tag address: //PLCBUS/
!76b59170-9f01-1027-8a99-bd6a9f6c47e8 oldtag: LOUNGEDLT newtag: LOUNGEDLT
20070128-231406 751 //PLCBUS - Tag information changed at tag address: //PLCBUS/
!76b59170-9f01-1027-8a99-bd6a9f6c47e8 oldtag: LOUNGEDLT newtag: LOUNGEDLT
20070128-231406 751 //PLCBUS - Tag information changed at tag address: //PLCBUS/
!76b59170-9f01-1027-8a99-bd6a9f6c47e8 oldtag: LOUNGEDLT newtag: LOUNGEDLT
20070128-231406 751 //PLCBUS - Tag information changed at tag address: //PLCBUS/
!76b59170-9f01-1027-8a99-bd6a9f6c47e8 oldtag: LOUNGEDLT newtag: LOUNGEDLT
20070128-231406 751 //PLCBUS - Tag information changed at tag address: //PLCBUS/
!76b59170-9f01-1027-8a99-bd6a9f6c47e8 oldtag: LOUNGEDLT newtag: LOUNGEDLT
20070128-231413 827 //PLCBUS/254 cb3befe0-8ddc-1027-9b69-917f11dd69c2 C-Bus Send
Error: (#)(retrying)
20070128-231413 827 //PLCBUS/254 cb3befe0-8ddc-1027-9b69-917f11dd69c2 C-Bus Send
Error: (#)(retrying)
20070128-231453 840 //PLCBUS/254 cb3befe0-8ddc-1027-9b69-917f11dd69c2 Orphaned c
ommand reply for unit 21 (suggests unit address conflict)

 

I was having a look around the config, and noticed the pc interface did not have the software burden set. very very odd.

i have never used a physical burden, and i think thats the only place i can set a burden ? that device is set to id#0

 

All PC interfaces, network bridges, system support units and output units can function as the network burden. It is only input units (key units, PIR sensors, etc) that do not have the network burden function.

Make sure you check out all the other units on your network that can function as a network burden. You need only 1.

 

Software V's Hardware Burdens

theboyg,

Like you, we have always used software burdens (about 3 years now).
In the last two months we have had three projects where the software burden appears to have failed. Generally the job runs smoothly for a week or so, but when we go back all three have had connectivity problems - ie: either the network will not open or can't scan the network. Plugging in a hardware burden has worked each time. In each case checking the unit GUI from the network shows the software burden is still enabled.

The first one we encountered sounds similar to what you experienced. As the day went on we went from no problems to not being able to change DLT text, to not being abe to open DLT GUI's (all other units were OK at this stage), to not being able to scan the network at all. This all happened over a period of about three hours.

We checked all the obvious things (software burden, clocks, voltage, number of units, cable length etc). Again, plugging in a hardware burden fixed it immediately. To date this project still runs a hardware burden with no problems since.

Currently working with CIS Brisbane on this one and will post any results.

Mark

 

I have a small network - 18 switches, 2 din dimmers, 2 relay din units, a pci, and a comfort module.

Even with the burden enabled, i still get these orphaned messages

 

I think that the physical burden is necessary and most reliable. I always use it.

 

I'm willing to rewire to support that if we have to.

The system has been up for 2 years so far without any problems - this has only started happening recently.

Do CIS know what is causing this ? Not neccesarily how to fix this.

 

No rewiring. The burden is a small dongle with a RJ45 plug. Just plug into any free RJ45 port on you C-Bus network. You will need one for each C-Bus Network you have.

 

Thats exactly why I need to rewire - there are no free sockets. The last one feeds into the Comfort CBUS module (doesnt use an rj45 socket)

Hence Id rather not do this - will CIS comment on whats going on here ?

 

Yep.... we can't tell from the posts here. If you contact Tech Support they can run through suggestions on the phone which will fast track the process.

http://www2.clipsal.com/cis/technical/technical_support

 

roger that...

 

Think I've found it.

Was the Comfort CBUS SIM module.

Seems ok now thats fixed.