How to operate a KRC1 controller

    I'm getting ready to purchase a KR150 robot with KRC1 controls and I'm currently researching ways that I can control the arm without needing to rely on the pendant or internal PC to program it. From what I can tell, the PC included within the control box is very outdated, underpowered and difficult to program. It is necessary for me to be able to connect a more modern PC to it and send it commands remotely, or at the very least be able to easily transfer programs to the controls from a more modern offline programming tool.


    From what I have gathered so far from various manuals and forum posts, the standard way to do this on the KRC1 is via the RS232 serial interface. However, I am having trouble finding any information about HOW to do this. To be honest, I haven't owned a PC with a serial port for many years, so my knowledge of using it is zero!


    Can anyone point me to some good resources about how to connect to my KRC1 via RS232 (or any other real-time-ish interface) so that I can control my robot?

    OK, so, having already been down this road you're about to drive on... let me offer you a not-so-objective opinion...


    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.


    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.


    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.


    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:


    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.


    2) Use a PLC + DeviceNet or some other supported card in your KRC1 to transfer your position data/command via registers. KRC1 likes registers.


    3) Just buy a KRC4 robot with the right control comm package and save your sanity.

    I would love to "just buy a KRC4" bot, but I will likely not amass that amount of money in my lifetime :winking_face: I'm only considering this project because I came across the KR150 + KRC1 package for an extremely low price, and will likely not find any alternatives. I am a DIYer, not an industrial or manufacturing person, so I do not have the budget to spend on upgrades, special tools or fancy software. This is more of a fun hobbyist project that, if successful, could lead to some non-traditional revenue later on down the road (months later).


    In a perfect world we will be able to locate a used KRC2 controller to upgrade to in the future, but we do not have more than about $5-6k on getting our system up and running. Granted, our applications are purely experimental and creative in nature and therefore are (hopefully) nowhere near as demanding as industrial/manufacturing applications, but we nonetheless have non-trivial challenges ahead of us.


    So it sounds like what you are saying is that the horrendous PC specifications cannot handle typical, well-formed serial messaging very well. It sounds like its advisable for me to implement lots of handshaking and checking, as well as keeping my baud rate nice and low (or at least artificially limiting the speed of my communications). I actually may not mind having my bot move between points slowly, so long as it does in fact move through the points I tell it to! Your limited success is still success, and is actually somewhat encouraging for me :smiling_face:


    I fully anticipate, and even welcome, spending several months working on developing a way to control my bot the way I want - so long as there is in fact SOME way to do it! I ultimately would love to implement a KUKA port of the Robo.Op framework (which interestingly sounds very similar in approach to what you described), but I must gain a relatively intimate knowledge of the machine's normal operation beforehand.


    The PLC + DeviceNet route sounds worth investigating, though I do not have any experience with either technology, so I will bookmark that rabbit hole for a rainier day.

    If you do get serial communication working, please do post the solution. I abandoned the approach after realizing that KRC1 simply does not do serial communication well. You can do everything 100% right, with the most beautifully structured serial protocol the world has ever seen, and the controller will randomly produce some kind of weird error that you don't even have the tools/commands to get around and recover from in the KRL program. It's disappointing and frustrating when you realize you can't get around things that are beyond your control. Maybe I didn't go slow enough, dunno.


    IMO the best approach would be to take the things that it does do well (basically reading registers on really old industrial protocols, i.e. DeviceNet), and make the most of it. I so wish it were easier just to rip out the Kuka controller altogether and control the servo drive positions directly; to me that would make this generation of robots really fun for these types of projects. Oh well... good luck.

    I'll weigh in: "bypassing the pendant and internal PC" means, in effect, bypassing thousands of man-hours of software engineering and quality-control testing. And there's no way to do that without spending similar amounts of man-hours.


    Remotely "puppetting" the KRC1 through an external interface is still going to require nontrivial amounts of skilled KRL programming to act as an interface between your external PC and the KRC1's internal control system.


    The RS232 interface is not really well-suited for realtime control. I've seen people do some quite amazing things with it, but these days, the skills and knowledge are going to be hard to come by. As X9 said, you're far better off sticking to a dedicated hard-realtime I/O scheme like DeviceNet, which won't be cheap, but will probably save you far more in time, blood, sweat, and tears than it costs. Plus it already has a deep history of reliability to industrial standards.


    If remote realtime control is truly what you desire, your best bet would be RSI, but I don't think you can get than in anything earlier than mid-generation KRC2s. On a KRC1... with a FieldBus I/O package, rather than RS232, you might be able to do something hybrid with the Function Generator, but that would take some work. It's possible, but the FG has some limitations and was never deeply documented.

    I certainly don't mean to diminish the work that was put into the product, but given the difficulty that users such as x9tech have had and the less-than-graceful way it has aged, I couldn't say for sure that all of those thousands of man-hours necessarily resulted in an intuitive, well-designed system (especially from a UI/UX perspective). For people who can afford for premium support and full-time on-site dedicated technicians that's probably not an issue, but for researchers and experimental users like me that presents quite a challenge!


    I should be clear in saying that every application that I can think of for my robot could probably be achieved using only the PTP command and whatever others needed to satisfy the systems built-in requirements (setting up zeros, variables, etc). I don't see myself needing to remotely puppet things like I/O, toolheads or anything fancy, just basic PTP control - everything else I can handle myself through custom equipment :smiling_face:


    If I can establish simple serial control, perhaps I could write a program on the KRC1 that maintains a queue of commands (10-20), which it will consume and execute as it is able to, requesting new commands to "top up" the queue from a remote source. That would obviously introduce a delay, but would allow me to stream larger toolpaths and do some rather interesting interactive behaviors, I think.


    I will contact my local KUKA rep and see if he can point me to a path to get reliable communications going, hopefully there is some insight he can provide given his experiences.


    I am VERY open to picking up a KRC2 in the future, especially if that would definitely allow for easier real-time(ish) communication. Is it possible to pick them up used for under $10k? Under $5k? Any dealers or auction houses that this community respects that I can go to?

    Quote from DomoArigato


    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.


    I'm using the same type of application using RS232, my question, How to send the XYZABC positions?

    Just a word of warning here: the RS232 interface on a KRC1 is much less reliable than any of the included "real" field bus options. Loulli's code absolutely looks like the first time anyone's done this properly in a public HOWTO, checking whether the incoming position data makes sense and so on, so it should prevent the robot from - let me quote someone on this forum when this topic came up before - piledriving itself into the floor at full speed, but reliability is still going to be an issue with the robot just stopping or skipping commands when RSR232 decides to randomly drop a byte and garble up the data.


    Loulli any plans for adding error feedback to allow for retries? Also, have you tried external control over DeviceNet?

    Hallo enleth,


    I do not agree. The RS232 communication is reliable if you use the 3964r protocol and send data in binary format rather than strings.

    I transferred 1000 of points without any problems.


    Using XON/XOFF protocol was mainly used by serial printers


    regards


    MOM

    Thanks! This is one of the situations when I'm happy to have been wrong - because if I hadn't posted, I wouldn't learn something new from your response.


    With that and Loulli's code, it should be possible to get a reasonable RSI-like interface for (V)KRC1.

    @enleth. Sorry for the late reaction, so far I hadn't found out how to get notifications at new thread entries. I hope this works now after selecting "Watch this thread".


    So far I haven't added any error feedback or retries, but you are right that we should. As I use the robot more like a hobby I don't know however if this will ever get a sufficient priority. Regarding DeviceNet I was not aware I could use it also to transmit positions.


    Currently I'm working on detecting bottles with a webcam, a Raspberry Pi and OpenCV. I'm planing to send the detected position via WiFi to a Raspberry Zero relaying to the serial interface of the KRC1. So far the tests look promising. Priority will however be, checking if the detected positions is allowed in order to avoid "piledriving into the floor at full speed". :smiling_face:


    All progresses will be published on my homepage, so stay tuned. :winking_face:

Advertising from our partners