Posts by Razzzhead

  • Mapping I/O KRC4 | Get Current Cartesian Position

    Are you familiar with fieldbus IO mapping in WorkVisual? The help file is your friend. Assuming your HMI on which you want to display the position data is connected to the KRC via a fieldbus then it should be straightforward.


    In my example I have the KRC I/Os in the left window and the Fieldbusses in the right window. My bus is a Beckhoff Profibus EL6731-0010 slave. You have to have spare slots available in the map - I chose slot [22] in this example which has to be configured as 3x INT in the signal editor. Drag the $ANOUT[3]-[5] group from the left window to join 21.0001 - 21.0005 in the RH window and all three will show as mapped and turn from grey to green. Voila:-


  • Mapping I/O KRC4 | Get Current Cartesian Position

    Why not use a cyclic Analog output? It's updated every 12 ms and there are plenty of way to create an almost real-time representation of axis or cartesian positions without the added expense of an RSI option package. It's limited to 4 concurrent channels which should be enough for 3-D. The description can be found on xpert.kuka.com under ID SE63407.

    Syntax

    Starting cyclical writing:

    ANOUT ON Signal name = Factor * Control element <±Offset> <DELAY = ±Time> <MINIMUM = Minimum value> <MAXIMUM = Maximum value>

    Ending cyclical writing:

    ANOUT OFF Signal name


    All the variables are REAL, as is $POS_ACT_MES and all other position or velocity variables.


    Although the Analog command was originally designed for synchronising a gluing process with TCP velocity, it should work with positions. The nice thing about the command is it can work in the advance run using planned positions, so by using $POS_ACT instead of $POS_ACT_MES and using a negative DELAY, it should be possible to overcome any system lag.


    It's easy to assign each $ANOUT[n] to the fieldbus IO in WorkVisual - you don't need a physical analog device - but only 16bit INT is supported. By manipulating the calibration factor, it's possible to determine the accuracy and range required.







  • $DATE does not match the system time

    Although this post is from last year, the out of sync issue with $DATE remains. From KSS 8.6 there's a new variable named $DATE_HOST which overcomes the issue and can be used the same way as $DATE. It's a shame they didn't do this years ago.

  • Jogging external axes

    KSS 8.6


    Is there a way to know when an external axis is being jogged by means of an axis key in $T1?


    The robot has E1 and E2 which will normally be driven synchronously from the program using E6POS moves, or asynchronously using ASYPTP moves. In some parts of the program due to mechanical reasons, these external axes will normally always have positions that are synchronous to each other much like a master/slave configuration but with both axes being driven from a common position command such as PTP {X 0, Y100, Z 0, E1 90, E2 90}, or ASYPTP {E1 75, E2 75}. However during external axis jogging, unless both keys are pressed simultaneously, the two axes will become separated and then the other axis would need to be jogged to catch up with the first one. I can't declare a proper master/slave configuration and only use one external axis. as in some instances the two axes will be mechanically independent, so will need to be driven separately.


    I have considered some logic in the SPS.sub which could determine that say E1 is being jogged and command its partner E2 to "keep up". This could be done by using the command ASYPTP MyVar , where MyVar is an E6AXIS variable so that MyVar.E2 = $AXIS_ACT.E1. But for this to work I would need to determine which axis is being jogged and which one not. I don't mind that during the actual jog movement of E1, E2 lags a distance behind, but when the E1 jog key is released and E1 stops, E2 should then "catch up" and again have the same position as E1. What I don't want to happen is for E1 to reverse movement and go back to where E2 was when the jog key was released.


    I should be able to figure out the logic to do this, but Ideally I need a pair of variables to tell me when E1 is being jogged and another when E2 is being jogged. I have found $KDO_ACT to indicate axes being jogged or commanded, but that doesn't tell me which one. I suppose I could log both positions during standstill and then determine which one moves first and call that the leader, but its dirty. I also thought about IS_KEY_PRESSED ( nn) to determine which axis key was pressed but again probably equally dirty.


    Does anyone have any ideas of how this could be accomplished?

  • Base calibration

    KRC4 8.6.6


    At present I don't have the real robot - I'm only using Work Visual 6.0 on a PC.


    I'm trying to figure out the best way to automate the manual KUKA 3 point base calibration procedure using a simple binary sensor connected to a fast measuring input. I want to be able to capture my points whilst a nominal base and measuring tool are active, and to produce a correction frame which I can use to shift the nominal program to fit the actual location of my workpiece:-


    New_Base = Nominal_Base : Correction_frame


    I'm sure I've seen this discussed before but can't find the threads referred to as they may be obsolete: wherever it was mentioned, the links don't work anymore. This is from 2017: -


    I've considered using TouchSense 3.2 as has been suggested elsewhere, but I'm not convinced that it will result in the correction frame that I need as it does with the manual 3 point method. This example program shown in 9.1 of the documentation is confusing as it doesn't show how the 3D correction is done on lines 30-35, as the points were made with BASE[0], not with a pre-defined workpiece base: -


    How can this work? I can see that the 3 correction vectors CD1 CD2 and CD3 were determined using BASE[1]:Table, but the points to be corrected are executed using Base[0], not BASE[1]:Table, as one would expect. Is it being done using a Technology Function as with a TTS weave? I find the documentation confusing as it doesn't explain actually how the shift is done.


    I understand the KUKA 3 point base calibration procedure uses some embedded dll code so there is no KRL to examine as with some other included functions. I'm sure if I had a real robot to play with, I could come up with a reasonable solution using instructions such as the geometric operator and INV_POS (...) for example, but I'm working from home at present, so proper development and tryout is difficult.


    Can anyone point me to some KRL code as an example, so that I can understand how the task might be accomplished?


    Thanks in advance! :)

  • Absolute Accuracy Info KRC2 - KRC4

    Thank you for your explanation which has reduced my confusion to almost zero! I had erroneously thought that if the status bit 4 was not set, then the Absolute Accuracy behaviour would be permanently disabled for that move. But as you point out:-

    Quote from Fubini

    ...bit 4 is set to true so this algorithm is not applied multiple times on a teached position. This is the only case inside the controller where status bit 4 actually has some significance.

    That makes sense why offline programs that don't have status bit 4 set, still work properly in the AA sense. Although I suppose if one had such a program and actually ran it with $ABS_CONVERT set to TRUE, then those points (and the interpolated path to those points) where bit 4 was not set, would be executed without AA and therefore be displaced from their prior coordinates. Consequently, the newly refreshed AA derived coordinates for every point would be incorrect.


    Perhaps that's why with later platforms, the documentation omits to mention the existence of $ABS_CONVERT, as without a detailed explanation, it would be just too easy to ruin a program that previously ran properly with AA. The author probably thought that if the description didn't exist in user documentation that implicitly reserves the use of the variable to KUKA personnel - what the user doesn't know can't harm him.


    However, for the sake of convention in offline programming, I believe that bit 4 should always be set for those points generated offline. As you point out:-

    Quote from Fubini

    Offline generated programs in itself are in a sense always absolute accurate.

    In the case of an AA robot, do you think manually taught points will have status bit 4 set automatically? In an offline generated program which is run on the robot, what happens to bit 4 that has been downloaded with it set to FALSE when one manually performs a touch up? Will it become set to TRUE?


    I would still like to see official documentation though. Do you think it's worth asking KUKA for it?

  • Absolute Accuracy Info KRC2 - KRC4

    Does anyone know the whereabouts of information or KUKA documentation regarding Absolute Accuracy?


    This is what I know so far:- I found an old document for KRC2 called Configuration - High Precision Robot which describes the installation of the necessary service pack, copying the relevant robot specific PID file and setting $ABS_ACCUR = TRUE. This is clearly only relevant for KRC2 SW versions and in addition I found in an old KSS system variables document where there are three relevant BOOL variables:-


    $ABS_ACCUR - Switch absolutely accurate robot model on/off

    $ABS_CONVERT - Conversion of point coordinates into absolutely accurate robot model

    $ABS_RELOAD - Reload absolutely accurate robot model


    In addition I believe that the E6POS and POS structures contain the INT S(Status) and T(Turn), and there is at least 1 bit (perhaps bit 4?) in the S field that contains information whether the point coordinates were taught with or without using the AA model.


    However it would appear that the functionality of Absolute Accuracy may have changed with KRC4, as I found the variables described above have changed in KSS 8.1:-


    The variable $ABS_ACCUR - Indicates whether the positionally accurate robot model is active.

    But changes from type: BOOL to type: ENUM having values:-

     #ACTIVATED: Positionally accurate robot model active
     #SUPPRESSED: Positionally accurate robot model currently suppressed (by $SUPPRESS_ABS_ACCUR)
     #NONE: No positionally accurate robot model available

    $ABS_CONVERT - seems to be missing with KSS 8.1

    $ABS_RELOAD - Reloading of the positionally accurate robot model

    $ABS_UPDATE - Updating of the positionally accurate robot model by means of a SOAP-HTTP protocol

    $SUPPRESS_ABS_ACCUR - Suppression of the positionally accurate robot model


    So this is a far as I got. I remember vaguely once (20 years ago?) using the $ABS_CONVERT variable to convert point coordinates in a program taught without the AA model being active. I had to run the program having correct LOAD DATA with the $ABS_CONVERT set to TRUE and then the coordinates for each point was updated with new AA coordinates and S(Status) bit 4 for the same point was written to TRUE. At the end of the program $ABS_CONVERT was reset to FALSE. So then when the program was run, the positions the robot executed with the AA model active were then identical to those executed with the AA model inactive - albeit with slightly different point coordinates for every move. However as long as the AA model was active, if the program was then subsequently run with different loads and corresponding Load Data, each position would be executed correctly with enhanced accuracy.


    So my question is how does one perform point conversion in KSS 8.x? Is it that S bit 4 is no longer used? Do I have to use $SUPPRESS_ABS_ACCUR somehow to achieve the conversion?

    A colleague who generates offline programs in KRL tells me that S bit 4 is never used, either in KSS 5.x or KSS 8.x so we wonder how offline generated programs can ever be Absolute Accurate?


    So you see my confusion of trying to figure out how Absolute Accuracy is supposed to work across older and newer platforms without any solid documentation. Can anyone help?

  • Software Request to KUKA - the robot forum bugs and wish list

    I agree with everything in the thread - I think it's a brilliant idea. As a matter of interest, has KUKA been formally asked to comment on these suggestions so far?


    I remember on the RCM that had editions of KRL after KUKA took over SIRL from Siemens, there was a COMMAND mode, where a movement could be executed before being input. It was of great benefit to augment jogging in a particular direction. One could type in PTP {X 30, A 90} for example, then press Ausführen and that's where it would go with the active $TOOL and $BASE, without having to input it in the program. It's a shame we can't have that back.

  • KRC2 boot from USB

    KRC2 ED05 with BIOS V4.06 R1.05-08.1688.01. When attempting to boot from a bootable USB drive the BIOS correctly identifies the F10 key pressed and momentarily displays Press Ctrl-S for menu, but then proceeds with the Windows load anyway before allowing time to accept the Ctrl-S. The BIOS settings seem to be correct with USB set to legacy. It's a PS/2 keyboard. Any suggestions?

  • KRC2 mains filter

    Quote from panic mode

    well, you may not like this but one straight forward solution is get proper 3-phase service...

    If only that were possible! The rented workshop is on a farm and the cost of running 3-phase to the premises would be prohibitive. The only other commercial solution would be to change premises which is not feasible.


    Since the original post, the mains filter has been isolated from ground and the robot can now be powered up without tripping the RCD. However there is now an undervoltage error when running at more than 50% override.

  • Record TCP Position

    As an alternative to RS232 as described by SkyFire, and depending on the type of I/O installed (Profibus, Devicenet etc.), it may be possible to use 3 virtual analogue outputs and store the resulting values externally on the connected PLC (or PC) along with the sensor values. It should be possible for a 12ms update of the 3 cartesian values via the SPS sub as described.

  • KRC2 mains filter

    A colleague has recently procured an ex BMW KR140L120-B2 with KRC2 05 SR AK9 BMW L6 cabinet EU version. His workshop is not equipped with 3-phase power so he is utilizing a proprietary phase converter using a 3-phase idle motor as ballast to produce 400v delta 3-phase from 230v single phase. The problem is the RCD (residual current device) supplying the building trips when switching on the robot when the phase converter is already powered up. Even though the RCD has been exchanged for a higher tripping current version (300mA), the switch on tripping still occurs. He has found that if the PE (ground) connection to the robot cabinet is disconnected, the robot powers up without tripping the RCD.


    Looking through some old training documentation, I found that on the KRC2 specification page it says:- "Mains filter leakage current approx. 300 mA". Apparently this RCD tripping phenomenon is a known issue with KRC2 but I suspect it is worse in this case, due to the asymmetric-to-ground 3-phase supply. Is there a straightforward solution, perhaps by exchanging the mains filter for another type? What would be the consequence of isolating the ground connection to the filter? Of course an isolating transformer might also be the answer, but a simpler solution is preferred.

  • Workspaces

    Quote from panic mode


    i notice that you are asking questions rather than testing your theories on a robot. why?


    Thank you for your answers, all understood now. :icon_smile:


    I'm not testing on a robot until I can get back to it next week. As I won't have much time to play around due to production, I wanted to get as much prior knowledge to enable an expeditious implementation of the workspace function.


    I wondered if the Cylindrical workspace could be used with the origin reference as #TOOL which then could include the outline dimensions of the gripper or weld gun etc. Then one could have two workspaces that can interact with each other. This may be similar to Safe Operation which uses up to six spheres for the Safe Tool. But this is conjecture which until there is some solid documentation, is perhaps not useful.

  • Workspaces

    PM, Thank you for your comprehensive explanation, that aspect makes sense now. :icon_smile:


    Sorry, but now that leads to more questions. I notice that both:-
    $CYLWORKSPACE[1]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0,Z1 0.0,Z2 0.0,R 0.0,MODE #OFF,REFERENCE #WORLD,STATE FALSE}
    and
    $AXWORKSPACE[1]={A1_N 0.0,A1_P 0.0,A2_N 0.0,A2_P 0.0,A3_N 0.0,A3_P 0.0,A4_N 0.0,A4_P 0.0,A5_N 0.0,A5_P 0.0,A6_N 0.0,A6_P 0.0,E1_N 0.0,E1_P 0.0,E2_N 0.0,E2_P 0.0,E3_N 0.0,E3_P 0.0,E4_N 0.0,E4_P 0.0,E5_N 0.0,E5_P 0.0,E6_N 0.0,E6_P 0.0,MODE #OFF,STATE FALSE}
    are declared in R1\Mada\$machine.dat, whereas:-
    $WORKSPACE[1]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0,X1 0.0,Y1 0.0,Z1 0.0,X2 0.0,Y2 0.0,Z2 0.0,MODE #OFF}
     is in Steu\Mada\$custom.dat.



      • Does that imply $WORKSPACE[n] is not write protected, so that the variables in the structure may be written by the program? If so, then $CYLWORKSPACE[n] and $AXWORKSPACE[n] are fixed.

      • Why is there an origin reference in $CYLWORKSPACE[n].REFERENCE #WORLD existing but not in $WORKSPACE[n] which must be explicitly #WORLD? Then what are the other possibilities of the origin reference?

      • Cylindrical workspace is not described in the documentation. Can I assume the same origin definition as in Cartesian workspace (but perhaps with a non-world origin) with the cylinder having it's axis in Z with the centres Z1 and Z2 and the radius R?

      [li]In my example, the declaration of $WORKSPACE[n].STATE FALSE seems to be missing. Or is this by design?


  • Workspaces

    KR 120 R3200 PA
    KRC4 KSS V8.3.39


    I'm trying to understand workspaces. The documentation is quite straightforward and shows how both Cartesian and Axis-specific workspaces can be configured. We are told that a Cartesian workspace is a cuboid whose location and dimensions are related to the WORLD coordinate system. So far so good, however I'm having a problem with the definition of the point that may violate the workspace. Depending on the mode, the documentation refers to either the TCP or flange, and in one case also the wrist point.




    In the case of TCP, does that include the current $TOOL? Can it be that the choice of TCP, flange or wrist point can be defined elsewhere?

  • Velocity output

    Thanks Panic Mode,


    I used your suggestion with minor modifications and it works perfectly. My version looks like this:-


    It runs in the SPS.SUB in a while loop as long as the flag is active and the programme where the ANOUT instructions are called is in the correct state.


    The ANOUT call in the programme looks like this:-

    Code
    ANOUT ON CHANNEL_3=1.0*VelX
  ANOUT ON CHANNEL_4=1.0*VelY
  ANOUT ON CHANNEL_5=1.0*VelZ


    The variables are declared in the $config.dat and are initialised in the programme like this:-


    We are using the analogue outputs via Profibus to drive Beckhoff KL2521 Pulse Train Output Terminals to emulate pulse encoders. Up to 1 M/s on a 500 mm path the accuracy is quite good and better than 0.2mm. Using the while loop in the SPS seems to give a consistent cycle time of 12ms which means we are synchronous with the interpolation cycle.


    I understand there is an option with KRC4 to also be able to do this encoder emulation faster but this method on KRC2 with a 12ms IPO seems to be adequate for our purposes.

  • Velocity output

    Krc2 5.6.8.


    We are trying to output the real time TCP velocity of CP moves not simply as the path velocity $VEL_ACT, but as a 3D vector velocity. So we want to end up with three real variables say VEL_X, VEL_Y and VEL_Z which would also have sign, which $VEL_ACT does not, as it is the forward path velocity which is always positive. (Unless $VEL_ACT is minus when pressing start minus??)


    These VEL_ variables would then be output with three ANOUT instructions. The problem seems to be how to realise the task. Ideally we would need to build a Tech function that could run synchronously in the 12ms interpolation time, but the Function Generator documentation does not give many clues to how this could be accomplished. The other alternative would be to interrogate $POS_ACT cyclically within the SPS and to use the delta of each coordinate to generate the value, but it's doubtful whether such a method would be accurate enough.


    Have any of our KUKA Experts got any ideas?