The problem with RSI is that it requires you to communicate with the robot at the robot's cycle time, i.e. 4/12ms. With a Windows system, doing so is generally not reliably possible (some special solutions exist, though). We actually created a client but decided against making it publicly available as errors in communication when Windows doesn't reply in time can even damage the machine, and wrong inputs are generally dangerous. Most of our users who work with RSI developed their own RSI server that takes the data from Grasshopper/KUKA|prc and then communicates with the robot.However, KUKA|prc does support mxAutomation, which uses a buffer and therefore does not require perfect real-time communication. As a consequence, it's also not fast enough to e.g. catch a ball, but you can nicely stream toolpaths over to the robot in a relatively save and reliable way. It's also quite a bit more affordable than RSI.The Grasshopper components for mxAutomation are available to all members, but are not part of the usual download from the member section. The setup of mxAutomation can be tricky, so by making the components only available on demand we ensure that we are in direct contact with all our users.

mxAutomation is a new product and therefore unfortunately only available for KRC4 controllers with KSS8.3+I've attached the manual for the CodeSys version - there is no special manual for the integration through UDP.

I'm stuck with my Plasma Torch Height Control problem, and I think that this topic is the right place to discuss it further because it deals with real-time changes to the toolpath.On this topic : https://www.robot-forum.com/robotforum/kuka-robot-forum/plasma-torch-height-control/ in the RobotForum, SkyeFire talks of the "Function generator" as a precursor of "RSI", which has an equivalent in "Mxm automation"...Ok, lots of fancy names and acronyms, but how does a newb like me get on board ?

From what I understand, MXM automation is not for me because I have a KRC2, so all I have left is "RSI" which costs an arm (how much exactly ?) or the "Function generator" which is some elusive beast for which no documentation exists.

In short, what would YOU do if you needed to alter a toolpath in real time with a KRC2 ?

I didn't see the reference to mxAutomation, it's a bit different from RSI. You can use RSI not only to control the robot in real-time, but it's actually primarily used to offset the tool in realtime, just like you would need it.

How "hectic" is the movement of the plasma torch height control? Because if it does not have to react superfast, my idea would be as follows...

You will need to set the PLASMAOFFSET variable in the sps.sub cyclically from your analogue value, probably with some scaling and safety measures so that it does not move too much.

The robot will read the variable in the advance run, so you will have some delay, and you will need to create toolpaths with very fine spacing to reduce latency.

I haven't tried that out, so it's entirely possible that it won't work. But you might give it a try.

However, my gut feeling would be to simply do that with an external microcontroller. Get an Arduino for 10EUR, a stepper driver for 15EUR and a linear stepper for 30EUR from china, and something so that the analog value coming from the plasma torch does not fry the Arduino. And then plenty of time to set it up

I revived an old topic of mine to discuss this. Maybe it's better to follow-up there.I thought of the Arduino thing, but I'd like to spend the little free time I have learning KRL.To be honnest, KUKA-PRC allows me to do amazing things, but it also has made me lazy in respect to learning the basics of KUKA programming...The "Function Generator" seems a good direction ; maybe in your case, you were spoiled by RSI and skipped this included feature