On Tuesday, August 20, 2002, at 04:26 PM, Rich Mooney wrote:
> No. My commands are going out a serial port to a device we make which > converts from serial to our protocol which is similar to > Appletalk. I do > have the capability to send my commands through TCP/IP to a module > which > converts from TCP/IP to our protocol and I've considered trying > this onsite > to try to work around the problem. I know what you are going through. I just got a call from a customer on a similar problem. Their customer had just upgraded their Unison (lighting control) system and now we have errors that slow down the polling cycle. (I wasn't able to convince the Unison folks to avoid the need for polling back when they were setting up the protocol.) I think I'm getting the picture. The entire polling operation is done in one handler (and subs). At the end of that the next one is scheduled with a send. You might want to put a meter on the number of lines in pendingMessages() just to be sure this is how it is working. Or log the value. If this is all in one handler then you must be using "read until <string>" or "read for n" depending on your protocol. Do you use "in time"? You might want to log those timeouts or put a counter on them. You might want to log the time and the long seconds since start of poll for each write and read as well as other events such as retries. Log result and syserr, too. (I use a different style. I read all available bytes in a single read in a handler called in timer send cycle and process those for messages. I might get some delays, but this allows me to do other things at the same time. And it allows me to use the same method for processing tcp messages as serial. With tcp a callback is available.) As you can tell, I've run out of ideas on what might be causing the slowing down. These are just some that might give you a heads up as to what is happening. You said only a slight increase in memory usage, right? Is this the kind of thing where you need to empty your read buffer just before sending out a command just incase there is something in there? Dar Scott _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
