Advertising

Posts by SkyeFire

    For a KRC2, your best bet is probably the RS232 port, streaming the data to an external device. The forum archives have many previous discussions of this topic.


    Since the robot's internal Cartesian data only updates every 12ms (ignoring IPO-FAST mode in RSI), and the SPS can loop faster than that, using a $TIMER to limit the transmission to once every 12ms would probably be wise. That also helps avoid any potential buffer overflow issues.

    Wait, Profinet or Ethernet/IP? Those are two completely different protocols, and cannot co-exist on a KRC.


    What options was this KRC-4 ordered with? Which options are installed? If the robot was originally ordered with ProfiNet and ProfiSafe, it won't have an X11.

    LIN_REL will rotate around the TCP, but use axes parallel to those of $BASE. LIN_REL #TOOL will rotate around the axes of $TOOL. But in either case, the point being rotated around will be the current location of the TCP.


    To answer your question, first we need to know: Do you want to rotate around a fixed point in space, or around a point "attached" to the robot wrist (similar to the TCP?). For the latter, as Panic says, simply creating a new TCP and rotating around it is the simplest approach. For the former... well, it would depend on the details, but one quick&dirty method might be to set that fixed point as the active Base, record $POS_ACT_MES, then rotate $BASE around its own axes and execute a move to the recorded position.

    VW? ...ugh.


    It's been years since I was involved with VW. And I don't have any documents handy.


    What I can recall of the VW programming standard:

    1. All robots must be programmed in the vehicle coordinate system. This actually makes sense, but means that you have to take extra care in your base/frame setup at the start. It can get a bit tricky with pedestal-welding robots.

    2. Every Pick/Drop operation sets a trigger condition that monitors the status of the part-present sensors on the end effector. For example, after picking a part, this monitor condition will throw a fault if any of the part-present sensors go false, until the monitor condition is formally shut off at the Drop operation.

    3. As of ~10 years ago (about the time VW was switching from KUKAs to Fanucs) they were still using optical Interbus-S for all their I/O. And setting up the communication required the configuration software tool from Phoenix Contact

    4. VW is obsessive about adherence to their standard, even when it doesn't make any sense. Also their record-keeping -- they want a master copy of every Interbus setup file generated from the config software, for each robot, for example.

    Nachi definitely appeals to the lowest-cost mindset. And for dead-simple applications, it can even work out. But beyond the simplest of applications, in my opinion you'll start paying for that up-front savings in back-end frustration and technological struggles.

    The "Drives contactor off" is not an error, just a status. When you enable the deadman, that error should go away as the motors energize.


    The "Safety Circuit not ready" message is odd -- I would expect that to happen alongside an E-Stop or Motion Enable error.


    The "Porigion" error I'm not familiar with.


    The DNDRV error could be related to your motion issue -- check the setting of $MOVE_ENABLE. You may need to change it to 1025 (the "always true" input) until you have your external I/O working.

    What is the exact error number and text?


    What motion type is being executed when the error occurs?


    Does the error happen at the start of a motion, or partway through? Is the robot stretched out or posed strangely when the error occurs?


    You said you are shifting paths -- how? Are you altering point data, tool data, or base data?


    Usually, the "Workspace Error", as Fubini says, indicates that the robot has been programmed to move to a point physically outside of the robot's reach -- like, a point 3m from the base when the robot's arm length is only 2m. However, I usually don't see it during LIN motions, only PTPs. That's because PTPs do a "pre-check" of the destination, but the LIN motion usually doesn't -- it just keeps moving towards the destination until it hits an axis limit. Similarly, LIN motions generally ignore the S&T values of the destination point -- or, more correctly, they subordinate the S&T in favor of maintaining the linear path motion.

    That suggests you have a power supply issue internal to the robot.


    However, the LBR is a sufficiently unique system that just using the KRC2 rules/jumpers may not work. I think you may need to contact KUKA tech support on this one.

    Simply: use safety-rated interlocks to ensure no human can ever come within the robot's reach unless the robot is either de-powered, or is limited to a safe operation mode (either Collaborative mode, or restricted to Teach mode with the deadman enabler required).


    Allowing the robot to automatically move after a collision would violate RIA safety specs, since there's no way to sufficiently ensure that that movement wouldn't make things worse.

    Ran into something interesting. I've recently spent some time on a KRC4 (KSS 8.5) that uses EKI 3.0.3 to communicate with a "streaming" data system. The unique (for me) parts of this setup were that the protocol was UDP, and the robot was acting as a server, not a client. All the communications were being handled from inside the SPS, as well.


    One of the issues I was asked to fix was that the "Alive" flag would not go False if the KLI cable was disconnected. The Channel XML file had no Ping setting, so I added one with a short delay, but that had an odd side effect: the Alive flag would never go True when I executed an EKI_OPEN. If I removed the Ping setting from the Channel file, everything worked as expected.


    The EKI manual includes very little detail about the Ping, but if I had to guess, I'd say that Server mode and Ping interact negatively. Or, there's a trick to using them together that I haven't figured out.


    I solved the problem by removing the Ping, and setting up an SPS element that monitors the Received flag and throws a fault if that flag doesn't change state for a few seconds. Since the remote system is sending data several times per second, this appears to work as intended so far. But I found the Server/Ping interaction curious enough to mention it (and hopefully help the next poor soul who encounters this).


    Sadly, I don't have any more time with this robot to really dig in and experiment;(

    I'm having an issue with mounting an Agilus -- specifically, a KR10 R1100. My Agilus documentation has a dimensional drawing for the wrist flange, the supplementary load mounting points, but nothing for the actual mounting of the robot to the floor.


    The manual shows a "Mounting Base" (a plate) that the robot should mount to, and the manual shows a bolt pattern for mounting that base to a concrete floor, but not for the bolt pattern mounting the robot to the plate (that hole pattern is shown, but not dimensioned). It looks like KUKA's intent is that the Agilus should only ever be mounted to this KUKA-supplied plate, but I didn't get that plate. And the drawings don't provide enough data to create the plate from scratch.


    On all the "big iron" KUKAbots that I have (lots of) experience with, the bolt hole pattern was provided in the documentation, with enough data to create an entire mount from scratch. So, anyone who has more experience with Agili than I do -- am I missing something? Should the plate have come with the robot, or is it a separate purchase item? I did receive a box of bolts that match the manual's description of the bolts used to mount the robot to the plate... but no plate to use those bolts on.

    I'm pretty sure this is not possible, and deliberately so. Even limited to Playback operation, RSI can be very hazardous -- for one thing, it bypasses/overrides the T1 250mm/s speed limit. Having RSI active while jogging strikes me as just begging for someone to be harmed.


    ...Hm. There is one possible exception, but it's a special case: the "joystick on EOAT" package (whose formal name escapes me) uses RSI as a foundational element, I believe. But since I've never used that option package, I can't speak to it with any authority.

    I think I was able to make this work several years ago, by diving into the KRCConfigurator program and messing around. It was, IIRC, under the Methods tab.


    But that was several KSS versions ago, and I've never seen a detailed manual for that part of KRCConfigurator, so you'd probably have to trial-and-error it. Make sure to take backups before you start.

    I personally have a very low opinion of Nachi robots. Some people like them, but even they mostly agree that the controller is rather primitive and not very friendly for doing advanced programming on.


    For very simple tasks, it's sufficient. But that's the highest praise I can give it.