LOCK-STATE E1.37-1 Implementation
LOCK-STATE E1.37-1 Implementation
Hello,
We do use the PID LOCK_STATE + LOCK_STATE_DESCRIPTION combine with a password to hide MANUFACTER_PIDS used for specific settings.
Any plan to implement them?
Thanks
Thierry
We do use the PID LOCK_STATE + LOCK_STATE_DESCRIPTION combine with a password to hide MANUFACTER_PIDS used for specific settings.
Any plan to implement them?
Thanks
Thierry
Re: LOCK-STATE E1.37-1 Implementation
Hello Thierry D,
According to the RDM specifications you will be able to lock GET and SET parameters. But is impossible to enable or disable a part of the supported parameters list.
MADRIX RADAR is working according to the RDM standard E1.37-1 so you will be able to work with the GET and SET commands for LOCK_STATE with and without a password.
According to the RDM specifications you will be able to lock GET and SET parameters. But is impossible to enable or disable a part of the supported parameters list.
MADRIX RADAR is working according to the RDM standard E1.37-1 so you will be able to work with the GET and SET commands for LOCK_STATE with and without a password.
Re: LOCK-STATE E1.37-1 Implementation
Thank you very much.
I am new to Madrix Radar. I had the impression that it worked only with your equipment but it does not which is a very good news. In our new platform called Sully we have a product without a display and to set it up you can only use RDM or a Web browser hence my request on IPV4 settings on another post.
I managed to unlock the Lock_State and the hidden Manufacturer Pids are present now.
How do you display the Manufacturer-PID on Radar?
I am new to Madrix Radar. I had the impression that it worked only with your equipment but it does not which is a very good news. In our new platform called Sully we have a product without a display and to set it up you can only use RDM or a Web browser hence my request on IPV4 settings on another post.
I managed to unlock the Lock_State and the hidden Manufacturer Pids are present now.
How do you display the Manufacturer-PID on Radar?
Re: LOCK-STATE E1.37-1 Implementation
Manufacturer Specific Parameters you will find at the Parameter List at the Parameter view right side of RADAR.
Furthermore you are able to enable or disable Manufacturer Specific Parameters at the Main View. Simply perform a right click at the header of the Main View and enable or disable the desired parameters.
Furthermore you are able to enable or disable Manufacturer Specific Parameters at the Main View. Simply perform a right click at the header of the Main View and enable or disable the desired parameters.
- Attachments
-
- radar.jpg (517.61 KiB) Viewed 26211 times
Re: LOCK-STATE E1.37-1 Implementation
Hi Thierry,
I have a few annotations to your requests and posts.
You cannot "hide" the PID of a manufacturer-specific parameter with the lock state!
SUPPORTED_PARAMETERS must contain all PIDs the fixture is capable of, regardless of any state the fixture may have. Only if parameters are required, they shall not be reported in SUPPORTED_PARAMETERS.
E1.20 states in 10.4 RDM Information Messages:
"Devices with the same Manufacturer ID, Device Model ID, and Software Version ID response for the DEVICE_INFO parameter shall report an identical list for the SUPPORTED_PARAMETERS message."
Therefore you are not allowed to change the Get Response of SUPPORTED_PARAMETERS based on the state of your fixture. For your case this means, you can not "hide" a manufacturer-specific parameter, when the fixture is locked.
Also be aware of the following:
Once your manufacturer-specific parameter was reported to MADRIX RADAR, it can not be "unseen". If you unlock your fixture to view your manufacturer-specific parameter in MADRIX RADAR and afterwards lock your fixture again, you will receive a warning from MADRIX RADAR. It will assume the fixture is not implemented correctly due to the missing get responses of your manufacturer-specific parameter.
Restraining user access to the fixture with RDM
But there are ways to restrain the access of the user to information in the RDM protocol family.
E1.37-1 states in 3.7 Get/Set Lock State (LOCK_STATE):
"When the SET_COMMAND functionality of any PID is locked for a device, with LOCK_STATE or otherwise, it shall respond to SET_COMMAND messages with a NACK with a NACK Reason Code of NR_WRITE_PROTECT."
Therefore you can deny the overwriting of your value.
Unfortunately, neither E1.20 nor any of the E1.37 states a NACK Reason Code for an unsupported Get Command as far as I know. I would recommend to discuss this request in the official RDM forum. As of now, there is imho no offical way to reject any response to a Get Command for a supported parameter based on the state of a fixture.
Using MADRIX RADAR to validate your implementation
As for the testing your implementation of your fixture you can use a bit of a tweak in MADRIX RADAR:
In Preferences => Event Configuration => Categories you can specify the Display event for validation purposes. When you have done this, MADRIX RADAR will report any errors it finds in the RDM traffic. You can view them in the View => Events window. This allows you to quick check the implementation of your fixture. But be aware that this is not an exhaustive list of errors one might expect in RDM traffic, only a few. Also those errors are only related to E1.20 and E1.37-1 exclusively.
Status Messages are not displayed
At last I need to say something about your post in the bug section of this forum:
STATUS_MESSAGE, as you pointed out in the RDM forum, is indeed implemented.
But there are at least 2 different types of status messages. If you send a STATUS_MESSAGE with the PDL of 0x00, the information is received, but not displayed by MADRIX RADAR, as there is no information to be shown other than it was received. Please also be aware of the MESSAGE COUNT field you have to set in the header of set/get responses.
If however the STATUS_MESSAGE you are sending is not empty and does contain data, this would be a fault. It would then be helpful to supply a wireshark record to us. This would enable us to look into this error based on your record.
I hope I got all your requests answered for now :)
Best regards,
FishAI
I have a few annotations to your requests and posts.
You cannot "hide" the PID of a manufacturer-specific parameter with the lock state!
SUPPORTED_PARAMETERS must contain all PIDs the fixture is capable of, regardless of any state the fixture may have. Only if parameters are required, they shall not be reported in SUPPORTED_PARAMETERS.
E1.20 states in 10.4 RDM Information Messages:
"Devices with the same Manufacturer ID, Device Model ID, and Software Version ID response for the DEVICE_INFO parameter shall report an identical list for the SUPPORTED_PARAMETERS message."
Therefore you are not allowed to change the Get Response of SUPPORTED_PARAMETERS based on the state of your fixture. For your case this means, you can not "hide" a manufacturer-specific parameter, when the fixture is locked.
Also be aware of the following:
Once your manufacturer-specific parameter was reported to MADRIX RADAR, it can not be "unseen". If you unlock your fixture to view your manufacturer-specific parameter in MADRIX RADAR and afterwards lock your fixture again, you will receive a warning from MADRIX RADAR. It will assume the fixture is not implemented correctly due to the missing get responses of your manufacturer-specific parameter.
Restraining user access to the fixture with RDM
But there are ways to restrain the access of the user to information in the RDM protocol family.
E1.37-1 states in 3.7 Get/Set Lock State (LOCK_STATE):
"When the SET_COMMAND functionality of any PID is locked for a device, with LOCK_STATE or otherwise, it shall respond to SET_COMMAND messages with a NACK with a NACK Reason Code of NR_WRITE_PROTECT."
Therefore you can deny the overwriting of your value.
Unfortunately, neither E1.20 nor any of the E1.37 states a NACK Reason Code for an unsupported Get Command as far as I know. I would recommend to discuss this request in the official RDM forum. As of now, there is imho no offical way to reject any response to a Get Command for a supported parameter based on the state of a fixture.
Using MADRIX RADAR to validate your implementation
As for the testing your implementation of your fixture you can use a bit of a tweak in MADRIX RADAR:
In Preferences => Event Configuration => Categories you can specify the Display event for validation purposes. When you have done this, MADRIX RADAR will report any errors it finds in the RDM traffic. You can view them in the View => Events window. This allows you to quick check the implementation of your fixture. But be aware that this is not an exhaustive list of errors one might expect in RDM traffic, only a few. Also those errors are only related to E1.20 and E1.37-1 exclusively.
Status Messages are not displayed
At last I need to say something about your post in the bug section of this forum:
STATUS_MESSAGE, as you pointed out in the RDM forum, is indeed implemented.
But there are at least 2 different types of status messages. If you send a STATUS_MESSAGE with the PDL of 0x00, the information is received, but not displayed by MADRIX RADAR, as there is no information to be shown other than it was received. Please also be aware of the MESSAGE COUNT field you have to set in the header of set/get responses.
If however the STATUS_MESSAGE you are sending is not empty and does contain data, this would be a fault. It would then be helpful to supply a wireshark record to us. This would enable us to look into this error based on your record.
I hope I got all your requests answered for now :)
Best regards,
FishAI