E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old March 1st, 2010   #1
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default 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
berntd is offline   Reply With Quote
Old March 1st, 2010   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Old March 1st, 2010   #3
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

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
berntd is offline   Reply With Quote
Old March 1st, 2010   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Old March 2nd, 2010   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

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.
ericthegeek is offline   Reply With Quote
Old March 2nd, 2010   #6
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

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.
berntd is offline   Reply With Quote
Old March 2nd, 2010   #7
mike_k
Task Group Member
 
Join Date: May 2009
Location: Gothenburg
Posts: 40
Default

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
mike_k is offline   Reply With Quote
Old March 2nd, 2010   #8
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

"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.
ericthegeek is offline   Reply With Quote
Old March 2nd, 2010   #9
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Old March 2nd, 2010   #10
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Quote:
Originally Posted by ericthegeek View Post
"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.


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
berntd is offline   Reply With Quote
Old March 2nd, 2010   #11
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

> 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.
ericthegeek is offline   Reply With Quote
Old March 2nd, 2010   #12
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Quote:
Originally Posted by sblair View Post
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!
Also true but how would that work for the same PID across 12/24 subdevices?

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
berntd is offline   Reply With Quote
Old March 2nd, 2010   #13
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

[QUOTE=ericthegeek;1962
Having spent hundreds of hours in 8051 assembly lately...
[/QUOTE]

:D !

Bernt
berntd is offline   Reply With Quote
Old March 2nd, 2010   #14
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

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.
ericthegeek is offline   Reply With Quote
Old March 2nd, 2010   #15
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

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
berntd is offline   Reply With Quote
Old March 2nd, 2010   #16
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Bernt,

I would send it with the current value. Previous values are much less important.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old March 3rd, 2010   #17
mike_k
Task Group Member
 
Join Date: May 2009
Location: Gothenburg
Posts: 40
Default

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
mike_k is offline   Reply With Quote
Old May 17th, 2010   #18
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

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
berntd is offline   Reply With Quote
Old May 18th, 2010   #19
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

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.
ericthegeek is offline   Reply With Quote
Old May 18th, 2010   #20
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Quote:
Originally Posted by ericthegeek View Post
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.
Hello,

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
berntd is offline   Reply With Quote
Old May 18th, 2010   #21
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Old May 18th, 2010   #22
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

Quote:
Originally Posted by berntd View Post
But where in the response does the responder set which subdevice is actualluy responding? Is it just byte 3/4 ?
Byte 3/4 counting from where?

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.
ericthegeek is offline   Reply With Quote
Old May 19th, 2010   #23
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

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
berntd is offline   Reply With Quote
Old May 19th, 2010   #24
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

> 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.
ericthegeek is offline   Reply With Quote
Old May 19th, 2010   #25
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Old May 23rd, 2010   #26
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

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
berntd is offline   Reply With Quote
Old May 24th, 2010   #27
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

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.
ericthegeek is offline   Reply With Quote
Old May 24th, 2010   #28
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

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?
berntd is offline   Reply With Quote
Old May 24th, 2010   #29
mike_k
Task Group Member
 
Join Date: May 2009
Location: Gothenburg
Posts: 40
Default

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
mike_k is offline   Reply With Quote
Old May 25th, 2010   #30
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

> 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.
ericthegeek is offline   Reply With Quote
Old May 25th, 2010   #31
mike_k
Task Group Member
 
Join Date: May 2009
Location: Gothenburg
Posts: 40
Default

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
mike_k is offline   Reply With Quote
Old May 25th, 2010   #32
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Old May 25th, 2010   #33
mike_k
Task Group Member
 
Join Date: May 2009
Location: Gothenburg
Posts: 40
Default

Quote:
Originally Posted by sblair View Post
While not explicitily stated, Queued Messages were really intended to be GET_COMMAND_RESPONSEs.
When saying that I assume that you mean queued messages generated by an event at the responser (changing of DMX address, etc)?
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
mike_k is offline   Reply With Quote
Old May 25th, 2010   #34
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

Quote:
Originally Posted by mike_k View Post
When saying that I assume that you mean queued messages generated by an event at the responser
This is my understanding as well.
ericthegeek is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

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


All times are GMT -6. The time now is 01:39 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.