Slot_Info / Slot ID Type-Slot Category/ID implementation issue
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 |
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 |
edit: Added the youtube link: https://www.youtube.com/watch?v=-5BmsJ7CeFE
|
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? |
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): Code:
{'slot_label_id': 1, 'slot_offset': 0, 'slot_type': 0}, Code:
Slot offset 0: Primary, intensity The OLA RDM tests don't throw any errors as expected. Regarding: Quote:
Quote:
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: Code:
{'slot_label_id': 0x0101, 'slot_offset': 0, 'slot_type': 0}, Quote:
Quote:
|
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 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. |
Quote:
Quote:
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: Code:
ola_rdm_get -u <UNIVERSE> --uid <UID> slot_info Quote:
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? Quote:
|
I also mocked up your original followspot personality, with raw data:
Code:
{'slot_label_id': 1, 'slot_offset': 0, 'slot_type': 0}, Pretty printed: Code:
Slot offset 0: Primary, intensity Code:
------------------- Warnings -------------------- 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. |
All times are GMT -6. The time now is 03:31 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.