Posts by Metalikooky

    You haven't really provided information to completely answer your question. What type of event are you monitoring for? Do you want that monitor to be active during all subroutines or only certain ones? Do you want the subroutine you're executing when the event happens to complete or should the robot essentially abort what it's doing and start executing something else (or nothing at all?)

    An interrupt is generally a good way to do what you describe, but you could also set a flag, finish your sub, and then check the flag before executing subsequent subs. Still other strategies exist, and which one you choose is dependent on information you haven't described here.

    Good morning, I created a program that has 8 pics and drops in it. Of the 8 actions to open or close the grippers 3 do not work? All the code is the same for the commands. Should I have written 4 separate programs and just called them from one main program with the call command?
    Thank You

    Generally speaking, it is good practice to use a subprogram/macro to do repeated tasks like gripper open/close. Any chance you can post some code for us to look at? My first guess, not having seen your program, is that the Advance Run pointer is playing tricks on you. Try searching your manuals for the variable $ADVANCE and the term "Advance Run" and that will get you going down that path. Of course, I could be completely wrong. It would be good to see the code.

    42 :hammer1:

    I'm fairly well versed in Kuka robots, and I don't understand this reference. How is this helpful? What's wrong with either answering the question or not replying at all? It's a serious question that isn't just directed at one user, but at the community as a whole. I've seen a lot of responses lately that only seem to admonish the OP for not having the knowledge they're coming here to gain. I don't have a problem pointing someone in the direction of a manual or a previous post. But if I were new to Kuka robots and looked over some of the forum posts here, I'd be hesitant to ask my questions.

    Why not just use the FTP commands inherent to the Windows command prompt? There's no need for first or third party software when it's already handled by Windows. Also, if the D: drive is made publicly available in Windows, you can also simply drag and drop files with the Windows Explorer.

    There is a message programming manual. I'm not sure if it's on this site or not. If not, you can get it from your Kuka rep. Beyond that, look for the MsgLib.src file on your robot. That routine provides canned macros you can use to display different types of messages. The type of message you will need to offer operator input would be a Dialog Message. The problem is that Kuka doesn't offer an inherent way for numeric entry to dialog messages.

    Search this forum for the manual, as well as MSGDialog or MsgLib.src and you'll find plenty of discussion on how this works.

    If the point is declared and initialized in a DAT file, then the FRAME elements will copy over but the original S, T, and E6 values will remain. If the point is simply declared, either in a DAT file, or at runtime, those elements aren't saved during subsequent runs of the routine.

    In other words, if you write the following:

    DECL POS myPos ;this position is declared but not initialized

    versus the following

    DECL POS myPos={X 0,Y 0,Z 0,A 0,B 0,C 0,S 0,T 0} ;this position is declared and initialized

    the values of myPos will not be retained between runs of the routine. Declaring the variable can happen in a local DAT file or in a global DAT file. These would not be runtime declarations. Or it can happen in the SRC file, which means it is declared at runtime. In either case, as long as the variable isn't initialized - as long as the value isn't recorded after the declaration - its value will not be retained.

    Well, if you copy the value of a POS or E6POS into a FRAME variable, it will "chop off" the elements of the source variable that don't exist in the FRAME, e.g. S, T, and external axis values. Then, if you copy that value back into a POS (or E6POS) variable that's declared at runtime, or into a POS (or E6POS) declared, but not initialized, in a DAT file, you'll have a POS (or E6POS) with only the X, Y, Z, A, B, and C elements.


    The workspace monitoring function is built into the KSS, but it is not safety rated like DCS. For that, you would need the option package SafeOperation.

    As for reading up on the workspace monitoring, I believe your best bet is the System Integrator's manual for whatever version of KSS you're using. It's pretty straightforward though - I think anyone with even a little bit of prior experience will be able to figure it out pretty quickly.

    Good luck!

    That I can think of, you can't directly do this with the points created in an inline form. The point names could not be referenced in a FOR loop. HOWEVER, you could make those points equal to another set of points that are declared as an array. And then individually copy the array variable into the inline form point data before moving to that point.

    For example, declare an array position variable to whatever length you might need:

    DECL E6POS posVar[10] ;Using a length of 10 just as an example.

    When you create a point using an inline form, copy that point data back into the associated posVar[] array position. Once you're done with your path, you would simply add the following code to the top of your program:

    FOR idx = 1 TO (index length)
       posVar[idx].Z = 0

    And then copy the array variable into each associated inline form point before moving to that point:

    XP1 = posVar[1]
    LIN XP1 ... (I don't have the complete syntax of the inline form memorized.)

    It's clunky, but I think it's really the only way to do what you're trying to do.

    Also, there is a specific manual Kuka has for generating messages on the KRC4. I'm not sure if it's over on the manuals section of this website, but if it isn't, you should be able to get it from Kuka, or look in the Parts and Documents CD.

    INV_POS() is a system function in KRL that performs a matrix inversion of a FRAME, POS, or E6POS type variable.

    The Geometric Operator (a ':' character) performs a matrix cross-product on any two FRAME or POS-type variables.

    Between them, these two will do everything you need. They're both discussed at length in the forum archives. The G.O. is documented in the KRL manuals, although for some reason INV_POS isn't.

    Is this the same as the INVERSE() function?

    It's difficult to directly edit an RSI context that's generated from the F/T application and maintain that change through subsequent iterations of the application. If a change were made directly to an RSI context via RSIVisual, I suspect that if a change were then made to the F/T application via the F/T application editor in the HMI, any changes that were made via RSIVisual would be overwritten. Both good ideas though.


    From what software is your screen shot? I don't recognize that from Work Visual. Maybe I've just missed that screen? I was aware of only two ways to set the VelGain values - one with the KRL "command line" suggested in the External Kinematics manual and one by editing directly the file where the value is stored.


    message you mention should never be on its own, there should be others too. i had similar problem not long ago - it was a robot with 6 external axes. attempt to move any axis would cause all axes to "shiver" for a moment before faulting out.

    issue was wrong gain on one of the external axes (gain value was incorrect in the WoV catalog, obviously a typo - it was of). resolved it same way you did - incrementally added more axes until troubled one was found (E5 in my case, had to reduce VelGain by order of magnitude, obviously someone skipped one zero... :baseball:).

    We have some experience with this. The vibrations are probably coming from a gain setting that is too high in your F/T application. Try decrementing your gains until the vibration goes away. Note that this will slow the robot's reaction to the external forces. The other thing you may want to look into is the servo tuning on your robot. But I doubt that's the problem. 99% sure it's the F/T application gains.