Self test description question

[sondericker]

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

[ericthegeek]

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.

[hamish]

Originally Posted by ericthegeek

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.

[ericthegeek]

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.

[hamish]

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

[mike_k]

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.

[ericthegeek]

> 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.

[hamish]

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....

[ericthegeek]

> 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.

[Gerry]

Originally Posted by hamish

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.

[hamish]

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!

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.

[ericthegeek]

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.

[sblair]

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.

[hamish]

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]

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

[ericthegeek]

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.

[hamish]

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.

[sblair]

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....

[Gerry]

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.

[sblair]

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....

[ericthegeek]

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.

[hamish]

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.

[ericthegeek]

> 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.

[Gerry]

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.

[sjackman]

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

[ericthegeek]

> 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.

[sjackman]

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

[hamish]

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?

[sblair]

Hamish,

I've got it flagged for us to look at during the next revision cycle as to how we can best solve it.