LabVIEW
New information - Bytes at serial port problem
While this is an annoying bug, using Bytes at Serial Port for serial port communication is almost always the suboptimal choice anyways. On serial port communication you have typically two types of communication:
- Fixed size protocols: These are protocols where the size of the message is known before trying to read data. This also includes protocols where you have a fixed size header that contains the number of data bytes that will follow.
- Character terminated protocols: These protocols use a specific character (in GPIB also a specific handshake line) to signal the end of message.
For both types, using Bytes at Serial Port is definitely the wrong choice. The first needs to read the number of bytes that the protocol mandates, rather than what is currently in the buffer, to avoid truncated and/or concatenated messages, while the second is much more reliably (and with a lot less code in the application) handled with the VISA termination character feature.
The only case where I could see Bytes at Serial Port somehow useful, is when trying to write a serial port terminal application, but to do that in LabVIEW seems like using a 50 ton hydraulic hammer to drive in a nail.
I fully agree, Pau! Both that it is a bug and that binary data can't be read with the termination character method.
However it is my true and full opinion, that a protocol using binary data without some kind of known data length is a completely broken protocol. There is no way to do reliable data communication with Bytes at Serial Port without a lot, and I mean really a lot, of rather involved extra code on the receiving side. Only a terminal type implementation can simply use Bytes at Serial Port, since the interpretation of the displayed data is then done by the human.
For machine control application, to make sure that Bytes at Serial Port wasn't called in the middle of a message and therefore only returns partial messages, or does contain more than one message which then has to be separated and the remaining part stored somewhere to be used for the next cycle, requires a lot of extra code, with a great potential for extra errors, especially since serial port communication can sometimes return errors too, and if you are not very careful there you loose either already stored data in the intermediate buffer or concatenate errornous data together. Been there done that and quickly abandoned once the VISA implementation with termination characters got reliable enough.
