Automating program upload to KRC4 via Ethernet

    Controller: KRC4

    OS: KSS 8.6.514

    Safety-Interface: X11(but ProfiSafe theoretically available)

    After an exhausting couple of months and visits from the service technician we finally have a working KRC4 and robot arm again. While everything works fine when done by hand (downloading/uploading projects & programs via WoV, executing programs in T1/T2, etc.) the goal of our research project is to automate a robot-based CT scanner. This means that the robot programs we generate need to be uploaded and executed automatically. After bashing my head against the wall for ~3 months regarding connectivity issues I am sufficiently confused and unsure what the best way to go about this is. Should I look to get this working using WoV/LabView/Python/C++ scripts? Do I have to get a PLC and Profinet and use those? Are there other/multiple options? Right now I am mainly looking at the best starting point to continue bashing my head against the next wall.

    In summary:

    1. Is uploading & executing programs "at the press of a button" generally possible using the Ethernet/IP connection (Ethernet KRL 3.1)?
    2. Can I upload program files to the KRC4 and send the command to execute them by communicating via a C++/Python script or LabView?
    3. If I want to communicate via the Ethernet connection outside of WoV then I am forced to use the EthernetKRL server, is that correct?
    4. Is it possible for a separate program/script to make the running server do something s.a. upload a XML file?
    5. What other documentation should I look at apart from the one for "Ethernet KRL 3.1" and "WorkVisual 6.0"?

    Any feedback on the matter is much appreciated. I will gladly dive right back into the documentation but would like to start by looking in the right place if that makes sense.

  • Go to Best Answer

  • Nation February 23, 2023 at 6:20 PM

    Approved the thread.

    1. uploading = NO. executing via "single button press" = YES if using EXT mode. uploading requires additional software (DirectoryLoader and EXT mode)

    2. This is possible but requires additonal software (Directory Loader) and using EXT mode. the other option is to use C3Bridge Server on the robot and develop suitable client.

    3. No... communication with robot is possible without WoV or EthernetKRL. One can do that using OPC or RSI etc.

    4. Not sure what you mean... you can use web browser to transfer some file to/from some server on the internet. you can use file explorer to transfer some file (XML or whatever) to/from another drive. what is the point of this?

    5. check out the READ FIRST thread.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Thanks so, so, so much! :grinning_face_with_smiling_eyes: :grinning_face_with_smiling_eyes: :grinning_face_with_smiling_eyes:

    I had no clue there was an option package just for uploading modules to the controller, I expected this to be included with any networking package.

    With "Directory Loader" as a keyword I managed to find a lot of the necessary info on how Kuka handles networking with external devices and what is required. This basically answered all of my questions.

    The project finances are stretched thin right now so we try to avoid paying 2k€ for the Directory Loader. :kissing_face: For now we decided to take a look how much development work C3Bridge would mean for our application. In the meantime I also found out we might be able to make do with RoboDK's online programming capabilities. For the research project the focus is to show that certain path planning methods are working, so as long as we can generate, send & execute our code remotely we don't need to upload anything.

    Quote from nicok

    Is uploading & executing programs "at the press of a button" generally possible using the Ethernet/IP connection (Ethernet KRL 3.1)?

    Note: Ethernet/IP and EthernetKRL are separate entities, despite (usually) operating over the same physical ethernet port.

    Neither one supports uploading programs. The DirLoader option package from KUKA allows the robot to delete a local subdirectory of programs, then "pull" replacement files from a mounted drive (most often a network share). It does have some particular rules that need to be followed, but works.

    Quote from nicok

    Can I upload program files to the KRC4 and send the command to execute them by communicating via a C++/Python script or LabView?

    Not exactly. To actually load a new KRL program automatically requires DirLoader. However, there are alternate approaches. For example, build a permanently resident KRL program in the robot that includes a very large point array in the .DAT file. It would be possible to write a KRL program that would communicate with a PC (requires using EthernetKRL for the socket-layer communications), and accept data to rewrite the array. The robot-resident program could also accept commands to start/stop via EthernetKRL.

    Quote from nicok

    If I want to communicate via the Ethernet connection outside of WoV then I am forced to use the EthernetKRL server, is that correct?

    Ethernet is a cable, not a protocol. The KLI port on a KRC4 can support Ethernet/IP XOR ProfiNet, in parallel with EthernetKRL, file transfer, remote desktop, etc. Much the same way a typical Windows PC can support HTTP, Remote Desktop, SMB, FTP, and other connections all in parallel over the same network connection. It's also possible to use EtherCat, as an extension of the KRC4's internal system bus.

    There are also options for using OPC/UA, and there's the open-source OpenShowVar, which is not supported by KUKA, but some forum users have had luck with.

    You can communicate with the KRC4 using any of these protocols, as long as you can handle that protocol on the PC end. EthernetKRL is required to perform "socket" communications, which is basically passing strings as if you were using a Telnet session.

    Quote from nicok

    Is it possible for a separate program/script to make the running server do something s.a. upload a XML file?

    Depends. It's possible to make a HDD directory on the robot network-writeable and then share it using typical SMB. You could write ASCII files to that. Then send the robot a command that would trigger the robot to open that file and read data from it (look up the krl_fgets command in the forum archives). KSS 8.3 natively supports reading/writing ASCII files, though it's a bit clunky.

    I would not recommend using XML this way, that would simply introduce extra unnecessary parsing. CSV would be more practical. EthernetKRL is tailored to transfer XML-formatted data, but not files.

    Quote from nicok

    What other documentation should I look at apart from the one for "Ethernet KRL 3.1" and "WorkVisual 6.0"?

    WorkVisual isn't really relevant to this discussion. It's a configuration and debugging tool, and can't really be used (AFAIK) for automated program loading/altering in production.

    EthernetKRL is probably the easiest for doing basic Telnet-esque socket communications between a KRC and a PC. It can handle XML-formatted data, basic ASCII strings, or raw binary. It will work with the basic "socket" libraries in major programming languages, you just have to ensure you format everything the same way on both ends.

    The industrial busses (Ethernet/IP, ProfiNet, EtherCat) can be programmed on the PC side, as I understand it, but I'm not sure what the learning curve is, or what the licensing is like.

    OPC/UA might be a good middle ground -- AIUI, there are open OPC/UA libraries, and KUKA offers an officially supported OPC/UA option package in the robot.

    There are details to keep in mind here: the industrial busses (Ethernet/IP, ProfiNet, EtherCat) have system level access to the KRC4 -- they can be directly linked to system variables, fire direct commands like Drives On/Off, Start/Stop, and (optionally) handle Safety-rated I/O.

    EthernetKRL, by contrast, is application level -- it exchanges data, but cannot directly control system-level resources in the robot. There are some workarounds for this, but I'd avoid the added complexity. EthernetKRL is often better than the Industrial busses for moving lots of data around, however.

    DirLoader is a system-level KUKA option that allows actual executable KRL to be deleted and replaced. EthernetKRL cannot do this.

    For example, a KRL module might include a .DAT file with a position array defined as 100 in size. The values of each member of that array can be rewritten from the application level, using data from any communication channel. But the .DAT file structure is immutable -- if you want to change the array size to 200, you would have to hand-load an updated KRL module, or swap the current module with a new one using DirLoader if you need it to happen in an automated fashion.

    The best working example I can give you from my own experience was drilling/riveting large airliners, using motion programs generated from simulation software. It worked like this:

    1. The robots had a set of permanently-resident KRL modules that handled actual operations

    2. DirLoader was used to swap the huge KRL modules containing thousands of motions commands in/out of the robot. This was necessary b/c the files were so large that the robot could not contain all of them at once. The airplane was broken up into "sections", where each section program was small enough to keep loaded into the robot alongside all the "operations" code. DirLoader loaded and "compiled" the new KRL modules to make them executable.

    3. The "operational" code from #1 acted as "middleware" between the swappable modules and the permanently-connected hardware, and the system resources.

    4. One "middleware" operation was to extract data from the swappable modules and pass that data to the production-line level control system using a combination of Ethernet/IP and Ethernet/KRL. For example, at the engineering/simulation level, certain drill/rivet points might be moved, added, removed, or renamed. The KRL module output from the simulation software carried that information down to the robot, which passed that information to the production line computers and PLCs.

    5. Robot system-level control (Safety, Drives on/off, start/stop, handshaking with hardware) was handled via Ethernet/IP. Transfer of large blocks of data was mostly handled via EthernetKRL, although it varied depending on what the robot was trading data with. On some PLCs it was easier to just bit-bang data using Ethernet/IP.

    6. Ethernet/IP was also used to trigger the DirLoader operation. The plant/line level controls tracked when the airliner was moved, or the robot was relocated to a new section of fuselage, and would trigger the robot to run the DirLoader. The big motion programs were stored in a common network share, and overwritten using the same file names. So the line-level controller had to erase the network share and then load only the correct KRL modules into that network share, before triggering the robot to do a DirLoader cycle.

    I should ask: are you aiming for smooth continuous motion along a complex path, or a discrete start/stop at every scan point?

    Because the latter simplifies things quite a bit. It would be entirely possible to write a simple loop program that would ask a PC (via EthernetKRL) "where do I move next?" and get back a set of coordinates, then execute. The program could be shorter than the EthernetKRL config file.

    If you need smooth continuous motion, things get more complex, because the robot needs to have the current point, plus the next 1-5 points, already in memory (depends on the $ADVANCE value) in order for the Advance Run Pointer to plot a smooth motion path. Basically, to have a smooth unbroken path from A->B->C, the robot has to have the coordinates for B and C before it leaves A. (I'm obviously eliding a lot of complexity here).

    Quote from nicok

    I had no clue there was an option package just for uploading modules to the controller, I expected this to be included with any networking package.

    So, this has to do with the fact that KSS's core functionality is pretty old, and predates the concept of dynamically swapping modules in/out of memory. The DirLoader is a slightly-clunky band-aid to cover that gap.

    Short version: whenever a KRL module is loaded into the robot, it undergoes a "compile" (more of a syntax check, really) and "link" cycle, where every call is evaluated for validity. In fact, when a KRL module is loaded or deleted, all the modules in the robot are put through this cycle. If you delete a dependency, every module that depended on it will be flagged as having illegal calls immediately -- it doesn't wait until runtime. If you copy&paste a bunch of KRL modules at the same time (you can try this with a USB drive), each module gets loaded one at a time, triggering a compile/link cycle for each one. This means that doing a "group load" will throw a bunch of temporary errors (if they have interlinking dependencies), until the last module load/compile/link. And when "group loading", KSS loads them in alphabetical order.

    This works fine if you're only loading/unloading modules manually. However, doing it automatically adds several wrinkles. Especially since breaking a dependency causes the robot to stop running, which would cause the DirLoader to stop running, which... Catch-22 time.

    So, the DirLoader basically emulates an operator doing a manual load of KRL modules, and to avoid errors, does it one at a time, in alphabetical order, and does some temporary commenting-out of calls in CELL.SRC. DirLoader was basically created to automate module swapping with the absolute minimum changes to the underlying, well-proven and certified, KSS structure. This has the side effect of DirLoader having some very specific limitations, and some very special rules that need to be followed (for example, we had to name our modules such that the alphabetical loading would load the lowest-level dependencies first, and work "up from the bottom"), and to someone from the PC/IT world, it looks primitive and clunky. It does work, and quite well, but you have to respect its requirements and limitations.

    Thanks for the extensive explanation.

    Quote

    I should ask: are you aiming for smooth continuous motion along a complex path, or a discrete start/stop at every scan point?

    In a perfect world we'd only need discrete start/stop motions as the basic task for our CT scanner-robot is to: 1. move to pose, 2. wait n milliseconds, 3. take CT image, 4. move to next pose and repeat. Unfortunately, due to our huge tool dimensions (~2m long metal arch with X-ray source & detector at the ends) we need to account for oscillations which means we will need to control the deceleration.

    I guess we might be able to approximate a "quasi-continuous" end of our path with discrete start/stop motions by dividing the last part of the path into a handful of points and use PTP motions with the desired deceleration. But I am not sure how "choppy" the motion is that could be generated with this approach.

    • Best Answer

    Accel/Decel control is separate from continuous motion. Indeed, from what you describe, you don't want continuous motion. Your application is more like spot-welding than spray-painting.

    For KRL motions:

    Code
    PTP P1 C_PTP
LIN P2 C_DIS
LIN P3 C_VEL

    The "C_" suffixes activate different types of motion continuation. That is, with that program, the robot would move from P1, through P2 without stopping, and through P3 to whatever is after P3, again without stopping. There are entire sections of the KRL manuals that cover this in detail.

    But for a "spot welding" type application, where the robot needs to come to a complete halt at each point, you would want to eliminate the "C_" suffixes:

    Code
    PTP P1
LIN P2
LIN P3

    With that program, the robot would come to a very brief but complete halt at each point. You would probably add I/O commands to trigger the CT scanner at each point:

    Set $OUT[1] to tell the CT scanner to fire, wait for $IN[1] that the scanner is done, turn $OUT[1] off and wait for $IN[1] to also turn off before moving to the next point (that "full handshake" ensures there's never any signals "left on" going from one point to another). Lather, rinse, repeat.

    Acceleration and Deceleration are a single setting that controls how the robot ramps its speed up/down when leaving or approaching a point. For PTP moves, it's axis-based. For LIN moves, it's three settings: linear acceleration of the TCP along the path in m/s^2, and two orientation accelerations controlling how fast the TCP rotational velocity changes.

    Then there's SPTP and SLIN, which have their own equivalent settings, but I haven't toyed with them much. Newer KSS versions (8.4 or 8.5 and later) default to using them, and the "classic" LIN/PTP are being slowly phased out. There's a packaged "helper" routine, BAS.SRC, that makes it a lot easier to adjust the speed/acceleration settings just by calling it with the parameters you want to set. Hand-taught points on the pendant, using Inline Forms (ILF) make heavy use of BAS.

    I should note that once these settings have been adjusted, they are persistent until changed. But ILFs "bundle" an entire set of parameters (speed, accel, approximation, Tool/Base frames, etc) into every "move command". So for "raw" KRL programmed without ILFs, you can simply set your speed/accel/etc at the start of the program and forget it, but mixing ILF moves with "raw" KRL moves needs to be managed carefully.

Advertising from our partners