Posts by SkyeFire

    Using BAS is convenient, but not necessary. KUKA included BAS mostly to support Inline Form programming. As you've seen, setting the Tool with BAS automatically sets $ACT_TOOL and $LOAD, along with $TOOL. This allows Inline Form motion points to only select a Tool number and let BAS do everything else for them.


    As far as I am aware, $ACT_TOOL has no effect on the robot, it just updates the "active tool" number shown in the pendant display. If you control $TOOL directly, it's possible to forget to update $ACT_TOOL, so the pendant display will not match your actual active tool.


    OTOH, avoiding BAS lets you do things like change $LOAD when you pick/drop a payload without needing to set up duplicate Tools (Tool 1 for an empty gripper, Tool 2 for a full gripper, with identical XYZABC but different LOAD_DATA values). It's also handy if, for some reason, you don't want to use the TOOL_DATA array.


    Most of the time, BAS is the better option. But KRL allows you the flexibility to choose.

    If I want to log a value from this signal between every point the robot moves to, do I send a readOutput or readSignal command between every point..?

    Nope, nothing special needed. At the program level, any multi-bit SIGNAL you declare looks and acts just like a typical INT variable. It's just that the Input SIGNALs are updated by the operating system.


    So, doing this:

    Code
    SIGNAL MyOut $OUT[1] TO $OUT[8]
    SIGNAL MyIn $IN[1] TO $OUT[8]
    LOOP
      MyOut = MyIn
    ENDLOOP

    Would constantly update your output byte to match your input byte.


    Or, if you want to scale or directly set your output byte, you can do any math on it that you would on an ordinary INT variable.


    Also, I found a bug in my precious example:

    DECL INT VIn1

    SIGNAL AIn1 $IN[1] TO $IN[8]

    VIn1 = AIn1 * 0.039

    DECL INT VIn1 should be DECL REAL VIn1. An INT variable will always be an integer value, even if you do floating-point math on it. So IntegerVariable=5/2 will always return 2, not 2.5.


    We were able to find that the analog signal is communicated across a given set of bits. The values we're looking at are signed (+/-).

    Okay, signed values get a bit tricky. In KRL, all INT variables (which multi-bit SIGNALs are) are treated as signed 32-bit numbers, even if the SIGNAL is declared as something smaller than 32 bits.

    Which means that, for an 8-bit SIGNAL, you need to handle the sign bit yourself. There's a few ways to do this, but one way would be:

    Or there's things you can do with the B_AND operator to mask off a particular bit(s) of a word.


    Note: For 32-bit words, there's a special case encoding (IEEE 754, IIRC) that PLCs do automatically when sending/receiving real/float values over binary words. KRL doesn't do this naturally, but current KSS versions support the CAST_TO and CAST_FROM functions (check the forum archives) that will handle this.

    You don't really have to use analog signals on the KRC for this. An "analog" signal over fieldbus is simply a several-bit binary number. For example, an 8-bit analog signal representing 0-10V would have raw binary values between 0 and 255, for ~40mV per bit. So simply assigning a "group" signal in KRL, like

    DECL INT VIn1

    SIGNAL AIn1 $IN[1] TO $IN[8]

    VIn1 = AIn1 * 0.039

    would accomplish what you're looking for. It gets a bit more complicated with signed values, but it can all be handled mathematically.


    The only advantage the $ANIN signals have is that they can scale the binary-to-voltage conversion inherently.

    does the integrated vision system helpful for identify the similar but different size of parts and take program offset accordingly ??

    The Integrated Vision option doesn't make the Cognex any better or worse at performing vision operations. What it does do is make communicating between the Cognex and the robot much easier -- the IV option adds software and hardware to the robot to simplify the integration, and also adds software to the Cognex to complete the package. In fact, I believe if you buy your ABB with Integrated Vision, you need to order the Cognex as part of the package, and you will receive the entire setup from ABB in a single package.

    Eventually I found that the Atlas Copco Nut Runner was in fault. I disabled in turn all the devices on the network and when it was the turn of this device the network began to work again. It remains strange to me that no dedicated messages was showed but at this point I'm happy enought with the help I received from you all. Thanks a lot mates!

    It is odd. But I have seen it before -- there were certain Siemens devices that, if improperly configured (usually incorrect baud rate), would crash the entire network. But even then, I would normally get a message for each MAC ID on the DN bus, along with the general error.


    I wonder if the nut runner was causing some sort of electrical fault on the DN line -- shorting the CAN+ and CAN- lines together, or something like that.

    Yes, I did it with no joy unfortunatelly.

    Received message 'Error on writing, driver: DN2DRV'.

    There should be additional errors with greater detail -- for example, which node is failing to be written to.


    Have you checked the power on the DN cable? The status LEDs on the DN modules and the X801 connector?

    Do you have the ABB IntegratedVision option installed on the robot? That makes things simpler.


    If you don't, then it's a matter of establishing communication between the Cognex and the ABB, which isn't too hard, but depends a great deal on your options -- Ethernet/IP vs ProfiNet vs Socket Comms, what data you want to transfer, etc.

    if I hit the emergency stop then the cutter stops which is a good start but is there a way to trigger an emergency stop under other settings.

    Depends on how your system is set up. You might have your E-Stop circuit hardwired into the power supply to the router, for example.


    I assume your robot has an output that can turn the router on/off. You could put something in the SPS that forces off that output when $PRO_ACT (program running) or $PRO_MOVE (robot moving) turn False. It doesn't have to be an E-Stop, specifically -- you want the router to turn off if the robot stops for any reason.

    Is there another way to fix these ini errors without a fill reinstall?

    It's hard to say, without being able to get a lot more detail. If the files are present and not corrupted, then there may be an OS-level issue in KSS.

    Re-installing KSS is the "shotgun" solution, but should fix these errors. That said, get the image backup first. You can always re-install KSS from the D: drive, but you cannot re-install Windows without the original install CD-ROM from KUKA, and getting one of those for this controller in this day and age will be very difficult, if not impossible.

    Re-installing KSS will "reset" the robot to "factory new" condition. It should be entirely possible to re-install KSS, then restore your last "known good" Archive backup. This has always worked perfectly well for me in the past. However, since you have a BMW "special" robot, it's possible there might be some issues I'm not aware of. I know doing this on a VW-version KRC could be a major headache, but VW's customizations were brutal.

    A full image restore might be premature at this stage, but definitely take a full image backup if you haven't already -- if the HDD is starting to have issues, you'll need it.


    But definitely taking an Archive backup and comparing those two .SRC files as they are now, to a backup when they were known to be good, would be a first step. Or even just checking those two .SRC files for syntax errors.

    Root issue here is that the Submit and Robot interpreters (Level 0 and Level 1, respectively) are completely asynchronous. And any event like a Program Cancel or Reset in the Robot interpreter will cause $POS_ACT (or $POS_ACT_MES) to become invalid -- #DECLARED but not #INITIALIZED, in VARSTATE terms.


    This means that it's possible for $POS_ACT_MES to change from #INITIALIZED to #DECLARED in between two consecutive lines in the SPS. So VARSTATE is not a reliable test here.


    As hermann said, look into using ON_ERR_PROCEED instead.

    I took a backup, but didn't image the drive. I was hoping to get the safety working before I made an image. I tried restoring from the backup, but it didn't help

    BAD idea. For any robot, especially an older one where re-install media may be hard to obtain, practically the first thing to do on first power-up is to take a "out of the box" image. You may want to take more images at various "milestones" along your progress, but even for brand-new robots I try to always take a full image as a "disaster recovery" save point.

    All this power cycling has now messed up my ini files? Getting a bunch of errors in the pendant about "error during reading ini". Should I be able to overwrite the ini files in C:/krc from a backup, or is this another rabbit hole?

    Power cycling shouldn't corrupt INI files. Although with robots this old, things can happen. Especially if the power cycles are too fast -- KRCs need to be allowed to complete shutting down before being powered back up. Especially if the batteries aren't up to snuff. Even for new, fully-charged batteries, a large number of back-to-back power cycles could eventually cause issues.


    I think we would need to see the actual error messages to advise you in detail. With luck, you should be able to simply restore from the Archive backup you made before these errors started happening. If that doesn't do it, re-installing KSS should work (although I'm not familiar with BMW versions). Worst case, you could restore the HDD image backup you made before any of this started.

    (you DID make backups, right?)

    The values in that video are unreadable. That said, Fubini is most likely correct.


    The Very short version is: For Euler angles, there can be an infinite number of mathematical solutions to the same physical orientation in space, so KSS limits the solution space to +/-180deg for A and C, and +/-90deg for B. As any one of the values approaches its limit (or sometimes any integer multiple of 90deg), you're likely to see some very large jumps. And given the way the angles interact, it's easy to achieve a state where making a tiny jog to, say, B can cause a huge jump in A or C values.


    Bottom line: this is normal and expected behavior. As long as the robot moves cleanly, you're fine. The path planner is built to deal with the "wraparound" of these values.

    one if i want to use onboard ethernet and second if i will buy a network card ,is that right?

    No, the question is, what does your application require? A question you have not yet answered.


    For RSI, the secondary ethernet card is strongly recommended. For anything else, the built-in ethernet port is sufficient.


    In fact, if you were to use VarProxy, I believe that cannot use the secondary ethernet card, only the built-in one.

    My gut says the robot should not be running unsupervised but I'm looking for a gut check if I'm being overly cautious.

    There's no insurmountable obstacle to running a robot "lights out". It depends on the risk factors and how you deal with them.


    For example, if the robot having a mishap could cause a fire and burn the whole building down, then investing in a good automatic fire extinguisher system might be one way to mitigate that risk. OTOH, if the odds of that happening are 1/10000000, is it really an issue?


    Normally it's a two-axis graph: How likely is a particular failure, plotted against how bad it could be.


    Lots of operations run robots unattended. Good cell design and robust error-checking can usually eliminate the vast majority of risks.


    Modern robots practically never "wild orbit", and frankly, if that ever happens, it's probably better when there's no one around. Almost all robot collisions these days are the result of a programming error. Good SafeOperation zones and velocity limitation, and/or collision detection, can make it nearly impossible to do any serious damage if the robot ever goes off the reservation. The bigger risk would be people wandering into the robot's path, but a properly fenced cell won't have that issue.


    Interlocking is important. If the robot were to stop for any sort of error, you want to ensure that the cutter also stops -- letting it sit and rub against the same piece of wood (you said it's routing) all night is probably a recipe for a fire. OTOH, ensuring the cutter stops spinning whenever the robot isn't moving isn't hard, it just requires carefully considering all the possible failure modes and ensuring you have them covered.


    Likewise, a sawdust fire is no more or less likely running lights-out vs having people on hand. It's a question of whether your fire prevention relies on someone seeing/smelling something, or if you have a reliable automatic detection/extinguishing system.

    How come KUKA on the controller won't allow OPEN and CLOSE to be declared but seems to work fine in Work Visual?

    What do you mean "works fine in WoV"? If you only mean that the WoV syntax checking doesn't flag it, that's simple: the WoV syntax checking is a constant work in progress, and isn't 100% accurate. The KRC is the final arbiter -- just because it seems fine on WoV does not ensure it works on the robot.


    There are certain "common" words that are reserved keywords in KSS. OPEN and CLOSE are among them, like TRUE and FALSE.

Advertising from our partners