Polling devices efficiently?

vegastech

I didn't see this anywhere, so here's my question:

What is the best way to enable polling on serial/IP devices in order to track their status? Specifically, I really only care about Power Off/On, and Input Selection. I have created 2 variables, nTVPWR and nTVINPUT, which work fine when pressing buttons on a touchpanel, but I want the program to go out and check every 30 secs to determine if the TV is still on, and if so, what input it is using. I thought this programming should go in DEFINE_PROGRAM, but should I put it in DEFINE_START instead?
I was thinking of a simple if statement that would send a serial string to the TV and then parse it for my variable's number.
I can't seem to find a polling command in the Netlinx programming guide to start with.

ericmedley

There is no such commonad. YOu'll need to create a polling loop from scratch. A simple way to do it is simply put it in a wait in the DEFINE_PROGRAM seciton and it will fire every 'whatever' tics.

WAIT 300 // Every 30 seconds
{
// send_string to poll for info
}

The issue with this is that do this no matter what the status of the port.

Another way is to use a WHILE loop. This can be tied to a variable that tracks the status of the port in case its down.

The way I do it is use a TIMELINE. a timeline gives you many levels of control over how things fire and allows you to modify stuff dynamically.

vining

Since polling and/or feedback usually isn't required unless a user is on a device page I like to set a flag when some one goes "on page" and turn this flag off when they hit the exit button for tha page. It gets a little more complicated than that since you generally need an array of flags so there is one for each TP that can potentially be "on page". Also if a panel drops offline you have to make sure its flag is reset to 0 and any time one TP goes "off page" you need to run a loop throgh the array to see if anyone else is on or not. I guess you could just try incrementing /decrementing a single variable flag but I also use this same flag to determine which module instance a TP may be on so I never tried just that.

Now when some one is "on page" I'll start polling (if needed) and feedback. Even in these cases I tend to do feedback as event driven but in define_program (behind a wait) or timeline will work for either purpose.

trustworthy

For power status you could use a power sensor device, connected to the I/O port of your master. This will give you a real power status rather than a fake one when the On command is sent. If its impractical to install one on the 240/120 line you could use it on the AV signal (it'll go high when theres 1v P-P present).

Can you send a string to the TV to request the current input? If so then a timeline would be the best way to do this, and you can determine when the best time to do this is (it may not be necesary every 30 seconds in reality). This may negate the need for a power sensor anyway because the device might only respond if its on.

TurnipTruck

I would put your poll command into a queue in case an actual command would attempt to be sent within a time window that would cause a collision.

DHawthorne

There are a lot of ways to do this, and the short answer is: it depends on your device. If your device can be set to do unsolicited feedback, that's the way to go, and there is no polling at all to do. If that's not possible, this is the questions I ask myself: exactly when do I need this information? If the device state never changes unless your program changes it, poll for specific states right after a command that might have changed it. If the user can change it, figure out the smallest possible interval and poll based on that. Power states, for example, you rarely need to know to the second, and you can check them every 5 seconds or so. Other things you might need more frequently. Similarly, in many cases, if the device is off, you don't really need to know anything else, and you can pop into a minimal polling mode.

Bottom line is, I don't think there is one answer. The main guiding principle is, however, don't poll any more than you absolutely have to. It not only bogs your program down, but can often bog the device itself down to the point it's so busy answering your polls that it isn't doing it's job. I've had cases where I had to sacrifice having current data just to make sure I didn't lose control (most recently, with a Jandy pool controller ... anything quicker than a 3 second interval on polling, and the thing didn't have time to do it's job).

TonyAngelo

TurnipTruck wrote: »

I would put your poll command into a queue in case an actual command would attempt to be sent within a time window that would cause a collision.

This is how I usually handle it. My queue's run in DEFINE_PROGRAM, here is an example:

IF(LENGTH_STRING(stDenonBlu.TxBuf) && stDenonBlu.CTS) // stuff in the buffer and clear to send
{
    OFF[stDenonBlu.CTS]
    // cancel related waits
    CANCEL_WAIT 'Cancel Denon3800 CTS'
    CANCEL_WAIT 'Poll Wait'
    IF(LEFT_STRING(stDenonBlu.TxBuf,1)="$02") // if the first char is the start bit
    {
	SEND_STRING dvDenon3800,REMOVE_STRING(stDenonBlu.TxBuf,LEFT_STRING(stDenonBlu.TxBuf,10),1)
    }
    ELSE // WTF!!
    {
	SEND_STRING 0, '!Denon3800 Tx Buffer error: cant find start bit!'
    }
}
ELSE IF(!stDenonBlu.CTS) // not clear to send
{
    WAIT 25 'Cancel Denon3800 CTS'
    {
	ON[stDenonBlu.CTS]
    }
}
ELSE // poll
{
    WAIT 300 'Poll Wait'
    {
         // send poll command
    }
}

For this particular device I do not need to poll because it has unsolicited feedback, but if I needed to poll I would do so by putting the polling command in the ELSE bracket. It will only poll when there is no communications happening.

kbeattyAMX

If the device does not provide unsolicited feedback. Poll after you send a command and poll occasionally to update feedback if the device changes status without you sending a command. I generally use a timeline event and buffer outgoing commands so commands don't collide with a poll command.