Is there a way to test an input buffer for data before doing a VISA read?

[Japper]

I have a VI that configures and reads a serial port with a VISA read inside a while loop but if there isn't any data available in the input buffer, the VISA read will give a timeout message. Also, because it is in a while loop, it sits there waiting for data to read and keeps the user from stopping the application until after some data is read.

Is there way to test that there is data to read in the input buffer and only do the VISA read if there is?

I was reading up on Producer/Consumer (Event driven events) but not sure how to get around this VISA read and if

there is a way to make an event when data is available on the Serial port so that I can execute code to capture the data.

Any helpful suggestions are appreciated!

Thanks

[johnsold]

Use the Bytes at Port property node.

Lynn

[joaopam]

If I got your need right, I think that one simple solution would be:

Check the number of bytes at port (using property nodes)

See if the number of bytes is higher than 0.

There must be something more complex, but I think this might help.

Regards

[pjr1121]

I don't know if this is directly relevent for you or not, but some devices have internal registries which set a bit when the data is ready to be retrieved.  You could poll this bit of the device registry.  If not, the bytes at port would be your best option.

You also said that while you are waiting for the measurement, the user can't do anything.  If instead, you place your read code together with code that stops the program or causes another event, this will bypass it (stop the while loop or something more elegent).

For a state machine architecture, you could have the READ state test for data, then check for user input.  The next state will be determined based on the results, either go to READ state again, or proceed to another state to handle some user input.

If you are using Queues to control the states, a user input during the READ state will add an event to the front of the queue so it is handled next.  If data is not ready to read, add another read state to the end of the Queue.

[Japper]

Thanks for the suggestions...

I decided to use the Bytes at Port property node which helps to guard against the time out issue I was seeing...

I have set up an event driven Producer/Consumer configuration where I have a test button, a print button, and a quit button .

Currently I have a routine that gathers the new test unit Serila  and then polls the serial port as part of the test event. I would prefer to make this polling function happen as a default and use the buttons mentioned above to interrupt this polling process to do the following:

test event - enter new test unit serial #

print event - print test report

quit even - quit the application

In other words I wish to split the two functions shown below so that the polling routie happens and the events interrupt it.

Is there a default event state that  I can create for this polling event? 

[Japper]

I also tried thhe following to create an event with serial dat but it didn't work either as it just sits there after checking the port for data...

[OlivierL]

All event structures have a "Timteout" case.  You need to wire a value to the top left terminal if you want to use this for your polling and wire somethign like 10 (i.e. 10ms) so that the VISA device is checked for new data every 10ms as long as no Event happens in the mean time!

[RavensFan]

You need to attach an actual VI.  It is impossible to troubleshoot a screenshot where a lot of the code is cut off the screen.

In general, it is a bad idea to have a while loop inside of an event case.  It can keep an event case running for a long period of time without a proper way to handle other events quickly.

You have a Bytes:value chane event.  But your Bytes appears to be an indicator.  Are you using a value (signalling) property node of "Bytes" anywhere?

[pjr1121]

In regards to your event structure diagram, you have a Case Structure inside a While loop.  The boolean fed to the case structure never changes, it's just the value input at the start of the while loop.  If your while loop isn't ending until the case structure runs, then it won't work.