View Single Post
Old June 26th, 2013   #7
este_
Junior Member
 
Join Date: Jan 2010
Location: Germany
Posts: 24
Default

I like the idea as reporting contiguous sub-devices as virtual rootdevice, but then I see the problem of identifying this as "virtual" root device.

Going with Hamish' example, "Now we set the BLOCK_ADDRESS to 1.
Root DEVICE_INFO reports DMX Address 1, footprint of 10.
"

What will occur? When reading the device info, it will tell me:

- I have a root device with a start address and I have 10 slots used. Reading the subdevice count field, I see that I have (additional) Sub-Devices present. So I read all the Sub-Devices and find, there are ten more slots (so now I have a total of 20 slots used), and I find, the subdevice addresses conflict with what I have already read for the "virtual" root (overlap).

Wrong or right?

Thus I would assume, reporting a start address and footprint for a "virtual" root device is not possible at all without creating additional confusion... We should separate rootdevice info and subdevice info as much as possible.

I would like to offer two solutions for the problem "to enable the many controllers that don't really do sub-devices":
- add additional functionality to the controllers under review, or
- make using subdevices optional.

We have chosen the latter option. Units are shipped as root devices having a start address and a number of slots used. User can activate subdevice functionality calling a manufacturer function called "ENABLE SUBDEVICES". When done, the unit identifies itself as rootdevice using no slots and so start address, but features a number of subdevices instead. BLOCK ADDRESS will only affect subdevice addressing, and never report to rootdevice data.

Comments welcome.
este_ is offline   Reply With Quote