Software options for interfacing with KR C4

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.

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.

Quote from SkyeFire

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.

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.

Quote from 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.

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.

Quote from SkyeFire

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.

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.

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?

Hi guys, I just wonder that Can I connect siemens s7 1200 with the KR C4 controller, KSS 8.3 via EthernetKRL? Thanks.

Quote from apakrat13

Hi guys, I just wonder that Can I connect siemens s7 1200 with the KR C4 controller, KSS 8.3 via EthernetKRL? Thanks.

1. Does the robot have EthernetKRL installed?
2. Does the PLC support acting as a TCP/IP server?

I've used EKI communications between a KRC4 and a Siemens PLC in the past, but not all Siemens PLCs support that function. Also, the PLC I was communicating with did not support XML, so I had to send my data in "raw" mode. I used comma-separated ASCII, and the PLC parsed variables out of the resultant string.

My robot have EthernetKRL tech and I think PLC have support acting as a TCP/IP cause I saw some videos in youtube which use TCP/IP for send/read data between PLC and PC. Can you give me some example code?
Thanks so much!

Already done - read manual

Has anyone done connect KSS - PLC Siemens via EthernetKRL. I have just use EthernetKRL-Server read from Kss successfully but i don't know config TCP block in PLC. How should i set IP in PLC exactly?