LabVIEW
Serial Port Reading
Solved!
Without knowing what device it is and seeing the Programming Manual for it, debugging this is really shooting in the dark.
As Jorge already mentioned the command "1" looks suspicious. But more importantly there is no hardware handshaking on serial lines that tells the device "this is the end of the message, start to decode and interpret it". While a command parser can be made to operate on input streams and recognize commands as soon as they make sense without any specific "end of message" indication, such a parser tends to get pretty involved and cumbersome very quickly, so they are seldom implemented that way.
Therefore when talking with a serial device you almost always have to append an "end of message" indication such as a <carriage return> or a <line feed> or a combination of both.
Most people get misled when trying to talk to a serial device through a terminal app, thinking that they never had to append a termination character to the message, not realizing that the very activation of the Enter key not really tells the terminal application to send the string of, but rather causes one or both of the above mentioned characters to be sent to the device.
You can easily add this character to your command in LabVIEW. Either using a Build Array and one of the according constants in the String palette (you need to know that the Carriage Return constant always will add the carriage return character 13 or 0xD, while the Line Feed constant will add the linefeed constant 10 or 0xA). The End of Line behaves differently depending on the LabVIEW platform it is executed (on Windows it adds <carriage return> + <line feed>, on Unix it only adds a <line feed> and on Mac it adds a <carriage return>.
Alternatively you can enable Backslash Code Display on the string constant with the right click menu and enter directly \r for <carriage return> and \n for <line feed>.
And once you have a working communication in highlight mode, get immediately rid of the Bytes at Serial Port property. It will not work like that as the Bytes at Serial Port will be evaluated before the entire string has been received by the device, processed and an answer has been sent back. People who use the Bytes at Serial Port property are tempted to add delays after the VISA Write to avoid this problem but that is really like repairing a water leak with paper: BAD BAD BAD!
The device usually will terminate its response in the same way as it expects the command to be terminated. VISA Configure Serial Port has two specific input parameters, one is a boolean called "Enable Termination Char (T)" which is by default set to true and the other is an integer called "termination char" whose default value is 0xA for the <line feed> character. If your device terminates the message with the <line feed> character you are already done, otherwise change the "termination char" input to the ASCII value for the character the device uses. Now you can simply place a VISA Read after the VISA Write, pass a number of bytes to read to it that is guaranteed larger than the longest message the device will ever return, and adjust the timeout on the VISA Configure vi to a reasonable value if you find the default of 10 seconds unsuitable and the VISA Read will always return after one of these conditions has been true:
1) an error occured
2) the termination character has been received
3) the number of requested bytes has been received
4) the timeout has expired
In addition to what RavensFan said:
The quotation marks are almost certainly only meant to indicate that you need to enter that text literally and will not be expected to be actually sent to the device.
Are you sure you set the device address to AA? I think it is more likely that the device uses by default an address of 00 or something close to it.
And while the ms command may be supported it is not mentioned in the part of the manual that you posted. So I would first try with the example as in the manual.
And no \13 is not the right code for carriage return. If you want to enter the numeric value of an ASCII code you have to use hex values, that means you need to enter \D and when the string control is correctly set to be in backslash mode, LabVIEW will automatically change this into \r, the preferred format for backslash code display.
Last but not least, why does everyone think that sending an image is perfect? Are you afraid someone will steal your VI? This way it is impossible to check if you entered the command correctly as the backslash only means the right thing if you enabled the option in the string, but that is not visible in a picture.
And of course will you receive a timeout as long as you are not sending the exact perfect command. Most serial devices will simply ignore anything they don't understand and/or wait for the correct termination character which you haven't sent so far.
With the Bytes at Serial port you will simply always see 0 as result since the device doesn't send anything back, with the VISA Read you get a timeout error until the VISA Read sees a termination character or the amount of requested bytes. Your specific device adds to that an address (the first two numbers in the command) and as long as those two characters are not matching the address the device is configured for it will simply ignore the entire command.
