Slot_Info / Slot ID Type-Slot Category/ID implementation issue

[Thierry Dupont]

Hi Everyone,


We are struggling with the implementation of Slot_Info. The standard can be confusing.


Below is the example of the most complicated Personality that we need to implement. We are not sure at all if it is correct. Integrity does not flag up anything and we are not sure either how we can try it.

Is there anyone who can check this over and telling if we are wrong or not?
Thanks.



Followspot 16bit:
Dimmer 16 bit:
Slot Type 0x00 Slot ID 0x0001
Slot Type 0x01 Slot ID 0x0001
Master 16 bit:
Slot Type 0x00 Slot ID 0x0002
Slot Type 0x01 Slot ID 0x0002
Strobe Duration 8bit:
Slot Type 0x02 Slot ID 0x0404
Strobe Speed 8 bit:
Slot Type 0x03 Slot ID 0x0404
Response Time 8 bit:
Slot Type 0x02 Slot ID 0x0502 or 0x0503
Control Mode 8 bit:
Slot Type 0x04 Slot ID 0x0502

[sblair]

Thierry,

It does take a bit to wrap your head around. Here's a couple previous threads on it where I've given some detailed examples that I think should be useful in understanding the relationships on dependencies and secondary slot types.

https://www.rdmprotocol.org/forums/s...highlight=slot

https://www.rdmprotocol.org/forums/s...highlight=slot

We also did a Webinar on this topic. You'll find about halfway through it we go through some concrete examples and detailed explanations on Slot_Info. https://www.youtube.com/watch?v=-5BmsJ7CeFE

[sblair]

edit: Added the youtube link: https://www.youtube.com/watch?v=-5BmsJ7CeFE

[Thierry Dupont]

Thanks Scott
Before posting we looked at the Webinar and the different examples and we did it again.
We did some corrections and it seems working on a specific controller but still we are not sure about one thing, see list below (generated by RDM Integrity)

Mode X
Dimmer
Dimmer fine
Master
Master fine
Slot Offset [0x0000, (0)]
Slot Type [0x00, (0)] Primary Slot
Slot Label ID [0x0001, (1)], Intensity
-------------
Slot Offset [0x0001, (1)]
Slot Type [0x01, (1)] Secondary Fine
Slot Label ID [0x0000, (0)], Slot Label ID Undefined Entry [0x0000, (0)] ----It is given by integrity and we are wondering if the Slot Label Id should not be 0x0001 as we did below with Intensity Master.
-------------
Slot Offset [0x0002, (2)]
Slot Type [0x00, (0)] Primary Slot
Slot Label ID [0x0002, (2)], Intensity Master
-------------
Slot Offset [0x0003, (3)]
Slot Type [0x01, (1)] Secondary Fine
Slot Label ID [0x0002, (2)], Intensity Master

We wanted to use more secondary for Strobe but the controller does not like it and we decided to use only primary.
World wide how many controllers are really using Slot_ID?

[peternewman]

I'd agree it certainly gets a bit confusing, especially with the overloading of slot label ID. I think I left some feedback on the latest public review cycle to try and improve it.

I decided to try emulating your two personalities in OLA, as it only took a few minutes and gave a good opportunity to test out the OLA RDM Responder tests to ensure we were catching the various issues.

