Advice on Communication VI’s - Polling for replies

[D.Barr]

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

[Gak]

Hi148dba,

If you know what reply you are going to get, then you can compare recieved string with expected after say 5 ms.

This will reduce time.

[Ben]

You may want to review this post where I show how I keep up with the data coming in from a serial device.

Using that technique you can check the serial port more often but only process when you have a complete packet.

Ben

[D.Barr]

Thank you both for your replys.

The tip about looking at the number of bytes at a serial port is proving very useful. I am now trying to implement a similar solution to our TCP comms. The only issue i am finding is there does not seem to be a "number of bytes" equilivent for TCP. If anyone know how to find the number of bytes waiting at a TCP port that would be very useful.

Thanks again

D.Barr

[Lucither]

Hi 148,

I have never done any of this before so some of this may be incorrect but you could have a separate loop with the 'TCP Read' vi in, in standard mode. Have the timeout at something like 100ms. Put the bytes to read at something like 10 (can be altered on what you are expecting to see). have the read string fed into a queue that is passed to your processing loop. If you read 10 bytes, 10 bytes will be sent, if you read less then these will be sent after the read vi has timed out. In your consumer loop you will be fed new data every 'Timeout' period or less depending on whether you read 10 bytes or less. In your read loop add some code that if 0 bytes is read not to update queue.

Sorry if this is a bit vague but it is very late where i live and i have had some of my favourite brandies.

Hope this helps. If it doesnt let me know and i will write a demo vi tomorrow. Dont trust myself to do it though at the minute

Rgs,

Lucither

[Lucither]

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.

[D.Barr]

Thanks Lucither for the post brilliant advice should be very helpful.

Many thanks

D.Barr