Welcome, Guest. Please login or register.
Did you miss your activation email?
May 23, 2012, 07:05:37 PM
Home Help Login Register
News: Any Problems or Experience with Industrial Robots ?
Register and place your Question / Answer to worldwide Robotexperts right here !

+  Robotforum | Support for Robotprogrammer and Users
|-+  Industrial Robot Help and Discussion Center
| |-+  KUKA Robot Forum (Moderators: Werner Hampel, Martin H, SkyeFire)
| | |-+  ASCII Characters and string variables
0 Members and 1 Guest are viewing this topic. « previous next »
Pages: [1] Print
Author Topic: ASCII Characters and string variables  (Read 1176 times)
SkyeFire
Global Moderator
*****
Offline Offline

Posts: 1784



« on: February 03, 2009, 07:20:39 PM »

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:00Psv9x_Sb0J:www.robot-forum.com/robotforum/kuka_robots/trying_to_communicate_with_an_omron_vision_system_using_serial-t857.0.html+kuka+serial+%22carriage+return%22&hl=en&ct=clnk&cd=4&gl=us&client=firefox-a
and
http://www.roboterforum.de/roboter-forum/kuka_roboter/keyence_machine_vision_x_kuka_robot-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.

Logged
Pavel_Yakubov
Newbie
*
Offline Offline

Posts: 8


« Reply #1 on: October 23, 2011, 08:37:52 PM »

It is really interested for me! I plan to use KUKA with the camera together. Thanks for the info.

But I will have OMRON camera (not KEYENCE). It is the same or not?
« Last Edit: October 24, 2011, 02:00:42 PM by Pavel_Yakubov » Logged
py_programmer
Newbie
*
Offline Offline

Gender: Male
Posts: 12

Robot programming is so 80's!


« Reply #2 on: February 03, 2012, 09:45:33 PM »

This is the way it works in C. Chars are just 8 bits. If you read the same 8 bits as an INT, you get a number.
Logged
Pages: [1] Print 
« previous next »
Jump to:  


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!