Posts by SkyeFire

    But now the part, where I am currently struggling with: I don't exactly know, what the next steps are to get for example the actual position data of the robot and further proceed this data in twincat or in general see some data from the robot in twincat. Maybe you can give me a hint how to proceed on from my current situation.

    Well, to start with, what signals have you mapped in WV? Whatever $OUTs you have mapped to the PLC, if you force one on from the pendant (teach mode, deadman held, motors on are prerequisites), you should see the corresponding input on the PLC change state to match.

    Likewise, whatever the first PLC output you mapped in TwinCAT to the robot, if you force it on in the PLC, you should see the corresponding $IN on the robot change state to match.

    I know this is going to be a useless comment but i am going to mention it anyway, but i have 3 robots where the gates need to be closed to move in T2. so it used to be possible. These robots are not the newest that you can find (kss 4.7) so i know that it is not really relevant for this case. But when i was reading this post i was wondering if somewhere the safety standards where lowerd? or was kuka more strict back then?

    As Panic said, that would have been an implementation detail. Generally done via external safety relays generating the enable signal (on that generation, probably the X11 $MOVE_ENABLE) as (T1 OR Safety Gate).

    Some of the VW controllers might have done this using safety relays added internally to the KRC, but the ones I recall working on had all safety logic external to the KRC.

    It's not KUKA. KUKA provides robots with T2, or without T2, depending on customer preference. Customers who buy T2-Enabled robots are free to limit T2 in any way they desire. There are conditions where being able to operate the robot in T2 while close to it is necessary. For any system set up that way, the rules keeping anyone without a deadman outside the cell when the robot is in T2 need to be rigorously enforced.

    As I understand it, KUKA's implementation of EtherCat is only compatible with a small subset of ECat devices. It used to be that only a small number of specific Beckhoff modules were approved for use connected directly to the KRC's internal ECat bus.

    I think that list has expanded over time, but I don't think the KRC can work with any standard-compliant ECat device the way most PLCs can.

    Was that a KUKA factory option? If so, that might let CJ get an accurate internal wiring diagram.

    Then, the bigger question would be, how feasible is it to remove that card and go back to regular X11 safeties? Or would they be better off just buying the Pilz safety PLC?

    Can you get a better shot of that card? I have to say, I've never seen that before, but the label (blocked by a cable in your photo) seems to say "safety I/O." And those dials look like something for setting an address, but with only two dials, it would seem to be limited to 0-99. That doesn't match any safety bus/network device I can recall ever seeing.

    Where does the yellow cable(s) go to? The shape looks like ProfiBus, but the color is non-standard (probably because it's a safety bus -- non-Safe PB is normally purple). I assume the yellow cables lead out of the cabinet.

    Bottom line: that card is an add-in. It's not one I've ever seen, but it could be a KUKA factory option. OTOH, it could be some 3rd-party add-in.

    I think the key is going to be the cable marked A1.1/X1. I'm betting that cable connects into the normal internal safety wiring of the KRC somewhere. If you can find that location, I'd bet that your regular KRC wiring diagrams would be correct from that point.

    Does that card have any other cables connecting into the KRC internals?


    I've never had the need to try taking apart a major system component like that before, and I know my soldering-iron skills are probably not up to the task. That is some damn fine work, there, although I have to agree with Panic about the capacitors.

    That is also a textbook example of a good follow-up post to resolve a thread, and provide good guidance for future readers.

    Depends on the type of motor. For some motors (BLDCs, for example), just increasing power will increase both RPM and torque. Steppers, OTOH, lose torque at higher speed, but increasing current will increase torque with no effect on speed.

    The harmonic drives are generally installed b/c most servo motors are better at generating speed than torque, and because it allows finer position control. Servo motor systems are generally better at controlling their speed than their position, but by having dozens or hundreds of motor rotations equate to a single degree of axis motion, through gear reduction, basically allows you to control position by controlling speed.

    I werd thatit is not a simpel solution to this.

    There's no simple solution b/c it's not a simple task. Generating a robotic milling path is much more complicated than generating one for a CNC machine. Robots have much more complex kinematics.

    Of course, if you want "simple," you can just pay the going price for RobotMaster or another professional-grade tool that handles this task. Of course, it won't be cheap.

    Is there a button or box drop down in which you see "attach" or something like that?

    Not that I've seen. The "mounting" appears to be based on where in the tree you place the geometry. Geometry under the "tool" branch attached to the Axis 6 flange, and geometry under the "robot" branch appears to attach to a point near the intersection of Axes 3&4. There's data entry areas for the location and size of the geometry, but nothing to "mount" it.

    I've been setting up some Upper Arm Geometry on some IRC5s recently, to cover the elbow-to-wrist volume of the robot. Especially since I have some bulky brackets mounted to the forearm in that area that need to be taken into account for the Safety Zones.

    But I found that, as Axis 4 rotate, the UAG does not. This is inconvenient, since I wanted to make a minimal geometry that bulged out further only on the side where the brackets protruded from the forearm.

    But when I did so, I saw that when rotating Axis 4, the dress brackets on the forearm would rotate out of the envelope covered by the UAG. Despite being "mounted to the robot upper arm, the geometry doesn't seem to rotate with the arm. Instead, at the moment, it looks like I'll have to make a "fat" cylinder centered on the Axis 4, wide enough to cover the volume "swept" by the forearm brackets through Axis 4's entire range of motion.

    Annoying, but I think I can deal with it. Still, I thought I'd ask if this matches other users' experience, and if anyone knows of a way to get the UAG to rotate with Axis 4?

    The robot runs on a 12ms internal clock cycle with scheduled multitasking. This comes out to a frequency of about 83Hz. One side effect of this is that you probably can't fire a pulse with a duration less than 12ms. Another is that $POS_ACT_MES only updates every 12ms.

    A short SPS loop can repeat multiple times in a single ~2ms "slice" of the 12ms "pie," but for ~10ms out of 12, the SPS is suspended. And since an I/O refresh only happens once every 12ms cycle, once the Pulse command fires, it'll take 12ms before the next I/O refresh that can shut the signal back off.

    Going by those numbers, it would seem that you should still have headroom up to ~41Hz (remember, you need at least one refresh cycle of signal-off time between signal-on times), but 36Hz is close enough that I'm not too surprised -- there's probably some subtleties that are eating up some more of the cycle.

    RSI might help, if you used IPO_FAST mode (4ms cycle). I've never tried pulsing outputs that fast with RSI, though.

    Another approach might be to try Interrupts, instead of the SPS. That would be trickier to code, but Interrupts are supposed to be hardware-level interrupts that act with microsecond response times, IIRC.

    Yet another idea: Create your program with points 30mm apart, and put a TRIGGER on each point to pulse the output. Or, what might work better: if you can get your camera to trigger on both rising and falling edges, just have the Trigger invert the output, instead of trying to rely on a PULSE time between two points.