Hello KUKA Robot Forum,
For an internship, I am researching and developing a proof of concept of a new way of communicating with KUKA robots (KRC4/5).
Currently, a robot program (.dat, .src) is generated by external software and send to the robot and executed. This doesn't give much flexibility because you can not change the positions while it is running etc. Also, we could use the time while it is running to make more complex calculations for next positions, because we want to minimize the waiting time before it can start.
So I am looking for a way where I can control the robot more directly/real-time.
I looked into RSI, but that is too low level for what we want, because of safety concerns we want to use KUKA's boundary checking, acceleration, etc.
PLC mxAutomation does seem to offer the flexibility I want, but means that I need to build the controlling logic with PLC's and I would like to implement all logic in a C++ program. And I am not sure if and how that is possible with PLC mxAutomation (My PLC knowledge is very limited).
I also looked into some other packages like Ethernet KRL and deviceconnector, but they don't seem to allow me to set robot positions.
Below is a quick summary of the requirements.
- I want to use KUKA's software on the robot for acceleration, deceleration, boundary checking, PID, path smoothing, etc.
- Turn on/off etc. of external tools.
- Communicate with robot from a C++ exe over Ethernet.
- Add new positions of robot and external axes while running.
Ideally there would be some API that allows me to send new positions from my software and the robot then puts them in some kind of queue so it can do its thing with it. What would be a good way of achieving this?
I am unsure about what to do with turning on/of etc. external tools, setting speed, movement types, accelerations etc. Maybe I could set those global vars, but that would mean my software needs to know when the robot going to move to a new position from the queue and at the right moments set the global vars. Timing wise, that doesn't seem feasible. Tips for an alternative approach of handling that?
Please let me know if you need any additional info! Thanks in advance.