LabVIEW
New information - Bytes at serial port problem
@w0utje wrote:
Offcourse, we also use a protocol length.
but since LabVIEW VISA requires a N-bytes to read input we use the bytes at serial port.
We want to avoid time-outs, because we need to reply as fast as possible.
To read just one byte at a time (fixed) will introduce timeouts if there are no bytes available, also when reading the message, it wil take much longer to get the message.
N bytes at serial port is the LabVIEW solution for this, but having this bug, it's very annoying.
We use our workarround now, but NI should clear this bug.
I think I miss the point somehow here. If you know the fixed size of the message ahead, why do you need to know how much data is in the buffer? What do you win when waiting youself until Bytes at Serial Port returns the number of data you want to receive instead of letting VISA wait? Reading byte by byte is terribly inefficient and should not be done whenever possible, which is AFAIK always!
Maybe you do the receiving of the data in the same loop as other things so you might be tempted to do the waiting for the entire frame with Bytes at Serial Port and do other stuff in the meantime when not enough bytes have accumulated. That I would consider a not so good approach unless it is a very simple application. It increases the coupling of the application very much since you mix different parts of it in the same place, making it not only almost impossible to reuese the code elesewhere but also to maintain and debug it from the begin on.
But then the header has a fixed length, does it? Reading the fixed length header once, decoding it and then reading the variable sized data junk is still much simpler, faster and efficienter to program and execute than writing your own management layer. If even the header is variable sized already without a sure means of reading it with predefined lengths and it does not use termination character indication either, it is surely a badly broken protocol.
I'm not saying here that Bytes at Serial Port shouldn't be fixed, but that it is in fact not necessary at all for any reasonable protocol, unless you write a terminal program, where the human does the actual protocol decoding.
@w0utje wrote:
We want to avoid time-outs, because we need to reply as fast as possible.To read just one byte at a time (fixed) will introduce timeouts if there are no bytes available, also when reading the message, it wil take much longer to get the message.
You will only get timeouts if there is no data. Why is this a bad thing? If the data comes in during the timeout duration, the VISA Read will complete with no errors. That is really the most efficient way.
@w0utje wrote:
The header has a fixed length, so indeed, we can use this.
It is a wireless serial link so it can lose data at every moment. Then you'll have a timeout when you're expecting a number of bytes.
We maybe can use a shorter timeout, so that we can send the reply sooner.
Thank you for your reply's, I will do some tests.
As crossrulz already mentioned, if you get a timeout because of a protocol transmission error you have quite a bigger problem than the timeout. So it would seem to me that even then you are better off trying to use the VISA features instead of implementing your own management layer on top of Bytes at Serial Port. A shorter timeout could help to issue retransmission requests quicker. In the end it is about handling everything on your own (and being hindered by the BaSP bug too) or using as much as possible of the VISA features that actually do work! 
@Bublina wrote:
@rolfk wrote:
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.
Some device protocols use nonfixed length messages without termination character, instead You get a header with length of data.
As I have tried to explain in this thread several times, even this is a protocol with a well known message size before you issue the Read() function. Never mind that you may have to split the read into two (or more operations) to first read the fixed sized header and then the variable sized data, whose size the header has told you. I bet that this approach beats every possible implementation on top of Bytes at Serial Port in terms of speed, ease of maintenance, and programming time all at once.
