Unfortunately that's not how it works with previous versions of LabVIEW. Could you convert it back to 7.1, or could someone else be so kind as to save it to 7.1
I see that the error cluster is not connected to a shiftregister in the while-loop. And the error indicator is out-side the loop.
This way you will only see the result of the last loop run after you exit and not while your VI is running. You can also add a event for errors to display the error.
If you wait 200msec before reading your device you must be absolutely sure that your device is ready after 200msec.
KC, i experimentally detrmined the delay necessary plus some margin added but frankly it could sometimes happen that it may take longer for the device to respond
is there any better way for serial port to make sure that all we waiting for is ready to be read? assuming i dont exactly know number of bytes i need to read from the device, if i knew i guess its enough to just count the bytes
I cannot say that the VI i use is better but it works for me for all my devices at RS-232 and RS-485 interfaces.
The VI writes data to the COM port and then waits for the number of bytes OR waits for the same number of bytes at the com port for the last 5 cycles (100msec / cycle) or times-out.
Like you said if you know the number of bytes it's easy. But it also helps if you only know the maximum number of bytes.
The VI works fine for me also for jobs where I don't know the number of bytes to receive. Just give it a try.
I too work with an undetermined amount of bytes to read from many instruments so I can hopefully make use of your COM vi. Also, thanks for saving the other vi in 7.1, I appreciate it.
It's funny how the littlest of things can help you realise something so simple. The send string in your VI immediately resulted in a timeout error and it gave me an idea to "piggyback" my scan (?SCU\r) command with the desired ACK response (\06). Simply by sending the ?SCU\r\06 string I get a byte count greater than 0 every time. Before my vi was messed up with something of a race condition problem that I've been having a lot of trouble with and sometimes I would get a byte count around 100, and sometimes I would get a 0 byte count.
