E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM User Forums > RDM Marketplace Discussion

RDM Marketplace Discussion Discussion for any products that include RDM functionality.

Reply
 
Thread Tools Search this Thread Display Modes
Old January 31st, 2013   #1
ggallant
Task Group Member
 
Join Date: Feb 2012
Posts: 5
Default Robe Robin Actor 3 in personality 6: GET_RESPONSE SLOT_DESCRIPTION violates spec

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.
ggallant is offline   Reply With Quote
Old February 6th, 2013   #2
porubat
Junior Member
 
Join Date: Sep 2006
Posts: 9
Send a message via ICQ to porubat Send a message via Skype™ to porubat
Default

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
porubat is offline   Reply With Quote
Old February 6th, 2013   #3
ggallant
Task Group Member
 
Join Date: Feb 2012
Posts: 5
Default

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 is offline   Reply With Quote
Old February 6th, 2013   #4
ggallant
Task Group Member
 
Join Date: Feb 2012
Posts: 5
Default

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?
ggallant is offline   Reply With Quote
Old February 6th, 2013   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
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
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
SLOT_DESCRIPTION berntd RDM Interpretation Questions 13 October 19th, 2009 10:24 PM
Sub Device and Personality kster RDM Interpretation Questions 1 July 29th, 2009 09:00 AM
DMX Personality p_richart RDM Interpretation Questions 6 November 12th, 2008 09:53 PM
Personality & Subdevices kocurr RDM General Implementation Discussion 1 July 8th, 2008 09:30 PM


All times are GMT -6. The time now is 07:48 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.