E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old March 19th, 2010   #1
sondericker
Banned
 
Join Date: Jun 2006
Posts: 11
Default Self test description question

How is a controller supposed to figure out, short of querying 254 possibilities, which self test codes are defined in a responder?

Thanks,
John Sondericker
sondericker is offline   Reply With Quote
Old March 19th, 2010   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

As far as I know there is no way. I think it's reasonable to assume that Self Tests will be sequentially numbered starting from one. You can do GET SELF_TEST_DESCRIPTION starting at 1 and keep going until you get a NACK DATA_OUT_OF_RANGE.

This technique will fail if a device has non-sequential self test numbers, but I don't think this will occur very often.

Note that there is a similar situation with Sub-Devices. You can find out how many sub-devs there are, but since they don't have to be sequential, you basically have to scan every possible device until you find the number you are expecting.
ericthegeek is offline   Reply With Quote
Old March 29th, 2010   #3
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default Ouch

Quote:
Originally Posted by ericthegeek View Post
As far as I know there is no way. I think it's reasonable to assume that Self Tests will be sequentially numbered starting from one. You can do GET SELF_TEST_DESCRIPTION starting at 1 and keep going until you get a NACK DATA_OUT_OF_RANGE.
A small point to add here, I have found that the PID SELF_TEST_DESCRIPTION may not be implimented.

This is an area of the standard that could definately benefit from a revision.

Something like Get PERFORM_SELFTEST, PDL = 1, PD = $FF would return the count of available self tests.
Using PD in the range of 1 .. Count(tests) would return the status of the individual tests.

Mean while, if anybody can suggest a way out of my little dilemma (with out stopping or starting sef-tests) please comment.
hamish is offline   Reply With Quote
Old March 29th, 2010   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

A well designed responder that supports self tests really should also support SELF_TEST_DESCRIPTION. If it doesn't, then all you can do is let the user enter a number between 1 and 254, start the self test, and return an error if the responder NACKs the request.
ericthegeek is offline   Reply With Quote
Old March 29th, 2010   #5
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default Poke & Hope!

Hi Eric
Agreed.

The unfortunate consequence is that it makes the control application look somewhat hapless. In the event of no description being available, the user must be eloquently asked to poke and hope!

Any which way, it's something for developers of generic controllers to be aware of!

Cheers
Hamish
hamish is offline   Reply With Quote
Old March 29th, 2010   #6
mike_k
Task Group Member
 
Join Date: May 2009
Location: Gothenburg
Posts: 40
Default

Unfortunately the standard have quite some issues with stuff being written mainly from a responder implementation point of view where the controller side of things apparently was forgotten.
Probably we will have to at some point open the core document to make a revision for a new version of the standard to make RDM future safe.
__________________
Michael Karlsson
LumenRadio AB
mike_k is offline   Reply With Quote
Old March 29th, 2010   #7
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

> The unfortunate consequence is that it makes
> the control application look somewhat hapless.

If the responder doesn't provide the information, there's nothing else the controller can do. A well designed responder will implement SELF_TEST_DESCRIPTION.

If the user complains to you, it's simple enough to explain that fixture X doesn't provide the necessary information.
ericthegeek is offline   Reply With Quote
Old March 29th, 2010   #8
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default Multifarious consideration

Quote:
A well designed responder will implement SELF_TEST_DESCRIPTION.
Hi Eric.

Yes, while I agree that's true, would it not also be true to say that a well designed standard would foresee this, as it does (to some extent) with required PIDs?
I have here, a responder that complies fully with the standard yet does little to enhance it's reputation. My aim is to present the controller EU with a good experience without making excuses for compliant responders, which is the situation I find myself in. Obviously, in the described situation, the controller will invoke the poke & hope modus operandi.

We're in danger of accepting more holes in the standard than a conventional tea bag.

I concur with Mike and would favour mending the standard.

Time to get back to work....
hamish is offline   Reply With Quote
Old March 29th, 2010   #9
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

> I concur with Mike and would favour
> mending the standard.

I agree. But mending the standard takes years (literally).

My suggestions are merely work-arounds on how to make the best of the situation until a formal resolution can be found. Even if the standard is updated, a controller will still have to deal with responders that aren't updated to meet the new spec.

There's a similar problem with presets. You have no way to find out how many presets a given responder supports. I believe a resolution for this is under-way as part of E1.37.
ericthegeek is offline   Reply With Quote
Old March 29th, 2010   #10
Gerry
Junior Member
 
