decimal addresses

[allgo]

Will it be possible in future releases to store the decimal addresses not hexadecimal within a component or in each component on the network.

[Newman]

Allgo

Internally the units will always work in Hexadecimal because that's the way computers work. We have tried however to make Toolkit as decimal driven as possible because that's what feedback from the field has told us is wanted.

[Richo]

Will it be possible in future releases to store the decimal addresses not hexadecimal within a component or in each component on the network.

Could you explain further what you mean. When you say store do you mean the project XML file? By Component do you actually mean unit?

[allgo]

Richo

Could you explain further what you mean. When you say store do you mean the project XML file? By Component do you actually mean unit?
Reply With Quote

My preference would be that every project would require an on site PCI. Within this unit the project XML file will be stored. In addition this PCI should be able to supply power to the network, have a selectable hardware burden and clock enabling facility.
C-Touch units should also be able to store their individual XML files.

allgo

[Darren]

My preference would be that every project would require an on site PCI. Within this unit the project XML file will be stored.
At last count there was only one byte of spare EEPROM in the PCI :eek:

There has been discussion about storing data in C-Bus devices, but of course nobody wants to pay any extra for the extra circuitry in the C-Bus Units...

In addition this PCI should be able to supply power to the network, have a selectable hardware burden and clock enabling facility.
They currently have clock and burden. Adding a power supply is not a great idea for the PCI as you would then have to have a mains connection.

C-Touch units should also be able to store their individual XML files.
This is on the to do list.

[ashleigh]

Re storing XML in the C-Touch

This is on the to do list.
Of course, you don't get something for nothing. If you store the ORIGINAL XML, even compressed, you have less memory for other things. Through devious magic this can be improved on......

[allgo]

They currently have clock and burden.

My preference was that the burden should be selectable HARDWARE.
I would even go so far as to say, delete software burdens on all units both current and future.

[Ross]

My preference was that the burden should be selectable HARDWARE.
It is, as is the software option. You can plug in a burden or not choose to.

I would even go so far as to say, delete software burdens on all units both current and future.
That’s being a tad overzealous I think. Right now you have the best of both worlds. I don’t see it as an issue right now although I’m open to be corrected.

[allgo]

Based on personal programming experience, instruction during c-bus training and advise during problem solving with clipsal support centre, I have always been told to disable software burdens and install hardware burdens only. With this kind of recommendation I would have thought that software burdens would have been done away with by now.

[ICS-GS]

the beautiful thing about the software burden is, if you have to (for some strange reason) have to remove the hardware burden. You have the option of 'switching' one on. Also a burden and clock are automatically added when you enter learn mode (when fault finding).

[Newman]

Also, if you have no free RJ's in your switchboard then a software burden saves some wiring. You can also identify where the burden is on the network from software.