For your second personality, the raw data is effectively (if I've interpreted your description correctly):

{'slot_label_id': 1, 'slot_offset': 0, 'slot_type': 0},
{'slot_label_id': 0, 'slot_offset': 1, 'slot_type': 1},
{'slot_label_id': 2, 'slot_offset': 2, 'slot_type': 0},
{'slot_label_id': 2, 'slot_offset': 3, 'slot_type': 1}

Which comes out of our pretty printer described as follows:

Slot offset 0: Primary, intensity
Slot offset 1: Secondary, fine control for slot 0
Slot offset 2: Primary, intensity master
Slot offset 3: Secondary, fine control for slot 2

Which appears to match your description of two 16 bit channels.

The OLA RDM tests don't throw any errors as expected.

Regarding:

Slot Label ID Undefined Entry [0x0000, (0)] ----It is given by integrity and we are wondering if the Slot Label Id should not be 0x0001 as we did below with Intensity Master.

I'm pretty certain that's a bug in Integrity. There is no primary slot definition of 0x0000 as they start with SD_INTENSITY at 0x0001, but that slot is a secondary slot so:

For secondary types, the Slot ID/Offset field contains a slot offset for the parameter to which it relates. For example, a 16-bit pan function in slots 1 and 2 would use ST_PRIMARY/SD_PAN for slot 1 and ST_SEC_FINE/1 for slot 2.

The confusion being "Slot ID/Offset" doesn't exist in the diagram, but the slash in the examples is fairly clearly denoting the different fields. The latest draft that went out for review fixed that bug.

If you consider a fixture that just had pan and tilt say (one of those funky mirrors maybe), it gets far less confusing as there is no numeric overlap and you'd end up with something like this:

{'slot_label_id': 0x0101, 'slot_offset': 0, 'slot_type': 0},
{'slot_label_id': 0, 'slot_offset': 1, 'slot_type': 1},
{'slot_label_id': 0x0102, 'slot_offset': 2, 'slot_type': 0},
{'slot_label_id': 2, 'slot_offset': 3, 'slot_type': 1}

We wanted to use more secondary for Strobe but the controller does not like it and we decided to use only primary.

Strobe is a primary, or do you mean say two secondary values such as timing and speed for frequency and duty cycle?

World wide how many controllers are really using Slot_ID?

OLA doesn't implement it in it's web UI yet. I can tell you the OLP RDM Manufacturer Index has 180 entries for particular software versions of responders which support the SLOT_INFO PID (of 327 total, although some have no supported parameters data)

[Thierry Dupont]

Thank you Peter to spend some time looking at our issue.

It is becoming clearer but still I would like if I may getting some precision just to make sure.

Personality for a 16 bit Dimmer:

Slot Offset [0x0000, (0)]
Slot Type [0x00, (0)] Primary Slot
Slot Label ID [0x0001, (1)], Intensity
-------------
Slot Offset [0x0001, (1)]
Slot Type [0x01, (1)] Secondary Fine
Slot Label ID [0x0000, (0)]

In our example above (which is implemented as it is) regarding the Secondary should we have?
Slot Label ID [0x0001, (1)], Intensity
or Slot Label ID [0x0000, (0)]

Currently we have Slot Label ID [0x0000, (0)]

Quote:
We wanted to use more secondary for Strobe but the controller does not like it and we decided to use only primary.

Strobe is a primary, or do you mean say two secondary values such as timing and speed for frequency and duty cycle?

We meant two secondary values as timing / one for duty cycle and one for frequency. The responder that we worked with cannot handle very well secondary.

We learnt the hard way recently that it is not because it is wrtitten that a responder support a specific PID that it is working as the standard says.

[peternewman]

Originally Posted by Thierry Dupont

Thank you Peter to spend some time looking at our issue.

No problem

Originally Posted by Thierry Dupont

Personality for a 16 bit Dimmer:


In our example above (which is implemented as it is) regarding the Secondary should we have?
Slot Label ID [0x0001, (1)], Intensity
or Slot Label ID [0x0000, (0)]

Currently we have Slot Label ID [0x0000, (0)]

Yes that's correct. It's a secondary slot, so the Slot Label ID should be a reference to the offset of the slot that's it's primary.


I should probably have explained before, with OLA installed that pretty printed output, which I'd hope makes it pretty self-explanatory if it's correct or not, is as easy as:

ola_rdm_get -u <UNIVERSE> --uid <UID> slot_info

Originally Posted by Thierry Dupont

We meant two secondary values as timing / one for duty cycle and one for frequency. The responder that we worked with cannot handle very well secondary.

Yeah, so the challenge seems to be that those channels have to be secondary so you can't say it's strobe. How do you actually turn the strobe on and off, a certain part of the intensity channel, or another one, or just have a frequency of 0 Hz and a duty cycle of 100%?



I'd probably have a primary of SD_STROBE and a secondary of ST_SEC_TIMING or ST_SEC_SPEED for the other channel.



I assume you meant the controller you worked with?

Originally Posted by Thierry Dupont

We learnt the hard way recently that it is not because it is wrtitten that a responder support a specific PID that it is working as the standard says.

Yes, listing a PID in SUPPORTED_PARAMETERS is one thing, actually making it usable and useful is quite another!

[peternewman]

I also mocked up your original followspot personality, with raw data:

{'slot_label_id': 1, 'slot_offset': 0, 'slot_type': 0},
{'slot_label_id': 1, 'slot_offset': 1, 'slot_type': 1},
{'slot_label_id': 2, 'slot_offset': 2, 'slot_type': 0},
{'slot_label_id': 2, 'slot_offset': 3, 'slot_type': 1},
{'slot_label_id': 1028, 'slot_offset': 4, 'slot_type': 2},
{'slot_label_id': 1028, 'slot_offset': 5, 'slot_type': 3},
{'slot_label_id': 1283, 'slot_offset': 6, 'slot_type': 2},
{'slot_label_id': 1282, 'slot_offset': 7, 'slot_type': 4}

Pretty printed:

Slot offset 0: Primary, intensity
Slot offset 1: Secondary, fine control for slot 1
Slot offset 2: Primary, intensity master
Slot offset 3: Secondary, fine control for slot 2
Slot offset 4: Secondary, timing control for slot 1028
Slot offset 5: Secondary, speed control for slot 1028
Slot offset 6: Secondary, timing control for slot 1283
Slot offset 7: Secondary, mode control for slot 1282

Hopefully it's fairly clear to see what's wrong there, but our RDM tests catch it too:

------------------- Warnings --------------------
Slot 1 is of type secondary and references slot 1 which isn't a primary slot
Slot 4 is of type secondary and references an unknown slot 1028
Slot 5 is of type secondary and references an unknown slot 1028
Slot 6 is of type secondary and references an unknown slot 1283
Slot 7 is of type secondary and references an unknown slot 1282

Full disclosure, I've only just added the warning about slot 1 and that will go into our primary branch for a future release once #1720 is merged, but the other test already existed.