E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   Refreshing of paramters need Queued Messages? (http://www.rdmprotocol.org/forums/showthread.php?t=1060)

berntd March 1st, 2010 04:47 PM

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.

:confused:


Regards
Bernt

sblair March 1st, 2010 04:55 PM

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.

berntd March 1st, 2010 05:10 PM

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

sblair March 1st, 2010 10:31 PM

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.

ericthegeek March 2nd, 2010 01:59 PM

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.

berntd March 2nd, 2010 02:49 PM

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

mike_k March 2nd, 2010 03:54 PM

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.

ericthegeek March 2nd, 2010 03:56 PM

"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.

sblair March 2nd, 2010 03:57 PM

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! :)

berntd March 2nd, 2010 04:02 PM

Quote:

Originally Posted by ericthegeek (Post 1959)
"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

ericthegeek March 2nd, 2010 04:08 PM

> 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.

berntd March 2nd, 2010 04:36 PM

Quote:

Originally Posted by sblair (Post 1960)
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. :cool:

Regards
Bernt

berntd March 2nd, 2010 04:40 PM

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

:D !

Bernt

ericthegeek March 2nd, 2010 08:20 PM

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.

berntd March 2nd, 2010 08:43 PM

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

sblair March 2nd, 2010 08:45 PM

Bernt,

I would send it with the current value. Previous values are much less important.

mike_k March 3rd, 2010 01:03 AM

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.

berntd May 17th, 2010 07:37 PM

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

ericthegeek May 18th, 2010 10:03 AM

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.

berntd May 18th, 2010 04:38 PM

Quote:

Originally Posted by ericthegeek (Post 2010)
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

sblair May 18th, 2010 04:49 PM

Yes, it just populates the Sub-Device field of the response message with the Sub-Device number that the Queued Message is for.

ericthegeek May 18th, 2010 09:55 PM

Quote:

Originally Posted by berntd (Post 2011)
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.

berntd May 19th, 2010 05:20 PM

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

ericthegeek May 19th, 2010 07:27 PM

> 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.

sblair May 19th, 2010 09:15 PM

Yep, a STATUS_MESSAGES response with a PDL of 0 is what you would use, since you have no status messages to respond with...

berntd May 23rd, 2010 05:25 PM

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.:confused:


Regards
Bernt

ericthegeek May 24th, 2010 11:22 AM

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.

berntd May 24th, 2010 05:01 PM

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?

mike_k May 24th, 2010 11:55 PM

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.

ericthegeek May 25th, 2010 12:06 PM

> 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.

mike_k May 25th, 2010 12:09 PM

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.

sblair May 25th, 2010 12:11 PM

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.

mike_k May 25th, 2010 12:45 PM

Quote:

Originally Posted by sblair (Post 2023)
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.

ericthegeek May 25th, 2010 02:09 PM

Quote:

Originally Posted by mike_k (Post 2024)
When saying that I assume that you mean queued messages generated by an event at the responser

This is my understanding as well.


All times are GMT -6. The time now is 06:10 AM.

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