Posts by SkyeFire

    Morning, all. Stupid question, but: is there a manual that has a "master list" of all the different values ERRNO can take on? In the RAPID Reference docs, any command that throws an error (SearchL, or WaitUntil\MaxTime, etc) has the ERRNOs it can throw documented, but I'm wondering if there's a doc that brings together all of the error codes.

    KRC4s support EtherCat natively, but with limitations. There are KUKA optional software packages to support ProfiNet, Ethernet/IP, and simple TCP/IP string exchange (basically, Telnet). With added hardware, older FieldBusses like ProfiBus, DeviceNet, InterBus (also ModBus?) can be supported.


    I believe there is a software option to add OPC/UA.

    The G-code can't handle I/Os direct, they all are ranked through a PLC that does some logic that's neccessary for the M functions controlling the I/O.

    Well, I learned something! :dance:


    My CNC experience is pretty limited, but the ones I've worked with had just a small number of relays that were controlled directly by G-Code, with no background ladder-logic processors.

    Ladder? Wouldn't a CNC machine normally control I/O through G-Code?


    If you can't control interface signals through I/O, then it gets more complex. Say, for example, the CNC has an automatic door that it can open/close from inside a G-Code program. You could add sensors to the door such that the robot could detect the door opening, and trigger the robot's unload/reload program based on that. Probably you would want to wire an extra relay in series with the powered door, controlled by the robot, so that the robot could block the CNC from moving the door as long as the robot was not clear.


    It all depends on what signals or hardware you have how much access to.

    When you mentioned an interlock you meant a chuck interlock?

    More like, a set of interlocks. The door would be one -- you need positive information on whether it's open, closed, or "unkown". Likewise, you need some sort of interlock to ensure that a programming error can't start the CNC while the robot is inside its working volume, or tell the robot to reach into the CNC while the CNC is still moving. Interlocking the chuck would depend on whether the robot has to be holding the stock while the chuck closes on it, or needs to grab the finished work piece before the chuck opens.

    Well, the first question is, how are the robots and CNCs going to interact? Followed by, how will the robots and CNCs communicate?


    A robot reaching into a CNC without some sort of interlock is a good setup for a very expensive collision. But some old CNCs are so "standalone" that they provide nothing, or at best very little, in terms of I/O interfacing to other pieces of automation. I've literally seen people attach small pneumatic cylinders to their CNC control panel to push different buttons, and attach photo-diode sensors to different indicator lights, because the CNC controller provided no means of exchanging signals other equipment, only with human operators.


    Just for starters, if your CNC has a door, you'll want a very solid way of letting the robot know that the door is fully open before reaching in. If the robot is going to grab the door and open/close it, you'll need reliable sensors for the "closed" position as well.


    If the robot is loading stock, you can run into issues with stock size variance. Robot's don't usually have touch-off probing, so rely on whatever they're working with to be the same size every time. Clamping stock might be an issue if you have a manual vise -- trying to teach a robot to turn a vise handle is liable to be... interesting. And not terribly consistent in applied torque.

    For most robot brands, Base 0 (UFrame 0 for Fanucs, Work Object 0 for ABBs, and so on) is a reference to the robot's World frame ($WORLD in KUKA). This coordinate system is permanently attached to the robot's base and cannot be altered -- it is literally part of how the robot is built[1]. "Base 0" is just an easy way to use World in programs, without having to create an extra data type. Tool 0 behaves similarly, but "mounted" to the robot wrist, rather than the robot base.


    Generally, any Base is an offset from World. World is considered the "master" reference frame from which all other Base frames are measured. And any point programmed for a move command (PTP, LIN, etc) are referenced to a Base.


    Without seeing the code of your robot, I can only guess, but if they programmed everything in Base 0, there are two ways they could have made it work.

    1. Point offsets. Basically, teach the "master" Pick Position once, then as the program runs, do something like TempPickPosition={X 100, Y200, Z 150,A 0,B 0,C 0}:MasterPickPosition , with the offsets changing to reference a particular item location on the pallet

    2. Base offsets. While Base 0 is unalterable, $BASE is the "live" Base that the robot is actually executing motions in, and $BASE can be set to anything. So the program might start with $BASE=$NULLFRAME (since there's no BASE_DATA array element for Base 0), but then, while running, $BASE={X 100,Y 200, Z 150... etc similarly to how the point offsets would work.

    3. I know, I said two. That's because Tool offsets could theoretically be done to make this work, but this method would be substantially more work for no gain.


    [1] there are special cases, like when the robot is mounted on top of a 7th axis positioner, where World is moved from the robot base to the base of the positioner. But World does not change unless the physical kinematics of the robot are altered. Once the robot is configured, World can be considered to be "grounded" to whatever structure (generally immobile) the robot is mounted to.

    AFAIK, just about any KRL written for KSS 8.2 will work under KSS 8.6. The only things that won't that I recall offhand is some of the CWRITE file-access commands. Some motion data may be incompatible, but IIRC they are compatible going "up" KSS versions, just not "down".


    This assumes that both robots have the same KOPs installed -- obviously a GripperTech command won't work on a robot that doesn't have GT installed.


    Hm... now, it's possible that there might be breaking changes in the Inline Forms code between older and newer versions of Gripper and SpotTech. KUKA generally tries to avoid that, but eventually it happens. ExpertTech has probably undergone the most changes, so any custom code relying on it may need to be refactored.


    SafeOperation has to be set up on a case-by-case basis regardless, but the underlying architecture should be the same.

    Only to a limited degree. "Crowding" points in the corner will counteract the large $APO_DIS value, but you'll quickly hit the point where the points are so close together that the path smoothing breaks down entirely and the motion becomes herky-jerky.

    $DIST_NEXT could be implemented in a submit where you could abuse $OV_PRO for the purposes discussed above with well situated points for the task. Not an elegant solution but in principle functional.

    $DIST_NEXT is a scalar value, however. It won't tell you anything about whether the next move passes through a workspace or not.

    i have looked in every program and they all use nullframe.

    How? Raw KRL, Inline Forms?


    I found something in System, but modify it didnt have any effect,

    ...what? What did you modify? How?


    What base is being used in the program? Base 0 is unalterable, while any other Base (usually part of the BASE_DATA array in $CONFIG.DAT) can be altered in any way you desire.


    If the programs are written to use Base 0, and you make edits of Base 1, of course it won't have any effect.

    -In what milling use case does C_Vel give better results that C_Dis ?

    C_VEL does the same thing C_DIS does, except that C_VEL prioritizes a fixed speed through the approximation path, where C_DIS prioritizes the the shape of the arc, allowing speed variance.


    Have you tried Spline blocks? They're more finicky, but can be more amenable to maintaining a path through lots of points, instead of "cutting corners".

    -Is there a general rule that can be used to get optimal values for these parameters, depending on the smallest detail/feature in the milling ?

    Not really, no. There's a reason that the software stack for doing this professionally is $$$. And even then, there's still a substantial amount of trial-and-error required. CNC machines brute-force their way through sharp corners, material resistance, cutter "recoil" forces, etc, but robots can't. For small sharp details, you'd better have a cutter much smaller than the detail, and be prepared to either accept rounding, or accept coming to a momentary dead stop in the corners.

    The root issue here is that the robot does not do a "simulation" of a move before it executes. When a PTP command is executed, the path planner basically calculates the end of the motion, issues each axis a command to move in that direction at that speed, and doesn't look at it again until the PTP is finished. The path planner is not "aware" of any of the motion along the way, except as a set of accel/decel/time profiles.


    The workspace checker, OTOH, is a "realtime" task, that is only monitoring the actual position of the TCP and/or axes and checking them against the workspaces every IPO cycle. It's not "aware" of where the robot is going, only where it is at any given moment.


    LIN motions are basically a string of very small PTP motions run in sequence, and the path planner is only really "aware" of the next 2-3mm of motion.


    I have seen applications where someone tried to create a "path awareness" check, but it got very complex very fast. A planned motion would be divided into "chunks" of a certain distance, and the program would run each "chunk" destination through INVERSE and FORWARD and check the results against the WorkSpaces, then only execute the LIN or PTP if all the "chunk checks" passed. The KRC processor is usually fast enough to do some of these checks in advance without breaking the ARP, if your program is well structured, but you quickly run into an issue of resolution -- checking every 1000mm makes it easy to miss that you might clip the corner of a workspace, but checking 1mm will probably bog down the processor and break the ARP. Then, of course, every in/out check has to be hand-coded, as well.

    3-5sec decel is meters of motion, unless your robot is moving very slowly, in which case you hardly need such a long decel ramp. How did you come up with that number? I honestly can't see any application that would need such a long decel ramp, aside perhaps from carrying an open-topped bucket of water and not wanting to spill a drop.


    As long as the robot has good $LOAD data, issuing a basic BRAKE command in the ISR should give you a path-maintaining stop that's not very violent, but requires much less time that 3-5sec. Have you tried that approach?

    ....programming a palletizing setup without setting up a Base or Tool is programattical suicide. Or possibly masochism. Is the original robot seriously running Base 0 and Tool 0 universally? That only works if the pallet is perfectly square to $WORLD, or if the program is doing extra trigonometry on every shift.


    How is the original program doing the Pallet pattern math? That's really what's going to define how much you can salvage from it.