Advertisement
Guest User

Untitled

a guest
Jun 4th, 2017
363
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.87 KB | None | 0 0
  1. OK, so, having already been down this road you're about to drive on... let me offer you a not-so-objective opinion...
  2.  
  3. KRC1 is a complete pain to interface with a PC. There's a good chance you will wish you never attempted this, and wish you had spent the extra $$ on a much newer KRC4 robot. My application required control of the robot in real time by simply sending it joint angles or XYZABC positions over RS232 and let it chase it, and send me back the current position. On the PC side I'll know when the robot reaches the position by comparing target/actual. Simple enough, right? No. Not at all, a thousand times no.
  4.  
  5. The code on the robot controller isn't impossible to write (using SREAD and SWRITE). I connected a RS232 cable to a computer on top of the robot controller, then wrote a bridge that translates the serial port to TCP. Voila, KRC1 over ethernet! Not so fast, I created subprograms to read and parse the data coming across the wire. Sometimes the controller will complain about them having errors. Then you open and close them in a magical sequence and suddenly it's happy. Until you reboot it.
  6.  
  7. No problem, rewrite the program for the 43rd time to not use subprograms. Sometimes it reads data at a predictable speed. Sometimes it does not. Don't forget to include some kind of recognizable delimiter in your communication, because sometimes it only reads some of the data, and your joint position array is off by one, and suddenly you have a giant robot that pile drives itself into the floor. At this point, once that is all sorted out, when all the stars seem to be lining up, you get your program running, it receives coordinates correctly and chases them, then all of a sudden it stops reading data from the serial port and you get some weird random buffer errors that can only be cleared by restarting the program. Sometimes your "serial port handle" will get stuck open so your code will need to deal with that scenario on startup.
  8.  
  9. Now that you have a glimpse into a week of my life that I can't get back, here are the 2 strategies I can recommend:
  10.  
  11. 1) Generate your KUKA programs on the PC and transfer them to the robot. You can set up file sharing in Windows 95 and connect the robot up to your network. One word here - KRC1 does not allow you to copy programs directly into its active /programs folder. You must copy it somewhere else on the C:, make sure the teach pendant is in expert mode, and copy/paste the programs into the right spot on the teach pendant, because KRC1 needs to feel special about it and compile the program as it pastes in. If you are doing some milling type work then make sure each of these files does not exceed 100k or so in size.
  12.  
  13. 2) Use a PLC + DeviceNet or some other supported card in your KRC1 to transfer your position data/command via registers. KRC1 likes registers.
  14.  
  15. 3) Just buy a KRC4 robot with the right control comm package and save your sanity.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement