Posts by Mentat

  • Easiest way to handle multiple set of points for same cycle

    Hi,


    I am merely an uneducated pleb and so don't know of any canonical ways. I do like setting things up in way that requires least work/effort.


    If I understood correctly, the amount of points, their order and respective motions should not change. A subset of points will need to have different positions depending on the parts being worked on. If these assumptions are correct, I would do something like this:


    1. Initialize and define the points that should not change in some public dat file as consts.

    2. Make a file that is going to be copied for every new loading program with the points that need changing. Protect them with a flag to avoid unintended execution (something like _TouchUpOn and $T1). This is the module where the operator will touch up the points.

    3. At the end of the program above have a call to a function in a different module that is going to actually execute the desired motions with the touched up points as parameters (better as pos array).

    4. Profit immensely as now all the operator has to do is duplicate a program, give it a name, enable _TouchUpOn flag, turn on $T1 and touch up the needed points. Afterwards just run the program every time it's needed.


    This seems so simple that I probably misunderstood the problem.

  • Kuka : How to round off values to lowest whole number

    You will have to roll your own.


    I used my knowledge of advanced pancake chromodynamics and came up with this:

    Code
     DEFFCT real Floor(FloorThis:in)
   decl real FloorThis
   decl int IntComp
   
   IntComp = FloorThis
   If (IntComp - FloorThis) > 0.00001 THEN
      IntComp = IntComp -1
   ENDIF
   return IntComp
ENDFCT


    Ought to work for most use cases.

  • Kuka run slow

    Quote from Evan94

    Thanks a lot. I am a newer here, in my case, the first one seems be helpful for me, how should I group them? Could u show a sample?

    Something like this:


    Spline

    SPL{X -11.96,Y 9.16,Z 30.41,A 0.0,B 1.58,C 178.79}

    SPL{X -10.53,Y 11.79,Z 30.44,A 0.0,B 1.39,C 181.56}

    SPL{X -9.6,Y 13.41,Z 30.46,A 0.0,B 1.27,C 181.77}

    SPL{X -8.69,Y 14.87,Z 30.49,A 0.0,B 1.15,C 181.96}

    SPL{X -8.26,Y 15.5,Z 30.51,A 0.0,B 1.09,C 182.05}

    SPL{X -7.83,Y 16.08,Z 30.52,A 0.0,B 1.03,C -177.88}

    SPL{X -7.47,Y 16.54,Z 30.53,A 0.0,B 0.99,C -177.81}

    SPL{X -7.12,Y 16.96,Z 30.54,A 0.0,B 0.94,C -177.76}

    SPL{X -6.77,Y 17.34,Z 30.55,A 0.0,B 0.89,C -177.71}

    SPL{X -6.43,Y 17.68,Z 30.56,A 0.0,B 0.85,C -177.66}

    SPL{X -6.1,Y 17.98,Z 30.57,A 0.0,B 0.81,C -177.62}

    SPL{X -5.77,Y 18.24,Z 30.57,A 0.0,B 0.76,C -177.59}

    .

    .

    . {about 40 more points goes here}

    endspline


    If you make the blocks too large, the robot will stop for a while before each block.


    This is assuming you have a controller that supports splines.

  • Kuka run slow

    The robot stops after reaching those points. Group them up by 40-50 and put them into spline blocks, that should speed it up considerably. Another measure is to reduce the amount of points, maybe turning them into splines would be worth the effort?

  • Kinda Lost between all of those options

    If you just need a proof of concept then I would say write the KRL code by hand. Not very innovative, but short of running free trials of the programs, cheapest solution. Keep in mind the full project might not get a green light even after successful prototype if the plant management decides they can't afford the space/insurance/blood sacrifice/investment/disruption.

  • Offset a target point

    If you are new and/or in a hurry reading about bases might be quicker/easier.

    Do keep in mind offsets with geometric operator will not stop advance run pointer, while changing $base - will.

  • Tracking distance travelled by TCP for adhesive refilling

    Hi, some alternative solutions:


    Why not put a sensor or three (depends on the shape and whether the cartridge is attached to the robot) into the cartridge? Then you could just see when it's empty from the inputs, no guesstimation needed.


    Could run a procedure in a submit that adds differences between previous position and current one when some flag is raised. No need to calculate movement lengths then. It's not going to be as mathematically rigorous due to timing issues, but I am going to assume you don't intend to use all the liquid/gas down to the last molecule :) Also significantly easier to implement coding wise.

  • KUKA INT to REAL

    Quote from panic mode

    and screenshots are NOT the proper way to share the code. if someone is to reproduce issue, it would take a more effort than necessary - retyping it. post the code as text


    It seems the ancient techniques of transforming code into text are being lost. We maybe the last generation to use such antiquated measures, so stuck to our old ways.

    Maybe it's unreasonable to expect the youngsters to go through the harsh training necessary for gaining the skill set.

  • Stop program when position is reached

    First, in StopScan(), make sure you actually want

    Code
    brake F; Stop robot motion

    instead of simple brake.


    The reason why interrupt 4 never gets activated- interrupts are triggered by rising edge and you already have

    Code
    GLOBAL BOOL RuntimeError=TRUE;

    that I suspect is not set to false anywhere outside the interrupt routine.

  • Krc4 mastering

    Quote from CGarza

    Hello everyone i have a problem with mi krc4 i cant configure the mastering position reference and i cant turn on the axis motion

    Is it because there is no electricity in the area where robot is located? Don't have the physical access to the robot? Is the robot disassembled into parts or melted to slag? Encased/submerged in something? Is a fixed point in a time paradox?

    I guess we will never know, unless we find a way to somehow discover what you want to do, already tried and what happened.