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 October 19th, 2009   #1
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default STATUS_MESSAGES

Hello

Should I implement this pid?

I do not support queueed messages and all that but I do wnat to convey errorsa across lke overheating etc.
Would I have to support everything in table A-4 or can I just do error messages somehow?

What about STATUS_GET_LAST_MESSAGE ? Do I have to support it?

Kind regards
Bernt
berntd is offline   Reply With Quote
Old October 19th, 2009   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 420
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Bernt,

I would strongly suggest implementing Queued_Messages. It really is one of the most useful messages there is as most of the controllers do a good job at supporting it I've found.

You can choose to only report Error conditions and not Warning type conditions if you choose. The standard does require the STATUS_GET_LAST_MESSAGE though to handle a case where the packet doesn't get through successfully:

Quote:
The responder shall maintain reported status information until it has been successfully delivered to the controller. Status is considered successfully delivered when the responder receives a Status Type Requested other than STATUS_GET_LAST_MESSAGE.



__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old October 19th, 2009   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 360
Default

> Should I implement this pid?

It's a nice way to deliver messages from the responder without the controller having to know what to ask for.

> I do not support queueed messages

Status messages do no require you to support queued messages.

>Would I have to support everything in table A-4
> or can I just do error messages somehow?

You don't have to support all of the status types. If you only want to support errors, then you simply send the error message for Error, Warning, and Advisory.

> What about STATUS_GET_LAST_MESSAGE ?
> Do I have to support it?

Effectively yes, you have to support it. If you don't support GET_LAST_MESSAGE, there's no way for the controller to re-get a status message packet that gets lost or corrupted. If you don't have GET_LAST_MESSAGE, and your "Dimmer on Fire" status message gets dropped, the error will be lost forever.
ericthegeek is offline   Reply With Quote
Old October 19th, 2009   #4
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Quote:
Originally Posted by sblair View Post
Bernt,

I would strongly suggest implementing Queued_Messages. It really is one of the most useful messages there is as most of the controllers do a good job at supporting it I've found.
Hello
In relation to queued messages...

Is it implied that a controller will leave the device alone if it receives and ACK_TIMER?

In other words, is there a way to tell a controller not to send any more commands for a certain period because the poor device is really busy saving stuff to eprom etc?

Kind regards
Bernt
berntd is offline   Reply With Quote
Old October 19th, 2009   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 360
Default

> Is it implied that a controller will leave the device
> alone if it receives and ACK_TIMER?

No, it's not implied. Many controllers will not send anything else to a responder until the ACK_TIMER period is over, but technically the ACK_TIMER is only for that specific message. It's perfectly valid to send another request while waiting for the queued message to come back from a previous ACK_TIMER.

If you're too busy doing other things, you can either issue another ACK_TIMER for the new request, or drop the packet.
ericthegeek is offline   Reply With Quote
Old October 19th, 2009   #6
sblair
Administrator
 
Join Date: Feb 2006
Posts: 420
Send a message via AIM to sblair Send a message via MSN to sblair
Default

The ACK_TIMER is supposed to indicate to the controller to "bugger off and leave me alone". Now that only applies to the specific PID. So if you ACK_TIMER me on GET DMX_START_ADDRESS, that doesn't mean I can't still ask you for other PID's, which you may ACK_TIMER as well.

ACK_TIMER is really only a partial solution as it requires the controller to remember all the questions it has asked and come back and ask them again later and hope for a reply. QUEUED_MESSAGES does a great job at closing the loop at providing the information to the controller when it becomes available.

I have not done a lot of experimentation with controllers and ACK_TIMER to see if they really do wait the amount of time that is included in the ACK_TIMER response before asking (if they ask again at all). All my implementations have used QUEUED Messages so that it negates that.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old October 19th, 2009   #7
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Quote:
Originally Posted by ericthegeek View Post
> If you're too busy doing other things, you can either issue another ACK_TIMER for the new request, or drop the packet.
In fact, too busy to even listen to packets because interrupts have to be off at some stage.

An "ACK_BUSY" (with a timer) would be rather useful in that instance:-)

Is dropping packets an accepted way of doing this?

Regards
Bernt
berntd is offline   Reply With Quote
Old October 19th, 2009   #8
sblair
Administrator
 
Join Date: Feb 2006
Posts: 420
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
Is dropping packets an accepted way of doing this?
Not especially, but sometimes that is your only option. I think Peter has ended up in that same situation before too. I'm not sure if he was able to find a way around it though other than just dropping packets.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old October 19th, 2009   #9
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Hehe, dropping packets is a really easy way to do this becase it will simply happen as a byproduct of the unit being busy :-)
No coding required

B
berntd is offline   Reply With Quote
Old October 19th, 2009   #10
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 360
Default

> An "ACK_BUSY" (with a timer) would be rather
> useful in that instance

NACK w/ NR_BUFFER_FULL is not exactly what you're looking for, but is close enough to probably work.

RDM is not a reliable transport protocol, so any device is free to drop any packet at any time for any reason (or no reason). A well designed controller will re-try any critical requests. Still, it's generally a bad practice to design-in dropping packets. You'll see enough dropped packets in the field due to noise, bad cables, etc.; If you start deliberately dropping packets, it just makes things that much more difficult.
ericthegeek is offline   Reply With Quote
Old October 20th, 2009   #11
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

Yes I've been here before with various Microchip PIC parts. In some (most) situations you run the risk of not being able to service irq's fast enough whilst the part is writing to EEprom. My approach, whilst still using ACK_TIMER to fend off the controller, was to buffer all my write requests and schedule them to occur when there was no pending RDM comms.

