Advice on Communication VI's - Polling for replies

Question

Advice on Communication VI’s - Polling for replies
Hi all
I have been given the task of improving the performance my works communication vi’s. One of the main areas I have found that needs improving is how we implement a delay between a commands being transmitted and when we read back the data from the DUT. Currently we use the flowing steps:
  • Convert text string into Hex
  • Transmit Hex commands to DUT using appropriate protocol (TCP, USB)
  • Wait Xms
  • Read Reply
  • Check Reply is valid
The main issue we have is that we adjust the X ms delay to cover the slowest possible command the DUT supports (~2 sec), however most command will return in ~20 ms. I am planning to replace the “wait X ms” vi with a vi that will continuously reads/polls until it receives a valid reply. This way communication vi will only delay for the require amount of time. This is the area I could do with some advice. Should I continuously poll/read to detect if a reply has been received, or is there a better method of detecting arrive of a reply?
Any advice would be gratefully received
D.Barr

Answer 1

Hi 148,
I have attached an example vi. It does not run as is just an indication of what i think you need. I wanted to just post a pic of it to give you and idea but my browser kept on crashing and im too intoxicated to figure out why so you can view the example instead.
Would be an idea to run a seperate loop that constantly scans the tcp read vi. If you set it in standard mode, it will either update all read bytes once 'bytes to read' is complete or update with the bytes read once the vi times out. This can then update a functional global that acts as a data buffer and message parser. Your main loop can then poll this for any new input messages. I havent included the functional global just an example of what the dedicated loop should do.
Hope this points you in the right direction. Im off to bed, goodnight.
Lucither.
"Everything should be made as simple as possible but no simpler"
Attachments:
TCP buffer.vi ‏8 KB