LabVIEW
Warning 1073676294 occurred at VISA Read in Omega
Your warning is almost certainly a red herring. This warning simply means that the VISA Read did indeed return as many characters as were requested and there MIGHT be more in the incoming buffer. It may seem odd to return a warning for it but VISA communication is in many ways somewhat different than many other things in LabVIEW programming. In your case you can safely ignore this warning!
Depending on what sits on the other end and what protocol this thing uses it can be even common that VISA Read would return a timeout error because no data could be read, but that this is totally fine for the particular device and a driver for this device has to purposefully ignore the timeout error.
For the driver in question all I can say is: Looks good on first sight but is Bad! Bad! Bad! when looking deeper.
It looks nice from the outside as it follows the NI Driver Development style guide but its implementation is awful. Any driver using VISA:Bytes at Serial Port anywhere is in 99.9% of the cases simply a hack at best. There are other things wrong with this driver. Each query does write the command, THEN Flush the receive buffer, THEN wait 100 ms and then using the Bytes at Serial Port to read what is in the receive buffer.
While it is reasonable to assume that LabVIEW on even an old Pentium computer will be much faster to send the data to the serial port buffer and then flush the receive buffer before even part of the message has been transmitted to the device, it feels illogical to flush the buffer after writing a command and not before! The 100 ms delay is necessary because they use the Bytes at Serial Port to find out how much data to read for the response but this Bytes at Serial Port is almost certainly NOT necessary. As can be seen in the CN7500_Checksum.vi every command send is terminated with a <carriage return><line feed> character sequence and it is VERY likely that the response from the device is terminated equally.
They even setup the VISA resource in CN7500_Initialize.vi to use a <line feed> Termchar but forgot to enable the Termination Character Enable property. With that set to true the whole 100 ms delay and Bytes at Serial Port stuff could be simply thrown out and replaced by a constant to the VISA Read that is guaranteed to be larger than the longest possible response.
Advantages of that would be that any command response won't take more than 100ms but only as long as the device needs to actually respond. And the entire communication would be more robust too.
@rolfk wrote:
Your warning is almost certainly a red herring. This warning simply means that the VISA Read did indeed return as many characters as were requested and there MIGHT be more in the incoming buffer. It may seem odd to return a warning for it but VISA communication is in many ways somewhat different than many other things in LabVIEW programming. In your case you can safely ignore this warning!
Depending on what sits on the other end and what protocol this thing uses it can be even common that VISA Read would return a timeout error because no data could be read, but that this is totally fine for the particular device and a driver for this device has to purposefully ignore the timeout error.
For the driver in question all I can say is: Looks good on first sight but is Bad! Bad! Bad! when looking deeper.
It looks nice from the outside as it follows the NI Driver Development style guide but its implementation is awful. Any driver using VISA:Bytes at Serial Port anywhere is in 99.9% of the cases simply a hack at best. There are other things wrong with this driver. Each query does write the command, THEN Flush the receive buffer, THEN wait 100 ms and then using the Bytes at Serial Port to read what is in the receive buffer.
While it is reasonable to assume that LabVIEW on even an old Pentium computer will be much faster to send the data to the serial port buffer and then flush the receive buffer before even part of the message has been transmitted to the device, it feels illogical to flush the buffer after writing a command and not before! The 100 ms delay is necessary because they use the Bytes at Serial Port to find out how much data to read for the response but this Bytes at Serial Port is almost certainly NOT necessary. As can be seen in the CN7500_Checksum.vi every command send is terminated with a <carriage return><line feed> character sequence and it is VERY likely that the response from the device is terminated equally.
They even setup the VISA resource in CN7500_Initialize.vi to use a <line feed> Termchar but forgot to enable the Termination Character Enable property. With that set to true the whole 100 ms delay and Bytes at Serial Port stuff could be simply thrown out and replaced by a constant to the VISA Read that is guaranteed to be larger than the longest possible response.
Advantages of that would be that any command response won't take more than 100ms but only as long as the device needs to actually respond. And the entire communication would be more robust too.
I actually peek into at least a couple of VIs before I use a driver so I can decide whether to use it or to roll my own. You'd (maybe) be surprised at how often I choose to roll my own.
