Robe Robin Actor 3 in personality 6: GET_RESPONSE SLOT_DESCRIPTION violates spec

[ggallant]

Hey guys, just reporting a minor RDM bug I noticed in Robe's Robin Actor 3 while testing some equipment. Please let me know if there's a better forum for this, or if anyone knows a Robe contact to which I can send this, thanks. Our unit seems to have a very old software version, so the bug may have already been fixed.

Summary: Robe Robin Actor 3 in personality 6: GET_RESPONSE SLOT_DESCRIPTION for slots {32,33,35} violates spec.

Controllers: DMXster4-RDM, any Pathport

Responder: Robin Actor 3; DEVICE_INFO follows:
RDM proto version: 1.0
Device model: 106
Product category: 1.1
Software version: 0.0.0.11
DMX footprint: 37
DMX personality: 6
DMX personalities: 6
DMX start address: 504
Sub-device count: 0
Sensor count: 1

Repro:
1. From either controller, send a GET SLOT_DESCRIPTION for slots 32,33 or 35; observe an ACK with only 1 param data byte (0). The SLOT_DESCRIPTION spec stipulates 2-34 data bytes.
2. From either controller, Send a GET SLOT_DESCRIPTION for any remaining slot (0-37); observe the expected correct response (e.g. for slot 0, an ACK with 19 data bytes {16-bit slot id, "Special functions"}).

I didn't have time to comprehensively check the slot descriptions for the other personalities, sorry.

[porubat]

Hi,

Robe Robin Actor 3 has in personality 6 37 channels, but GET_RESPONSE SLOT_INFO return only 32 channels because first 5 channels are unused.

There is only a little bug in the channels offset which I will fix and then in the SLOT_DESCRIPTION response, when the slot number is higher than 32 which i will fix too.

I thing when you are doing a device patch, you have to use DMX mode footprint parameter, but when you get personality slots information, first you have to get SLOT_INFO and then get SLOT_DESCRIPTION based on the SLOT_INFO.

Regards

Tomas Poruba
Robe

[ggallant]

Tomas,

Thanks for your responss (and to Peter Willis for forwarding this to Robe). Unfortunately, I no longer have the Actor 3 here to play with.

As you advised, I use the first 16-bits of each SLOT_INFO as the slot # for the associated SLOT_DESCRIPTION. This seems to be the most tolerant reading of the spec, which is ambiguous in its use of "slot #", and presents conflicting info on whether or not SLOT_INFOs can skip slots.

For most (but not all) devices I've tested, the SLOT_INFOs increase monotonically from slot 0.

[ggallant]

Tomas,

Reading the spec again, my interpretation is that "slot" and "channel" refer to the same concept (slot offset), 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.

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?

[ericthegeek]

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.

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.

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.