STATUS_MESSAGES

[berntd]

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

[sblair]

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:

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.

[ericthegeek]

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

[berntd]

Originally Posted by sblair

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

[ericthegeek]

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

[sblair]

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.

[berntd]

Originally Posted by ericthegeek

> 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

[sblair]

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.

[berntd]

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

[ericthegeek]

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

[prwatE120]

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

[berntd]

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

[ericthegeek]

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.

[berntd]

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

[ericthegeek]

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

[berntd]

Originally Posted by ericthegeek

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

[ericthegeek]

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

[berntd]

Originally Posted by ericthegeek

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