LabVIEW
Convert byte to integer, have troube in type cluster
The functions viWrite and viRead in the Spy log indicate that you used the VISA Interactive Control panel. These are the C API functions called by all applications except LabVIEW. LabVIEW uses slightly different API functions to match the actual VI names more closely.
Obviously you have not disabled termination character in there which is why the viRead only returns 98 bytes as the LOOP response is terminated by a <CR><LF> pair followed by a binary 2 byte checksum. While it seems to work for this specific data it's still not a very good idea to enable the termination character for the receiving of the loop response since the earlier binary data could also contain 0xA bytes which the VISA termination detection would interpret as message terminator and stop returning data at that point so with termination character <LF> set, one would need to loop VISA Read until we received 98 bytes and then read another 2 bytes (which also could require up to 2 VISA Reads since the binary checksum could also contain the 0xA value.
The ,7 (0x7), 7 (0x7) is simply a slight difference in reporting the API call for the standard vi.... API and the special LabVIEW API. It corresponds to the 2 extra parameters that viWrite requires, the first being the number of bytes to write out and the second being the number of characters the viWrite() function reports to have moved to the output buffer without error.
@rolfk wrote:
The functions viWrite and viRead in the Spy log indicate that you used the VISA Interactive Control panel. These are the C API functions called by all applications except LabVIEW. LabVIEW uses slightly different API functions to match the actual VI names more closely.
Obviously you have not disabled termination character in there which is why the viRead only returns 98 bytes as the LOOP response is terminated by a <CR><LF> pair followed by a binary 2 byte checksum. While it seems to work for this specific data it's still not a very good idea to enable the termination character for the receiving of the loop response since the earlier binary data could also contain 0xA bytes which the VISA termination detection would interpret as message terminator and stop returning data at that point so with termination character <LF> set, one would need to loop VISA Read until we received 98 bytes and then read another 2 bytes (which also could require up to 2 VISA Reads since the binary checksum could also contain the 0xA value.
The ,7 (0x7), 7 (0x7) is simply a slight difference in reporting the API call for the standard vi.... API and the special LabVIEW API. It corresponds to the 2 extra parameters that viWrite requires, the first being the number of bytes to write out and the second being the number of characters the viWrite() function reports to have moved to the output buffer without error.
Hi Rolf,
It's weird because I didn't set enable the termination character. I tried to enable it then I can read 100 bytes instead of 98!
Anyway, I still got timeout no matter I enable or disable the termination character. I think there might be something wrong with the configuration I set in Labview.
@feelsomoon wrote
You're correct. So it stoppped anyway no matter I enable the termination character or not!
I very much doubt it! Where did you think you disabled the termination character detection?
@feelsomoon wrote:I didn't choose the enable termination character box when I send and read for the first time in the test panel. I didn't find a separate button to disable the termination character.
In the VISA Test Panel on the first tab Configuration in the sub tab IO Settings, you can change the termination mode and in order to make them apply you also have to push the Apply Change button. In NI IO Trace you should then see an according line viSetAttribute(ASRLx::INSTR, TERMCHAR_EN, VI_FALSE) line.