Join Date: Jan 2010
Location: UK
Posts: 8
Default

Quote:
Originally Posted by hamish View Post
Mean while, if anybody can suggest a way out of my little dilemma (with out stopping or starting sef-tests) please comment.
Hamish,
Does this responder actually expect the controller to initiate the self tests?

If the test PD's are documented in the manual, I guess you could build them into your controller, but it sucks and goes totally against the grain of RDM.

Personally, I wouldn't lose sleep over this. If a responder manufacturer includes self tests, but chooses not to allow the controller to find them by including SELF_TEST_DESCRIPTION, then I would assume they are not for general use.
Gerry is offline   Reply With Quote
Old March 30th, 2010   #11
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default You never know!

Gerry

I'm working from the perspective of a generic controller and therefore have to cater for all eventualities. I'd recommend the exercise to anyone who likes a challenge, its like a box of chocolates, you never know what you're going to get till you open it!

Quote:
If it doesn't, then all you can do is let the user enter a number between 1 and 254, start the self test, and return an error if the responder NACKs the request.
Eric's approach (Poke & Hope) remains the only option at present.
hamish is offline   Reply With Quote
Old March 30th, 2010   #12
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

There are a handful issues like this in the standard. I'm actually kind of surprised this one hasn't come up before.

So what's the best way to solve it? My suggestion would be to add a GET SELF_TEST_COUNT PID.
ericthegeek is offline   Reply With Quote
Old March 30th, 2010   #13
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

I agree with Eric, if the Responder chooses not to report the DESCRIPTION PID's then it is going to have very limited usefulness. I always advocate for the Controller to handle things gracefully whenever it can, however there is only so far you can go. If the Responder doesn't implement the necessary messages to make it useful then there is only so much you can do and I wouldn't lose lots of sleep over it.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old March 30th, 2010   #14
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default Going Forwards

Quote:
So what's the best way to solve it?
Looking toward the future, making SELFTEST_DESCRIPTION mandatory when SELFTEST are supported would be the minimum, adding SELFTEST_COUNT would make everything beautifully simple.

I don't see a problem telling the Application EU that a responder is not compliant when it's not. I'm mindful that the user of a controller should not have to know all about RDM, it should just do what it says on the box. The standard should facilitate that.

I appreciate that it's not going to be fixed in a hurry but let's not kick it into the long grass.
hamish is offline   Reply With Quote
Old March 30th, 2010   #15
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default BTW

Quote:
I'm actually kind of surprised this one hasn't come up before.
http://www.rdmprotocol.org/forums/showthread.php?t=24

Looks like this one is doing a lap of honour
hamish is offline   Reply With Quote
Old March 30th, 2010   #16
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

We also need to determine if self test numbers have to be contiguous starting at 1, or if there can be gaps in the sequence. It's simpler if you assume they'll always be consecutively numbered, but I can see a manufacturer wanting the pan test to always be test number 47, and simply skipping test 47 on devices that don't have pan.
ericthegeek is offline   Reply With Quote
Old March 30th, 2010   #17
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default

Permitting a cardinal index may be put in the same context as for personalities. For consistency, I would suggest that indexes be ordinal from 1.

In the case that an responder does not utilise a self test and chooses to maintain a standard cardinality, could this be handled by the SELFTEST_DESCRIPTION either returning PDL = 0 or NACK NOT SUPPORTED?

It could be recommended that the index be contigouse.
hamish is offline   Reply With Quote
Old March 30th, 2010   #18
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

It was always intended that these be contiguous. Things start getting really ugly if you have to start doing "discovery" to figure out where they are sprinkled out....
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old March 31st, 2010   #19
Gerry
Junior Member
 
Join Date: Jan 2010
Location: UK
Posts: 8
Default

Well I vote for non-contiquous. The way I see it, manufacturers will drop test codes for exactly the reason Eric cited above.

A better way might be to implement a "get test codes" PID in the same way as we now have the E120_SUPPORTED_PARAMETERS. Then the controller can directly get at any test code without hunting for it. Also when the "get test codes" PID is supported the Responder shall support SELF_TEST_DESCRIPTION.
Gerry is offline   Reply With Quote
Old March 31st, 2010   #20
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Implementing packed lists it just what I was hoping to avoid! The guys that have small devices really hate implementing those and many likely won't....
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old March 31st, 2010   #21
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Building packed lists on the fly can be frustrating for small devices, but when it's just a matter of sending back a canned response that never changes (Like SUPPORTED_PARAMETERS) it's not really a big deal.
ericthegeek is offline   Reply With Quote
Old March 31st, 2010   #22
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default Cardinal Index

