Posts by Mentat

Quote from panic mode

still... it would be nice of KUKA to include this in modern documentation. the last time this was mentioned is a quarter of a century ago. and it is not going to happen unless there is enough of pressure from users.

so any wishes on software/hardware/documentation updates should be forwarded to KUKA and mentioned in

Thread

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

Post here your suggestions to KUKA for the improvement of the robot software.
Report bugs and security risks for KUKA Robots.

The KUKA development looks in here to implement ideas for updates from operators and programmers!

Thanks for your suggestions, maybe they will be included in the next update.

Werner Hampel

August 17, 2019 at 10:37 AM

At least in 8.6 System integrator's manual these are documented, with error tables even

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.

Are there no motions in this procedure or are there other reasons you don't want to use a trigger?

Quote from Dbonds28

hey im having the same problems

Open the box with the X32 connection and see if maybe the wires are pulled in? Or did you do that already and it was ok?

You will have to roll your own.

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

 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.

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.

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?

Would linking the turntable to the kinematic system as a synchronous axis not be easier, simpler and have less points of failure?

Is base the same as in the simulation?

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.

Would be valuable to know (for cost/benefit) if these parts will be constantly changing- the program creation will be an ongoing process or if these programs will be created once and used for years.

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.

Quote from roboter123

Many different parts, but if I could perform this operation once the automation of the process would be least concerning.

Then either a standalone simulator or an add-on for CAD/CAM software.

Do you want to do this on one part once or on many different parts ( looking to automate this process)?

I maybe gearsimple, but why not use an actual timer and/or a state machine?

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.

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.

Just like Workvisual, I also can't see the declaration of that function. That's a good direction to start looking.

On an unrelated note, had anyone heard about any breakthroughs in technology to be able to post and save code as text instead of as a screenshot? Or would such a thing be possible only on quantum computers?

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

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

GLOBAL BOOL RuntimeError=TRUE;

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

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.