LabVIEW
labview program working in highlight mode and not working in normal mode
Solved!
@Ben wrote:I am curious why you have such a strong opinion about checking the number of bytes waiting at the serail port and reading as many as are indicated.
Because you will miss parts of messages unless you wait a LONG time. Most instruments use the CR as the marker that the message has ended. So just save yourself a lot of headache and just let VISA handle searching for it for you. You will now know that you got the entire message and you can process it.
Yes, for instruments that just stream data in this format, the first message will likely be trancated. But you can handle that at the point of connection (do a read and do nothing with the data). From there, just let the termination character determine when a message has ended and take care of it.
But where I do like to use the Bytes At Port is just for checking if a message has even started, like I showed earlier. But the Bytes At Port is not used to tell the VISA Read how many bytes to read, otherwise we would be back to the original issue. If there is a termination character, use it!
This is valid for ASCII messaging (you can read the raw serial data in a text file). For binary messaging, then you need to be smarter (like read 1 byte at a time until you find the message start byte, then read the message type byte, then read then number of samples needed for the rest of the message, perform CRC/checksum validation where applicable).
I have plans for a series of nuggets for serial port communications. I need to work on those again for reasons just like this...
@Ben wrote:
For those very old-school widgets that would drive a dot-matrix printer and used a CR LF termination I was able to pick-up in the middle of the device being connected to a serial port (first packet is generally corrupted or malformed) search until I find teh CR LF and then syncronize with the incoming data stream.
Many on those old devices did not accept commands but would just start spewing serial message to print on the printer.
I am curious why you have such a strong opinion about checking the number of bytes waiting at the serail port and reading as many as are indicated.
Just curious,
Ben
As others have pointed out, if you have a termination character you really shouldn't need Bytes At Serial Port (BASP) at all. You simply start of reading data and the first packet you may have to verify to be a full packet and after that you can sit back and let VISA do all the work!
I can see some usefullness in using BASP to check if there is any data available and if not go to do other things rather than letting VISA Read block the thread, although it is in most cases not really a problem to have a thread blocked by VISA Read as LabVIEW has more threads available and doing other things in the same code module often is rather violating the isolation of code responsibility.
For full binary protocols with no common termination character BASP is an option although it makes the protocol handling not really easier, it just exchanges some of the complexity for other complexity.
The only case where BASP is really undispensable is when you want to implement a terminal like UI. There you don't care about partial data blocks as all you do is dump it on a screen and let the user do the decoding 
.
Humans are pretty good at that sort of task to recognize patterns easily and that is what people struggle to understand when trying to implement a reliable device driver. What seems intuitively trivial to do as we simply do it without much effort proofs to be pretty hard to do when you need to put it into formalized programming instructions 
@rolfk wrote:I can see some usefullness in using BASP to check if there is any data available and if not go to do other things rather than letting VISA Read block the thread, although it is in most cases not really a problem to have a thread blocked by VISA Read as LabVIEW has more threads available and doing other things in the same code module often is rather violating the isolation of code responsibility.
Just to play Devil's Advocate...
I had an instrument that only sent data over the serial port when something changed. I initially just let the timeout do its job of waiting for data and let it do the waiting. But I actually ran into the race condition where I only got part of my message since the message was sent right when the timeout was expiring.
Yes, this is a rare situation. But it does happen. So for any type of slow streaming (like 200+ ms/sample) or randomly sending data instruments, I always first check to see if there is anything in the port first. If there is, I read my entire message. If there is no data at the port, I throw in a wait (usually).
@crossrulz wrote:
@rolfk wrote:I can see some usefullness in using BASP to check if there is any data available and if not go to do other things rather than letting VISA Read block the thread, although it is in most cases not really a problem to have a thread blocked by VISA Read as LabVIEW has more threads available and doing other things in the same code module often is rather violating the isolation of code responsibility.
Just to play Devil's Advocate...
I had an instrument that only sent data over the serial port when something changed. I initially just let the timeout do its job of waiting for data and let it do the waiting. But I actually ran into the race condition where I only got part of my message since the message was sent right when the timeout was expiring.
Yes, this is a rare situation. But it does happen. So for any type of slow streaming (like 200+ ms/sample) or randomly sending data instruments, I always first check to see if there is anything in the port first. If there is, I read my entire message. If there is no data at the port, I throw in a wait (usually).
Well, what you describe is a very rare situation. I have come across devices which just squirt data without ever being commanded to do so (GPS devices being one class of them), but not in random intervals. And I would guess that about 95% of the devices I have interfaced so far are fully command-response based.
These rare beasts do IMHO not warrant to use the BASP function for simple basic examples that only confuse new users into thinking they need to use this function for every communication they will run into. I will maintain my stance that BASP is the wrong solution in just about every possible case a new LabVIEW and/or VISA user is ever likely to encounter.
rolfk wrote: And I would guess that about 95% of the devices I have interfaced so far are fully command-response based.
I would say about 90% of the devices I have interfaced with are also command-response, SCPI/ASCII based (I recently ran into several custom instruments that stream data). And I fully agree that the BASP should NOT be used for those. And NI really needs to do some cleaning up of the serial port examples. And by cleaning up, I actually mean to make more. There should be an example for a standard SCPI/ASCII command-response interface and another for a streaming ASCII data interface (constantly read with the occasionally write). I could argue similar for binary interfaces, but that could get complicated since you really need to know the protocol.
