ASCII Characters and string variables

    Had some odd experiences trying to do hand-coded serial comms in KRL over the past week. Thought I'd share.

    Had to connect a Keyence camera to my KRC2 via RS232. Got the channel working easily enough, but eventually found that I had to append a Carraige Return (ASCII code 13) to my output string before I gave that string to my CWRITE command, as per these threads that I dug up:

    http://74.125.95.132/search?q=cache…lient=firefox-a
    and
    http://www.roboterforum.de/roboter-forum/…t-t2797.15.html

    But there was a snag. The code described as working in the second link... didn't, for me. Any attempt to SWRITE the value of a Carriage Return into the string using a %c conversion code failed with a #FMT_ERR. This is odd, b/c it's been described as working for other people, and judging from the manual, the %c conversion code should do exactly that.

    Trying UNIX-Style "\n|" or "\r" inside the format string didn't work, either.

    Eventually, someone suggested doing this: STRING[first_clear_position] = 13
    It sounded crazy to me, since string variables (char arrays, really) in KRL are always fussy and hard to work with, but what the heck, I gave it a shot...
    And it worked. It would appear that assigning a single element of a CHAR[] array the value of an INT variable will put the ASCII equivalent of that INT value into the CHAR[] array.
    One other thing I found interesting: I had the String variable logged in the .dat file, so I was able to look at it later. It's appearance in the .dat file was STRING] = "T1'H0D'"
    Note the single quotes inside the double quotes. 'Hxx' is the standard KRL notation for Hexadecimal values, and 'H0D' is the hex equivalent of 13, so my guess is that KRL uses this technique to store non-alphanumeric ASCII characters (like Carriage Return, Line Feed, etc) inside string variables.

    While my code now works, I'm interested in seeing if anyone wants to chime in with their own experiences and/or tricks for handling string variables, ASCII values, and serial comms. It's probably a rich topic for discussion, and I suspect I'll be doing more of this stuff before long.

    hello I am writing sofware for robot communication over RS232 and I want to send messages coded in hex, like sendiing number 33.62 with ESC and STX at the start and EST ETX at the end , should give something like 1B 02 33 33 2C 36 32 1B 03 (without spaces)

    ESC ; Hx 1B
    STX ; Hx 02
    ETX ; Hx 03
    3 ; Hx 33
    . ;Hx 2C
    6 ;Hx 36
    2 ;Hx 32

    I cant try it now on the robot unfortunatelly, but I was thinking about writing something like this:
    decl char val[5]
    val="33.62" ;
    offset=0
    SWRITE(Send[], State, Offset, "%x", val) ;

    or like that
    SWRITE(Send[], State, Offset, "%x, %x, %x,%x,%x", val[0], val[2], val[3], val[4], val[5]) ; (later on parametriazing by loop for i =0 to strlen)

    and then adding ESC and STX and ETX later on.
    Could any of it work?

    Edited once, last by watchcat (November 20, 2014 at 10:40 PM).

    You can do something like this rough code:

    That's very rough, but something along those lines will work. Assigning an integer value to a single-character CHAR variable will encode that CHAR variable as the ASCII character for that value. I've used a variation on this for adding CR and LF on the end of RS232 transmission strings.

    jep later on, I was thinking about it before falling asleep. I will have to do all the ASCII2Intiger converter function and then of course express it in hex.

    It just I have my old backup and then when I added just intiger Kuka showed it like that:

    SWRITE(Send[], State, Offset, "%f %g", $axis_act.a1, $axis_act.a2) ;
    Offset = (( StrLen (Send_Command[])) +1 )
    Send[Offset]=ETX ;
    // output invariable was Send[]="38.627579 -77.7795'H03'"

    And I am not sure if it is sending it with ' and H at the begging? becouse this is what warries me...
    Now I am thinking about something like

    V_ESC = 'H1B'
    V_STX ='H02'
    V_ETX ='H03'
    V_3='H33'
    V_. ='H2C'
    V_6='H36'
    V_2='H32'

    SWRITE(Send[], State, Offset, "%x, %x,%x,%x, %x,%x,%x", V_ESC, V_STX,V_3, V_., V_6,V_ETX ,V_ESC ) ; for "ESC STX 3.6 ETX ESC" ="1B02332C36031B"

    or am I complicating it too much with %x? :] :uglyhammer2:

    The 'H' is not part of the number. 'Hxxx' is KRL coding to represent a hexidecimal number, just like 'Bxxxx' is the binary representation. So 15 = 'HF' = 'B1111'.

    If you simply used Variable=1111, that would be One Thousand, One Hundred Eleven. Variable='B1111' would assign the variable a value of 15 (decimal).

    Using SWrite is going to convert the integer value, regardless of how it is encoded, into a text string. So using SWrite (string[], "%x", 'H03') is going to write a simple integer 3 into the string as a string.

    I have a small example module called Serial located at kuka.skyefire.org where I do this, although I did use decimal integers rather than hex. But KRL should not differentiate between them -- check the .DAT file values for CR and LF to see what I mean.

    Edited once, last by panic mode (November 22, 2014 at 11:37 PM).

    finally I have time to sum up things here so that somebody else might use it.
    Different kind of coding numbers (hex, bin dec) was not a problem for me. I was just worried that the robot could send the mark H before it. But it didn't as you have written. It just sent a numbers so that I could decode it partner device.
    As about code - I made a function to change char into proper digit to calculate checksum, but I was sending chars to the open port as a "%s" type: first by SWRITE, and then into the opened serial by CWRITE.

    temp_data2bsent[j]="7"
    int_data2bsent[j]=ASCII2INT(temp_data2bsent[j]) ;for checksum calculation
    (...) ; rest of the data
    SWRITE(Dane_toSent[], CH_State, Offset, "%s", temp_data2bsent[]) ; make a string

    COPEN (:SER_3, Handle) ; open serial port COM3
    CWRITE (Handle, TX_State, Mode, "%s", Dane_toSent[]) ; send TX string
    WAIT SEC 0.1 ;
    CCLOSE (Handle, CH_State);


    What was strange, I had to add a little delay before closing serial port it because the message was not complete without. In documentation there was structure to check the CWRITE status value on #CMD_OK, but I didn't decide to use it. I could make "wait for #CMD_OK" as it might hang the communication and other values were not significant for me as if the partner device don't receive proper message, the whole communication looped anyway.
    Thanks for help! :smiling_face:

Advertising from our partners