Quote:
Originally Posted by ggallant
Reading the spec again, my interpretation is that "slot" and "channel" refer to the same concept (slot offset),
|
That is correct. DMX used to call them "Channels", but that term meant many different things depending on context. Starting with the E1.11-2004 revision of DMX, the term was changed to "Slot" to make it clear that a slot is a single byte within a DMX universe.
Quote:
Originally Posted by ggallant
so the first 2 bytes of SLOT_INFO is a slot offset, and the slot# in the GET SLOT_DESCRIPTION is also a slot offset.
|
Correct. For these two PIDs, Slot offset means the number of the slot within the device's DMX footprint. So, a responder that has a footprint of 37 slots would report slot offsets 0 through 36 for SLOT_INFO and SLOT_DESCRIPTION.
Quote:
Originally Posted by ggallant
So, if the first 5 slots are unused, the Actor 3 should return a SLOT_INFO list starting at offset 5. On receipt of a GET SLOT_DESCRIPTION, the Actor 3 should:
a. NR_DATA_OUT_OF_RANGE a GET SLOT_DESCRIPTION for slots 0-5.
b. ACK slots 5-36 (inclusive) with the expected label.
Is this your interpretation too?
|
For slots that are unused, my personal preference would be to respond to GET SLOT_DESCRIPTION with ACK and a text string of "(Not Used)" or something similar. But, NACK'ing with NR_DATA_OUT_OF_RANGE would also be acceptable.