February 22, 2019, 04:20:48 AM
Robotforum | Industrial Robots Community

 Software options for interfacing with KR C4

Author Topic:  Software options for interfacing with KR C4  (Read 314 times)

0 Members and 1 Guest are viewing this topic.

February 12, 2019, 08:24:21 PM
Read 314 times
Offline

Agustin Costa


Hello,

I am working on setting up a robotics laboratory for my company as to test different applications where robotic systems would be useful for the industry, specifically many that require the interaction of the robot with other devices, such as cameras to indicate the position of an object in a bin-picking application or PCs to define new TCPs.

For this I have found three main software option packages which I think may be best suited:
  • KUKA.Ethernet KRL
  • KUKA.OPC
  • KUKA.RobotSensorInterface

I have a KR3 R540 robot with the KR C4 controller with KSS 8.3 and I need help choosing one of these that allows for a wide range of different applications which require communication with external devices. Versatility is the most important factor since I don't want to be locked out of trying some applications because of the interface software.

Thank you  :toothy9:

Today at 04:20:48 AM
Reply #1

Advertisement

Guest

February 13, 2019, 05:42:04 AM
Reply #1
Offline

Jonson


If I were you, I would like to use EthernetKRL.  I think it can help you finish your application.
As for OPC and RSI, I think OPC is more suitable for communicating with PLC, MES or Cloud system. And the RSI is commonly used for real-time application, for example, you want to control the robot motion in real-time.

Hoping this helps.

February 13, 2019, 03:02:21 PM
Reply #2
Offline

SkyeFire

Global Moderator
The KRC4 can support a wide range of communications options, and more than one at the same time.  The key is to choose your remote hardware to be compatible with what you have.

Most industrial I/O uses industrial FieldBusses.  The two high-runners these days are Ethernet-IP (Allen-Bradley/Rockwell) and ProfiNet (Siemens).  These two are widely supported, but are incompatible, and the KRC4 can only have one of them installed.  These are pure software options.

EtherCat, ProfiBus, InterBus, and even old buses like DeviceNet can be supported, by connecting adapter modules to the KRC4's internal EtherCat bus.

EthernetKRL (EKI) is essentially the equivalent of opening a port to a remote TCP/IP server, pushing a string down that port, getting a response string back, and closing the port.  It's extremely flexible, especially if you want to talk to a computer rather than an industrial I/O device, but it lacks the deterministic hard-realtime refresh of the FieldBus options.

OPC I don't have any hands-on experience back, but it seems to fall between EKI and the FieldBusses.  It appears to be widely supported, but you'll need to watch the sub-variants.  IIRC, for example, the KRC4 OPC option does not support OPC-UA, and some devices you might want to connect to might only use the -UA variant of OPC.

RSI is for realtime motion control via external signals, and requires either a FieldBus connection, or a 100% reliable deterministic hard-realtime TCP/IP connection to a remote server application.  It's extremely powerful, but also makes it much easier to break the robot (or yourself), so requires care and skill.  RSI is only necessary to create a realtime connection between an external sensor and the robot's motion model, like applying a specific force against a surface regardless of position.  If you only need to have your program "handshake" with external devices, then RSI isn't necessary.  In fact, outside of its specific specialty, RSI is a bad option to use for I/O.

February 13, 2019, 08:46:45 PM
Reply #3
Offline

Spirit532



I should clarify that generic fieldbus options(interbus, devicenet, ethercat, etc.) are not hard-realtime by default, but you're guaranteed to get the message across.
Good for robust and quick communication, but it's not deterministic.


To OP:
Consider your budgets. Almost all of the software and hardware options from KUKA cost a lot of money, especially if you're buying them after the robot has been configured.
Alternatively, if you're only looking to get some data across without paying a lot(or anything), I recommend looking at KUKAVARPROXY. It's a good option for simple automation, but I wouldn't necessarily use it in a long-term commercial deployment, because it's an unofficial hack that uses an undocumented, KUKA-proprietary Cross interface.

February 14, 2019, 03:47:43 PM
Reply #4
Offline

SkyeFire

Global Moderator
the deterministic hard-realtime refresh of the FieldBus options

I should clarify that generic fieldbus options(interbus, devicenet, ethercat, etc.) are not hard-realtime by default, but you're guaranteed to get the message across.
Good for robust and quick communication, but it's not deterministic.
[/quote]

How are they not deterministic?  In my experience, they all update on a fixed cyclic rate, and anything that would delay a update causes a bus error.
« Last Edit: February 14, 2019, 03:49:29 PM by SkyeFire »

February 14, 2019, 10:48:19 PM
Reply #5
Offline

Spirit532


not[/b] deterministic?  In my experience, they all update on a fixed cyclic rate, and anything that would delay a update causes a bus error.

The data may be updated at a fixed rate, but it can't be utilized by the robot immediately. The robot needs to reach it with a program, which takes an uncertain amount of time.
Somewhat like EthernetKRL vs RSI.

February 15, 2019, 02:18:37 PM
Reply #6
Offline

SkyeFire

Global Moderator
I think we're using different definitions of "realtime", then.

Yes, the program state is always a factor, but the FieldBus input table always updates every X milliseconds, like (literally) clockwork.  And if I ensure my program (often an SPS loop) is cycling faster than that rate, without any potential branches or delays that can push execution time above X, I can generally reliably count on reacting every X milliseconds.  That's how RSI functions, when using FieldBus inputs instead of Ethernet data.

Ditto for Interrupts, or the Fast Measurement inputs.

EKI, OTOH, is potentially completely unreliable for update timing, in exchange for greater robustness dealing with network issues.  It's great for moving big blocks of data whose timing isn't critical.  But you could never run an RSI program on EKI data.

RSI-over-Ethernet, OTGH, uses the same physical layer communications as EKI, but requires absolute timing reliability, just like FieldBus.  RSI is simply created in such a way that it's impossible for the internal cycle of an RSI program to exceed the I/O refresh rate (which puts an upper limit on the number of Objects and Connections your RSI program can have, although I've never seen anyone hit that limit yet).  In fact, the FieldBus timing and RSI-Ethernet timing are on the same clock interval, which should allow a single RSI program to make use of both Ethernet and FieldBus data in parallel -- I wonder if anyone's ever tried that?

Today at 04:20:48 AM
Reply #7

Advertisement

Guest


Share via facebook Share via linkedin Share via pinterest Share via reddit Share via twitter

xx
Fanuc - Software options

Started by WojciechL on Fanuc Robot Forum

1 Replies
1939 Views
Last post January 13, 2016, 11:53:46 AM
by dha
xx
Handling Tool Software & Options

Started by Jacobk243 on Fanuc Robot Forum

7 Replies
1143 Views
Last post March 01, 2018, 04:39:56 AM
by Jacobk243
exclamation
DDRQ software options - roboguide fail

Started by Bobarker83 on Fanuc Robot Forum

0 Replies
179 Views
Last post December 13, 2018, 04:44:44 PM
by Bobarker83
xx
how to install software options PACs on Fanuc Robots

Started by hernari98 on Fanuc Robot Forum

6 Replies
5557 Views
Last post July 19, 2018, 03:57:07 PM
by jbhatt