Re: wait for replay

"Winbug" <Roger.Valand@xxxxxxxxx> wrote in message
news:26194a82-5aa8-4875-ac7a-8ea6c7630b74@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I am sending commands to an instrument over a serial link and expect a
response from the instrument. Certain commands have to be sent
repeatedly by a loop. Every command is answered with a respons by the
instrument. The problem is that the instrument have no time to
respond successfull or failed before the loop is over. Sometimes the
wait is some milliseconds and other times up to a seconds.
The problem is wich strategy to choose. There is one procedure
initiating the loop, by a button. Another function is processing
replys from the serial component. Somehow, the procedure have to be
notified when the replay arrives and the loop can continue.

So, should I use messages or threads or both. Threading is new to me,
so if there is another easier way...

With the right ensemble of messages, event handlers, and queues, you
should be able to construct a continuously running system that does
not wait synchronously for a response to every command. Instead, the
fact that a command has not been answered yet is indicated by its
still being on the waiting-for-response queue.

When the response arrives, the command is popped off the queue and
they can be processed together. If incomplete responses are possible,
there are queues both for incoming and outgoing (gone, really) traffic,
and you wait until you have a complete matching package at both heads.
If responses always arrive in one piece, you can dispense with the
incoming queue.

If processing a response can tie up the computer for long enough to
interfere with further reception, you need threads. But that's not
usually the case and even then there are workarounds.

Does that give you an idea?

Groetjes,
Maarten Wiltink


.

Quantcast