View Single Post
Old February 6th, 2013   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 367
Default

Quote:
Originally Posted by ggallant View Post
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 View Post
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 View Post
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.
ericthegeek is offline   Reply With Quote