LabVIEW
Bytes at Port Property Node. When to use it and when not?
Solved!
It’s easier to filter the timeout error after VISA Read. If that function times out it simply means that there was no data yet (or not enough and the data that was there simply stays in the VISA session buffer). No need to work with delays that are always either to short to work 100% or way to long for 99.9% of the cases.
I did use Bytes at Serial Port too in a grey past, but soon found that I was always ending up with very elaborate VIs that did their own buffer handling and termination character encoding. And it required generally delays too. But if you start putting delays in communication functions for anything else than giving CPU up while waiting, you are doing it wrong. And that giving up CPU is already done by VISA Read when it waits for the requested data to arrive, so if using VISA and you end up using delays you are doing it wrong. Yes I know slapping a delay between two functions seems like a quick and easy fix, but it always will bite you sooner or later as the instrument may get slower with a new firmware or the communication infrastucture changes such as using a different interface type, PC or OS.
@STTAndy wrote:
I don't know if I am still missing the point somewhere but it appears to me that reading the data before it is available produces an error and reading the data immediately after bytes at port says there is data available can produce truncated results so it still requires a delay to ensure the whole data package is ready.
If you use the Bytes At Port to state how many bytes to read, then you run into this issue. You need to know the protocol of the device in order to do a proper VI, knowing how many bytes you need to read for the message whether it is using a termination character, set message lengths, or length as part of the message (or implied by the command ID).
@STTAndy wrote:
I am finding that attempting to read the port when there are no bytes available produces an error that prevents further writes or reads. Error -1073807339.
It is necessary to stall the read until the bytes are available.
That is a timeout error. It just means that the entire message was not at the port before the timeout. Just set your timeout to be longer and you will have your data as soon as it is available without the timeout error. No need for bytes at port.
I, too, am a former user of bytes at port, but have found that most of where I was using it was actually making my program less efficient.
I think we need to look at the communications protocol. What you're describing doesn't seem unusual, and doesn't seem to need bytes at port, at any rate.
Reading a serial port doesn't even have to be especially "slick" as your code will mostly be waiting around to read stuff.
@STTAndy wrote:
For the application I am working on I need a constant stream of readings from devices that only provide one reading per request so the cycle of send command and read data needs to be slick.
This is exactly the reason not to use bytes at port. If you have known length responses just read that number of bytes using a long enough timeout that you know you will get the data in that time. It takes longer to read bytes at port and then read the data.