For those coding in a high level languague -

I would also look carefully at what your compiler library does in the routines to write to the EE. The one I used was horrible, masking interrupts for far longer than necessary, which did not help with the servicing of comms. I ended up having to create my own.

The RDMLabpack only needs to issue ACK_TIMER for SET: commands that result in EE writes. The ACK_TIMER tells the controller that the original request has been received, has the correct syntax and has been understood. It will get actioned. If there were to be a subsequent Write problem, I would generally choose to que a STATUS_MESSAGE with an appropriate error code.

Berntd - if you contact me off-list I can send you more details of the Labpack.

Peter
prwatE120 is offline   Reply With Quote
Old October 20th, 2009   #12
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Hei,

Thanks Peter!

I am still having trouble understanding the STATUS_MESSAGE.
Assume I do have a dimmer_on_fire error.

Now I supply this info when status is requested by the cotrlloer.

If the controller asks next time for status and I still have the same problem, do I send dimmer_on_fire again or is this system ONCE only upon change of status?

Kind regards
Bernt

Last edited by berntd; October 20th, 2009 at 05:50 PM.
berntd is offline   Reply With Quote
Old October 20th, 2009   #13
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 360
Default

There's no standardized way to enunciate the end of an error condition.

There's been some discussion about this among the task group lately without reaching any real conclusion. It's a dicey issue that can't get any official resolution until the entire E1.20 document is opened for revisions.

One way is to report status messages only when they first occur. This seems to be what's envisioned in the text of the standard since the text says "The previously delivered status messages shall be cleared from the reporting queue once they have been successfully delivered to the Controller."

The problem with this is that if a status message is lost (for whatever reason), you have no way to get that message again unless it's re-reported sometime later. But, you also don't want to fill up someone's error logs with tons of inconsequential status messages.

My personal opinion is that status messages should be reported when they first occur, and then re-reported when it makes sense for that particular message. You'd want to re-report "dimmer on fire" every few seconds since it's darn important, and isn't likely to last very long. "Speck of Dust on the LCD display" isn't very important and could last for months. You might want to re-report it once a day, or once a week.

It's probably also desirable to re-report all status messages when you detect that DMX signal has been lost (indicating that a new console may have been connected).

This opinion is not based on anything in the text of the standard. It's my attempt to work out a way of dealing with lost messages that fits within the framework of the text. Others (some of who read this forum) strongly disagree with me on this.
ericthegeek is offline   Reply With Quote
Old October 20th, 2009   #14
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Hi

Still nede some more clarification on STATUS_MESSAGES:

I see the controleer asks for the status type.

I then note that the responce carries a Status_type in each message.

Does this mean if controller wants edvisory status, all the response messsages MUST have the type = Advisory and so forth?

Or: can the response reply with error messages or whatever when asked for advisory?

Regards
Bernt
berntd is offline   Reply With Quote
Old October 20th, 2009   #15
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 360
Default

> Does this mean if controller wants edvisory status,
> all the response messsages MUST have the
> type = Advisory

No. If the controller asks for STATUS_WARNING, then the responder should returns any status message of type STATUS_ERROR first, followed by STATUS_WARNING. Each status message is sent with the level matching its severity.

This allows the controller to know which messages are the most important. A controller might choose to show STATUS_ERROR in bright red text, STATUS_WARNING in a little notification window, and STATUS_ADVISORY in a hidden log file somewhere.
ericthegeek is offline   Reply With Quote
Old October 20th, 2009   #16
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Quote:
Originally Posted by ericthegeek View Post
...If the controller asks for STATUS_WARNING, then the responder should returns any status message of type STATUS_ERROR first, followed by STATUS_WARNING. Each status message is sent with the level matching its severity.
Hello Eric,
you have lost me.
The way it sounds is like no matter what it asks for, it gets error warnings advisories all at once. How is that supposed to work?

Surely if it asks for ERRORS, it needs to get errors and not warnings or advisories?
The spec makes absolutely no sense to me for this pid.

Kind regards
Bernt
berntd is offline   Reply With Quote
Old October 20th, 2009   #17
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 360
Default

> The way it sounds is like no matter what it asks for,
> it gets error warnings
...
> Surely if it asks for ERRORS, it needs to get errors
> and not warnings or advisories?

See table 10-1 for details. You can think of the Status Type as being the minimum level of messages to send. Effective, "Show me messages that are this important or higher".

If the controller asks for errors, it gets only errors in response.

If the controller asks for warnings, it gets both errors and warnings.

If the controller asks for advisory message, it gets errors, warnings, and advisory messages.

It's a concept similar to that used by many error logging mechanics in computer OS's. You tell it the minimum importance level of the messages you want to see, and it will show you everything that is that important, as well as messages that are more important.
ericthegeek is offline   Reply With Quote
Old October 20th, 2009   #18
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Quote:
Originally Posted by ericthegeek View Post
>
See table 10-1 for details. You can think of the Status Type as being the minimum level of messages to send. Effective, "Show me messages that are this important or higher".

If the controller asks for errors, it gets only errors in response.

If the controller asks for warnings, it gets both errors and warnings.

If the controller asks for advisory message, it gets errors, warnings, and advisory messages.

It's a concept similar to that used by many error logging mechanics in computer OS's. You tell it the minimum importance level of the messages you want to see, and it will show you everything that is that important, as well as messages that are more important.
I got it now.
Thanks Eric.
berntd 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


All times are GMT -6. The time now is 03:56 PM.


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