|
RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product. |
|
Thread Tools | Search this Thread | Display Modes |
|
March 1st, 2010 | #1 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Refreshing of paramters need Queued Messages?
Hello,
I am just having this converstion with someone and I am now wondering. I thought a controller should either manually (button) or periodically refresh paramters FROM a device. However, another approach seems so be that the controller does not do this but rather relies on the device to generate a queued message if a parameter changes. Regards Bernt |
March 1st, 2010 | #2 |
Administrator
|
The controller can do whatever it chooses ultimately.
If a controller sees that a device does not support Queued messages, then clearly it will have to specifically request parameters that it wants to monitor for updates. Obviously devices that support Queued messages make life a lot easier because the controller can assume that the device will alert it to any parameter change that the device thinks is important for the controller to know about. A well implemented controller will make use of both Queued Messages and periodic refreshing of key parameters to keep itself up to date. Constantly flooding the link asking for updates for each and every parameter probably isn't that useful in most cases though and won't scale well.
__________________
Scott M. Blair RDM Protocol Forums Admin |
March 1st, 2010 | #3 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Hi Scott
How can that be? The specification does not mandate queued messages nor does it mandate the specific contents of supported queued mesages. To assume that even if queued messages are supported, they will report ALL changes of everyting does not sound right. Smaller devices don't have enough RAM to support multiple queued messages. Regards Bernt |
March 1st, 2010 | #4 |
Administrator
|
Queued messages are not mandated. Most of us wish they were but a few folks were deadset against it.
Ultimately devices that chose not to support Queued Messages may not be as well supported on many controllers as devices that do. As I said a good controller makes use of both Queued Message polling and querying specific parameters that it needs to know about. Also, as I said the device makes the determination what it thinks is important to report back to the controller via Queued Messages (if it supports them). A good controller will make sure to poll a specific parameter to ensure it has the right value at the point it is needed most, for example when a user is editing that setting. Before allowing the user to edit, the controller can do a GET on that specific parameter to make sure it is reporting the current value.
__________________
Scott M. Blair RDM Protocol Forums Admin |
March 2nd, 2010 | #5 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
At first, it seems a bit wasteful to have to constantly poll for updates. But most controller implementations will send a packet to every device on the link periodically to make sure that device is still present. It's not significantly more overhead to send a packet to get the parameters you care about periodically than to just send GET QUEUED_MESSAGES.
As Scott said, then the user opens a window to edit a parameter, it's probably a good idea to get the latest values for everything anyway. |
March 2nd, 2010 | #6 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Hello,
Here is an example: A root device parameter is changed on the front panel of the device or with RDM. This results in several parameters in each of up to 24 subdevices to change. This would result in an enormous number of queued mesages, needing an enormous amount of memory and enormous processing power to compute and generate. I think a good controller should have a button that allows a user to refresh parameters (at least the manufacturer specific ones) when necessary or before / after updating them. Or while the paramter edit window is open, the controller could poll the paramters. Kind regards Bernt Last edited by berntd; March 2nd, 2010 at 02:55 PM. |
March 2nd, 2010 | #7 |
Task Group Member
Join Date: May 2009
Location: Gothenburg
Posts: 40
|
How come that everybody assumes that queued messages needs to actually be queued, in some of my devices that support queued messages I only queue the message type. Hence it need only a few bits to store each queued message.
A good responder should send back changes through queued messages, and a good controller should make sure it have necessary data available, regardless of how they do it.
__________________
Michael Karlsson LumenRadio AB |
March 2nd, 2010 | #8 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
"Enormous" is relative. I've seen RDM devices with everything from 192 bytes of RAM to 128 MiBytes.
Hundreds of messages in the queue might be impractical for many of the older 8-bit microcontrollers with a few hundred bytes of memory. But with 16 KiBytes or more available in many microcontrollers that sell for under $5/US, it's quite possible even in a relatively low end device. |
March 2nd, 2010 | #9 | |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Quote:
True but we are not designing new hardware here we are issuing new software for existing products. Even the fairly new microchip PICs with 16 bit core have 2048 bytes of RAM. Some have 4k RAM. Regards Bernt |
|
March 2nd, 2010 | #10 |
Administrator
|
I just Queue the PID itself. Then when the controller asks I just send whatever the current value is for that PID.
In a limited device, you could use a single BIT to denote the PID. Thus with a single BYTE you could support queueing for up to 8 messages!
__________________
Scott M. Blair RDM Protocol Forums Admin |
March 2nd, 2010 | #11 | |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Quote:
Example: The operating mode of the device is changed. This can change: 1: The preheat value 2: The DMX personality, 3: The output limit Of each subdevice / channel. That results in a total of up to 24*3 + 1 = 73 queued messages and lots of them with with the same PID. So to make that work, I suppose it will need some sort of processing engine that will just manage the message queue and it will need to sort out sub-devices as well as pids and strictly speaking also the values. It also needs to keep track of how many messages remain as well as the LAST_MESSAGE. :D If the operating mode is changed a few times in successtion, buffer full and lost messages / no way for controller to see the changes will result right? It makes the Enttech Controllers "Refresh" And "Get" / "Set" buttons look very atractive. Regards Bernt |
|
March 2nd, 2010 | #12 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
> issuing new software for existing products.
Having spent hundreds of hours in 8051 assembly lately, I understand... Using a real queue you could do it in 3 bytes per message (1 byte for the sub-device and 2 bytes for the PID). If you use bit packing and have 32 sub-devices that support 50 PIDs each, you can store the entire queue state in 200 bytes. Map each possible queued message to a bit and set the associated bit whenever that PID's data changes and needs to be reported to the controller. |
March 2nd, 2010 | #13 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
[QUOTE=ericthegeek;1962
Having spent hundreds of hours in 8051 assembly lately... [/QUOTE] :D ! Bernt |
March 2nd, 2010 | #14 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
As Michael said earlier, you don't need an actual queue.
Lets say you have 5 sub-devices, each with 2 PIDs that you need to track QUEUED_MESSAGES for (DMX address and Personality). That's a total of 10 possible queued messages. So, you allocate 10 bits. If all 5 personalities change, you just set the 5 bits (one for each sub-device). Then, when the responder receives a "GET QUEUED_MESSAGES" it scans through the 10 bits until it finds one that's set, sends the matching response, and clears the bit. If the same parameters changes two times before it's reported to the console, it doesn't matter. The console only needs the most recent data. A big advantage of this method is that your queue can never overflow (since there's no queue). It's easy to implement on microcontrollers with a few bit-test instructions and you can statically allocate all of the bits you need up front. |
March 2nd, 2010 | #15 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Hi Eric
I have understood that and I am looking into it However, the GET_LAST_MESSAGE will need special attention or do you then just store the bit number / mask of the last message somewhere and if required send it again but with the current value instead of the actual last value(s)? Kin dRegards Bernt |
March 2nd, 2010 | #16 |
Administrator
|
Bernt,
I would send it with the current value. Previous values are much less important.
__________________
Scott M. Blair RDM Protocol Forums Admin |
March 3rd, 2010 | #17 |
Task Group Member
Join Date: May 2009
Location: Gothenburg
Posts: 40
|
I agree with Scott, I would sent it with the current value since the old value is not of very much interest any longer if it has changed since last GET.
__________________
Michael Karlsson LumenRadio AB |
May 17th, 2010 | #18 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Hello I am finally getting round to implement some Queued Messages.
Of course I am now rusty on this so first problem I now have is what about subdevices? What if someone changes the DMX personality on a subdevice? How do I relay this in a queueed message since they seem to be addressed to Root devices only? Or better still, the example on p47 where the responder sends a message for DMX_START_ADDRESS: What if this were a start address change on a subdevice? Kind regards Bernt |
May 18th, 2010 | #19 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
The "GET QUEUED_MESSAGES" request is sent to the root device, but the response can come from any sub-device.
For example, if the user changes the DMX Address of two sub-devices, then the responder would set it's message count to 2. When the controller sends a GET QUEUED_MESSAGES to the root, it would send the new DMX address for the first sub-device. The next GET QUEUED_MESSAGES would return the new DMX address for the second sub-dev. |
May 18th, 2010 | #20 | |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Quote:
Ok, understood. Simple. But where in the response does the responder set which subdevice is actualluy responding? Is it just byte 3/4 ? In other words does the controller Send GET_QUEUED_MESSAGE with Subdevice = 0x0000 and the responder then responds to that with DMX_START_ADDRESS and subdevice - 0x000x ?? Kind regards Bernt |
|
May 18th, 2010 | #21 | |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
Quote:
Looking at table 6-6 in the standard, the sub-device goes in slots 18 and 19. It's after the Message Count and before the Command Class. For the GET QM request, slots 18:19 would be 0x0000. If subdevice 9 had a new DMX address, slots 18:19 in the response would be 0x0009. For most RDM packets, the response's Sub-Device Field will match the request's sub-device, but this is one case where they won't match. |
|
May 19th, 2010 | #22 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Hello,
So far so good. One more thing: What happens with the STATUS_GET_LAST_MESSAGE response if there is no last message to resend (sort of after power up etc)? Regards Bernt |
May 18th, 2010 | #23 |
Administrator
|
Yes, it just populates the Sub-Device field of the response message with the Sub-Device number that the Queued Message is for.
__________________
Scott M. Blair RDM Protocol Forums Admin |
May 19th, 2010 | #24 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
> What happens with the STATUS_GET_LAST_MESSAGE
> response if there is no last message to resend Good question. I'd probably respond with a STATUS_MESSAGES response (similar to E1.20 section 10.3.1 paragraph 3). That effectively means "I have no queued messages for you". It's probably best to have no parameter data and set the PDL to zero. This way a status message won't get lost if the controller isn't expecting a STATUS_MESSAGES PID in response to a GET_LAST packet. |
May 19th, 2010 | #25 |
Administrator
|
Yep, a STATUS_MESSAGES response with a PDL of 0 is what you would use, since you have no status messages to respond with...
__________________
Scott M. Blair RDM Protocol Forums Admin |
May 23rd, 2010 | #26 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Hello,
Are the responces always of CC = GET_COMMAND_RESPOSE ? Example, DEVICE_RESET. My device has reset and I am generating a queued message. Is that message GET_COMMAND_RESPOSE ? I ask because DEVICE_RESET does not actually support GET_COMMAND. Regards Bernt |
May 24th, 2010 | #27 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
I'm not sure what the best solution is.
GET QUEUED_MESSAGES can return a SET as a followup to an earlier ACK_TIMER, but there's no mention of a responder-generated SET queued message in the standard. Looking through the list of PIDs, this would effect RESET_DEVICE and CAPTURE_PRESET. For RESET, seeing a queued SET message would tell the controller that there was a reset. But it's less useful for CAPTURE_PRESET. The SET CAPTURE_PRESET response does not contain the preset number. The controller would know that a preset was recorded on the responder, but it has no way to know which preset it was. |
May 24th, 2010 | #28 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Hello
I have for the moment made it a GET_COMMAND_RESPONSE with the logic that QUEUED_MESSAGES is a GET_COMMAND. If we want to have a SET_COMMAND_RESRESPONSE, then most queued messages would have to be that (ok, not all but many) because they indicate that something on the device has changed. Likewise, the example in the spec about the DMX_START_ADDRESS is shown as a GET_COMMAND_RESPONSE but because the address was changed (set from somewhere else), it could allso be a SET_COMMAND_RESPONSE right? Maybe there is further clarification available form some of our other members? |
May 24th, 2010 | #29 |
Task Group Member
Join Date: May 2009
Location: Gothenburg
Posts: 40
|
I think the best way to look at it is "What will make the most sense for the controller?"
In the case with DMX_START_ADDRESS it wont make any difference for the controller, hence you could go with either SET_RESPONSE or GET_RESPONSE. The GET:QUEUED_MESSAGE itself could return responses of either GET_RESPONSE or SET_RESPONSE type even if the request itself is GET:QUEUED_MESSAGE. As Eric pointed out a responder could ACK_TIMER a SET command, and would then queue up a SET_RESPONSE. So use the response type that makes the most sense for the controller regard what information it could get from the queued message, it the cases where SET_RESPONSE and GET_RESPONSE returning the same information, use the one you like, the controller should handle it properly either way.
__________________
Michael Karlsson LumenRadio AB |
May 25th, 2010 | #30 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
> In the case with DMX_START_ADDRESS it wont
> make any difference for the controller, hence you > could go with either SET_RESPONSE or > GET_RESPONSE. I'd argue that it does make a difference. If you queue up a SET_RESPONSE DMX_START_ADDRESS when the DMX address is changed, then the controller only knows that the DMX address was set. It then has to issue a GET DMX_START_ADDRESS or GET_DEVICE_INFO to find out what the new address is. If you queue a GET_RESPONSE DMX_START_ADDRESS, the queued message contains the new address and the controller does not need to do any followup work to find out what the new address is. |
May 25th, 2010 | #31 |
Task Group Member
Join Date: May 2009
Location: Gothenburg
Posts: 40
|
You are correct, I remembered incorrectly. I had some weird thought that the SET_RESPONSE included the value as well. I have to blame the early morning at the time of my post.
__________________
Michael Karlsson LumenRadio AB |
May 25th, 2010 | #32 |
Administrator
|
Eric is correct. Most of the SET message responses do not echo back the value that the field was set to. That only comes back in a GET message response.
While not explicitily stated, Queued Messages were really intended to be GET_COMMAND_RESPONSEs.
__________________
Scott M. Blair RDM Protocol Forums Admin |
May 25th, 2010 | #33 | |
Task Group Member
Join Date: May 2009
Location: Gothenburg
Posts: 40
|
Quote:
Queued messages in response to to for instance a SET:DMX_START_ADDRESS would only make sense if it is a SET_RESPONSE, since it is a response to the ACK_TIMER'd SET command. For instance: 1. A controller sends a SET:DMX_START_ADDRESS 2. A proxy responds with a ACK_TIMER 3. The proxy forwards the SET:DMX_START_ADDRESS to the device 4. The device replies with a SET_RESPONSE: NACK with NR_WRITE_PROTECT 3. The controller issues a GET:QUEUED_MESSAGE 4. The proxy will then of course reply with a SET_RESPONSE with the NACK reason. So SET_RESPONSES would be legitimate responses to a GET:QUEUED_MESSAGE otherwise the proxies would be unable to to their job. But as I read your post I read it as being addressed to queued messages generated by events in the responder.
__________________
Michael Karlsson LumenRadio AB |
|
May 25th, 2010 | #34 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
|
Bookmarks |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
ACK_TIMER, QUEUED Messages | berntd | RDM Interpretation Questions | 1 | November 12th, 2008 10:02 PM |
get queued messages as a ping? | sondericker | RDM Interpretation Questions | 2 | January 20th, 2007 09:11 PM |