Re: wait for replay
- From: Winbug <Roger.Valand@xxxxxxxxx>
- Date: Wed, 14 May 2008 02:55:22 -0700 (PDT)
Thanks guys
Using queues might be the simplest solution. First in - First out kind
of queue.
I'm using a simple component called CPort (SourceForge project). It
does what I need. (I've also looked at the Async Pro components).
Luckily, my instrument sends back chr(13) at the end of each
responses, so I gather up each snippets in a global variable before
sending it to parsing. Then I empty the global var ready for next
response.
You triggered my mind to come with a new solution. Wich might be
simple but efficient is to create only one command queue keeping track
of how many commands have been issued. First I put as many commands
in the command queue as there would be loops. When the response
arrives, the parsing is completed. At the end of the parsing function
I then checks the queue and if there are commands left, I send it off
to the instrument. That way the instrument is the controlling factor,
since the serial component really is responsible for trigging another
command. If I get en error message from the instrument, the command
queue is emptied. The computer will then follow the instruments pace.
What do you think? See any pitfalls in this scenario?
Roger
.
- Follow-Ups:
- Re: wait for replay
- From: Maarten Wiltink
- Re: wait for replay
- References:
- wait for replay
- From: Winbug
- Re: wait for replay
- From: ham
- wait for replay
- Prev by Date: Re: wait for replay
- Next by Date: Re: wait for replay
- Previous by thread: Re: wait for replay
- Next by thread: Re: wait for replay
- Index(es):
Relevant Pages
|