232 Queue Preference

DanRessler

Folks,

Thanks to some good advice here and a whole lot of searching, I've had good luck creating queues to manage my 232 communications. One question for the group, however: When a manufacturer provices a "guaranteed response time" for a device (e.g. 150Ms), have you queue programmers out there been using it or a multiple of it as an error check with some kind of timeline (or other algorithm)? I'm thinking about the best way to give an outer bound for the amount of time that I will wait for a response, and whether/when it makes sense to just assume that a communication might have been lost and resend.

Thanks in advance ... trying to improve the design of our basic architecture.

Dan

mpullin

example

For the new Fujitsus I place all my commands to it into a queue. Every couple seconds I monitor its RS232 buffer. If I see a @S I know the most recent command was a success and I send the next one. If I see a @E I try to send the offending command again.

Since they added the non-optional tuner with the "Loading..." screen, it makes writing macros for these TVs much more difficult since after turning it on there's a 5-10 second period before it will accept more RS232 commands. One of our clients even has a Fujitsu with a 20+ second warmup. But so far we have foiled all of their attempts to screw Home Automation. ;-)

Spire_Jeff

Slightly off topic, but I hear that Fujitsu has seen the error of their ways and has announced (or will be) that they are going to offer plasmas without tuners again

As for the queueing, if the manufacturer provides a response time, I will use that response time plus a few milliseconds (just to allow for some odd processing delays). Be sure to watch the communications through the diagnostics utilities to look for odd strings that aren't documented or that vary slightly from documentation. I always prefer to control the device from my laptop first the to verify the protocol document because it seems that the people writing the protocol specs aren't the people implementing them

Jeff

DHawthorne

My experience is that if I have an error response it is 95% of the time because my code sent the command wrong, in which case, it's pointless to send it again. The other 5% of the time seems to be I have sent a command at an inappropriate time - as in asking for a tuner channel when a receiver is on the DVD source. But again it's a problem in my code, not a communications error. It is extremely rare that I feel it is appropriate to keep trying a command on receiving an error response. I find it more helpful to trap the errors and log them than repeat them.

The result is I rarely worry about response timing. Typically, I will wait a tenth of a second between sending out packets, but cancel that wait if I get any response. I only worry about response time if the protocol says I absolutely have to wait between commands, error or not, in which case I'll set my base pause time to that, but still wait a bit longer if I don't get a response.

setholle

RS232 buffering

Interesting points, I find that writing a queue is a good thing for most devices. For instance for JVC DVRs, which I have many. I write a queue function that waits for @A, as soon as I get that I send another command. At times because of requesting certain dates to play etc, there could be 20 commands. IT took work, to get it right, but I also wrote in the string event what to do for every possible error I could encounter. This is makes the device bulletproof. This is necessary since at times hundreds of people are watching what the dvr is outputing.
However in dealing with an NEC projector, it was impossible to implement a queue function. At times the projector would just stop talking for like a minute, so I had to learn its weird ways and then put in waits and all sorts of stuff to understand what it wanted.
I would be curios as to a function that someone has built for general queue for devices.
Now in the case of like leitch routers, you can flood it with commands and it will just buffer them all and implement them. Very very good serial communication.
So does everyone find it better to just write code to deal with errors, then send strings or cover both ends?
Seth C. Olle

DanRessler

OK, I've been fooling around with this for a bit, and I have a design that is medium-simple (sort of) that has been working. It's basically comprised of four pieces.

Send232Command
- An integer function that accepts a command string and returns 0 or 1 for success or failure (could be more sophisticated; there are lots of integers )
- Basic Flow
IF waiting for a 232 response
Push232Message ... see next
Else
send the command string to the 232 device (using SEND_STRING)
set waiting for a response to true
create a timeline (one execution only) to event at the agreed response time plus a bit

Push232Message
- An integer function that accepts a command string and pushes it into a stack of commands (array of strings), returning 0 for success or 1 for queue full
- Note: I was going to make the command array have circular capability, but got lazy and lame; I just pop all the commands down one each time I pull from the queue
- Basic Flow
IF the last message pointer for the command array < allowed array queue length
increment last message pointer by 1
set message queue [last message pointer] to command string
ELSE
set error return to 1 (queue full)
ENDIF
return error return

TIMELINE_EVENT [232 timeline]
- This is the event that really checks for the response with some relevance to the manufacturer's agreed response time ... although I've been adding 50% on top for safety
- Basic Flow
nBufferLength = length of buffer for the 232 device
IF (nBufferLength > 0)
set waiting for a response to false
get the entire buffer (I use the nBufferLength) into response variable
* * *
* * * Process the response variable
* * *
ELSE
process for error feedback

DEFINE_PROGRAM Logic
- This is the logic that processes the array of commands if they build up, such as when a series of queries is popped onto the stack in one transaction (Are you on? What's your volume? OK, let's change that.)
- Basic Flow
IF (last message pointer > 0 and not waiting for a response)
send the first command string in the array ([1]) to the 232 device using SEND_STRING
set waiting for a response to true
create a timeline (one execution only) to event at the agreed response time plus a bit (same create as above)
IF last message pointer > 1
FOR loop from 1 while loop < last message pointer by 1
set messagequeue[loop] = messagequeue[loop+1]
END IF
decrement last message pointer by 1

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

So that's where I am right now. In the event for a button or from within a "transaction", I just call the function Send232Command. So far it seems to be working well.

Any thoughts or suggestions?

Dan

DanRessler

PS I've been keeping the array and some associated variables in a single user defined structure to try to make it easier to keep track of them.

Dan