A PID SUPPORTED_SELFTESTS would in this case be in lieu of SELFTEST_COUNT so no real difference in overhead.
I make the assumption that any responder supporting many self tests will not see an extra byte of code space for each test as a big overhead, so here I buy into the cardinal approach.

There may be a slight impact on the controller side, but in any case, less than the current arrangement demands.

I make the assumption that we're all in favour of making support for SELFTEST_DESCRIPTION mandatory when PERFORM_SELFTEST is supported.
hamish is offline   Reply With Quote
Old March 31st, 2010   #23
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

> we're all in favour of making support for
> SELFTEST_DESCRIPTION mandatory when
> PERFORM_SELFTEST is supported.

No. I'd prefer to make it a "should", not a "shall".

I'd feel differently if it were a new standard, but there are already fixtures out in the field which have one PID but not the other. Since those fixtures may never get updated, the controller has to gracefully handle that case anyway. Making it mandatory won't save anyone any work at this point.
ericthegeek is offline   Reply With Quote
Old April 1st, 2010   #24
Gerry
Junior Member
 
Join Date: Jan 2010
Location: UK
Posts: 8
Default

Scott, I don't see ther new PID as an issue. It's a fixed response, like E120_SUPPORTED_PARAMETERS PID and implemented instead of a "get count" PID. Its just that "get count" feels like wallpapering over a crack - the crack is still there.

Eric, I'm only suggesting the SELF_TEST_DESCRIPTION PID is mandatory when the responder supports the new "get test codes" PID, in the same way that
SUPPORTED_PARAMETERS is only required when actually supporting additional PID's. All existing responders are compatible since they won't support "get test codes". Without it, the controller is blind to what the test codes are for. Having said that, I wouldn't worry too much about it being should, just not optional.

Gerry is offline   Reply With Quote
Old April 28th, 2010   #25
sjackman
Task Group Member
 
Join Date: Sep 2006
Posts: 26
Default

I use GET PARAMETER_DESCRIPTION PERFORM_SELFTEST to get the minimum and maximum valid values. I had thought of PARAMETER_DESCRIPTION as only being useful for manufacturer-specific PIDs, but it seems pretty useful in this case.

Cheers,
Shaun
sjackman is offline   Reply With Quote
Old April 28th, 2010   #26
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

> I use GET PARAMETER_DESCRIPTION PERFORM_SELFTEST
> to get the minimum and maximum valid values.

That's a clever solution, but I don't think it will be widely supported.

Technically, PARAMETER_DESCRIPTION is only valid for manufacturer specific PIDs. The "PID # Requested" fields has a range of 0x8000 to 0xFFDF per section 10.4.2.
ericthegeek is offline   Reply With Quote
Old April 28th, 2010   #27
sjackman
Task Group Member
 
Join Date: Sep 2006
Posts: 26
Default

Hi Eric,

I agree, it's outside the spec. If the controller does request PARAMETER_DESCRIPTION, there's no harm done if the responder returns an error.

As a controller displaying a UI to the user, I've taken to requesting the max value (as above). If I get a response, I limit the UI to display only those tests, otherwise I display all 255.

Cheers,
Shaun
sjackman is offline   Reply With Quote
Old October 28th, 2010   #28
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default Still to be resolved

This issue is one that remains open and one I discussed at the thin end of the CPWG on Monday. Anyone who was at the last Plugfest may have witnessed the result of testing for 255 self tests, not a pretty sight.

I propose the addition of PID SUPPORTED_SELFTESTS, being a canned response. At the next revision of the standard, a minimum of "Should" be supported, although I personally would vote for "Shall" be supported, leaving controller developers responsible, as indeed they already are, for the case that that the PID has not been implemented.

Where do we go from here?
hamish is offline   Reply With Quote
Old November 2nd, 2010   #29
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Hamish,

I've got it flagged for us to look at during the next revision cycle as to how we can best solve it.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair 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
ASN.1 description of RDM sjackman RDM General Implementation Discussion 2 September 19th, 2006 10:20 AM


All times are GMT -6. The time now is 04:02 AM.


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