Best Practice Question
hodeyp
Posts: 104
Hi, I am communicating with a lumagen scaler that I need to confirm is on and ready to receive commands before sending rs232 commands.
What is the recommended way to code...
Send a command...
Check if unit is on
If not on, switch on
Wait for confirmation unit is ready to receive commands
Send Command
tia
Phil
What is the recommended way to code...
Send a command...
Check if unit is on
If not on, switch on
Wait for confirmation unit is ready to receive commands
Send Command
tia
Phil
0
Comments
Otherwise i would build a timeline that checks communication with the scaler. Scaler doesn't respond? Then it's off (or broken ) Send power on command.
Keep checking the status and adjust if necesarry. This way, when you want to execute a command it's done instantly
any other suggestions would be appreciated
With a single room system, I just use discrete power commands. When the device is selected, turn it on. When the entire system is shut down, turn it off. If it's a multi-room system, I'll still turn it on when selected, but only turn it off after checking that none of the rooms are using it.
Having discrete power commands takes all the guesswork out of it, and eliminates the need to test. Most devices with serial control have that in the protocol. But if you really have to test and send a power toggle command, you still only need to do it when the device is selected and on shutdown; it's unnecessary to test on every command.
If this channel is off, I need to send a power-up command, wait until the unit confirms it is available and then send the command.
What is the most appropriate way of implementing this?
thx
Phil
The following code is how to do this. Note it doesn't implement a queue or flow control or powerup delays or any of the other good things you need for serial comms.
if the device receives a command before it is ready to receive it it ignores the command. THis is the crux of the problem - any advice on best practise for queuing code?
tia
PH
A queue doesn't solve that problem. Take a look at my earlier posting for a solution.
Nevertheless you do need a queue and here is my string queue code. Its layout is odd because I use two character tabs. I have modified it slightly for this posting so there is a possibility it's broken:
There are a couple of things that will vary the solution. If the device acknowledges commands with a response, then you are able to control delivery of the queued commands based on responses from the device. You could create a queue based on one of the previous examples. You queue the command then send it without advancing the current command pointer. At this point, you also start a wait (or handle it in a timeline) to resend the command after a designated time period if no response is received. You should also consider tracking the number of times a command has been sent so you can alert someone to a device not responding after x retries. When a response is received indicating the command was successful, you increment the current command pointer and depending on how you are initiating the next command delivery, you may initiate the next command be sent.
If the device does not acknowledge commands, but does allow you to query it for data, you could create a timeline for command delivery that meters command delivery and base the timing on the baud rate plus any processing time required by the device. You then have to insert the query command every x time commands are sent and if you go y amount of time without receiving a response, you increase the time interval of the timeline and/or halt the delivery of queued commands while you wait for a response.
If the device offers now 2 way communication, all you can do is handle transmission based on a timeline and hope for the best
Jeff