I have a serial device (sick LMS200) connected to my PC using a RS422 to USB converter. The serial settings (baud, stop bits, etc...) on the LMS200 and my PC match and are communicating (verified using an application that ships with the LMS200). I need to write a custom application which communicates with the LMS.
Before I can begin building my application I need to figure out how to exchange datagrams between the PC and the LMS. To figure this out I have been trying to manually send datagrams using PuTTy. The manual for the LMS ( https://drive.google.com/open?id=0Byv4owwJZnRYVUJPMXdud0Z6Uzg) defines the datagram types and how they should be built. For example, on pg 46 of the manual it is possible to see a datagram that sends a specific instruction to the unit; it looks like this: 02 00 02 00 30 01 31 18.
However when I use PuTTy to send the string 02 00 02 00 30 01 31 18 the LMS does not respond (which it should). I believe it does not respond because the datagram is missing either some serial header data or I am not representing the hex values correctly (I tried to represent bytes such as00 using 0x00 and 00h but had no success). Can you please help me formulate a valid serial message using the manual? I have been at this for a very long time and I am having a really hard time understanding how to convert the information in the manual into a valid datagram.
Please let me know if I can provide any more info. Thanks in advance.
I am not representing the hex values correctly (I tried to represent bytes such as00 using 0x00 and 00h but had no success).
The Ctrl key on terminal/PC keyboards can be used to generate ASCII control characters (i.e. the unprintable characters with byte values of 0x00 through 0x1F).
Just like the Shift key generates the shifted or uppercase character of the key (instead of its unshifted or lower-case character), the Ctrl key (with an alphabetic or a few other keys) can generate an ASCII control character.
The typical USA PC keyboard can generate an ASCII 'NUL' character by typing ctrl-@, that is, by holding down the CTRL and Shift keys, and typing 2 (since the '@' character is the shifted character of the 2 key on USA PC keyboards).
In similar fashion for 'SOH' or 0x01 type ctrl-A (i.e. CTRL+A keys, the Shift is not necessary), for 'STX' or 0x02 type ctrl-B, et cetera.
For 'SUB' or 0x1A type ctrl-Z.
For 'ESC' or 0x1B type the Esc key.
For 'FS' or 0x1C type ctrl-\ (or CTRL+\).
For 'GS' or 0x1D type ctrl-] (or CTRL+]).
For 'RS' or 0x1E type ctrl-^ (or CTRL+Shift+6).
For 'US' or 0x1F type ctrl-_ (or CTRL+Shift+-).
Note that a few oft-used ASCII control codes have dedicated keys, e.g.
'HT' has the Tab key for 0x09,
'BS' has the Backspace key for 0x08,
'LF' has the Enter key (in Linux) for 0x0A, and
'ESC' has the Esc key for 0x1B.
When you don't know how to generate the ASCII control characters from the keyboard, you could fall back on creating the message in a file using a hex editor (not a text editor), and then send the file.
Actually the binary file could be the most reliable method of hand-generation of binary messages. Hand-typing of control codes could fail when a code is intercepted by the shell or application program as a special directive to it (e.g. ctrl-C or ctrl-Z to abort the program) rather than treating it as data.
Escaping the input data is one method that might be available to avoid this.
Phone modems have managed to avoid this issue when in transparent (aka data) mode, by requiring a time guard (i.e. specific idle times) to separate and differentiate commands from data.
The way to get this done is to:
(1) download HexEdit software, and create a file containing HEX values (not decimal reprsentations of the ascii table - where the number 2 was being tramitted as 32)
(2) use Tera Term software to then send the file over the serial line.
