Refreshing of paramters need Queued Messages?

[sblair]

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]

Originally Posted by sblair

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]

Originally Posted by mike_k

When saying that I assume that you mean queued messages generated by an event at the responser

This is my understanding as well.