Messages

Hmmm... The easiest way might be to use axis movements in between larger movements.
So the robot finishes a path, moves in Z away from the object, makes a PTP movement to a safe position while the turntable rotates, then moves back and continues your linear motion paths.

You will need to identify paths with significant repositioning time (e.g. by comparing the E1 values), because if it just moves 20mm, then in turn the PTP motion is a major waste of time.

Best,
Johannes

Hello, unfortunately while you provided a lot of details, I cannot fully troubleshoot it remotely. Some thoughts from my side:
It reads as if axis movements are accurate, this is why the first movement works nicely.
The rest points either to a wrong base calibration (should be offset base, not the normal base calibration!) or an error in the axis setup. Maybe the external axis is turning in the wrong direction or E1/E2 are switched?
"Wrong" being only in relation to the simulation, there are plenty ways to set up external axes.
Best,
Johannes

Hello Martin,

Just thinking out load here, but could you simulate the toolpath in high accuracy, output all axis values from the Analysis component and then simulate the path by extracting a single set of axis values from that large list and displaying it / doing whatever you need to do with it?

So you get a fine, interpolated list from the first simulation pass and then use a second Core component to simulated the selected set of axis values.

Otherwise, we are internally using a new version of PRC that enables that quite a bit easier.

Best,
Johannes

Hello,
I'm not 100% sure that I understood that correctly, but you can set the value of the external axis by right-clicking a movement component and selecting the option to show inputs for the external axes. So I guess adding 180 degrees to E1 would put it on the other side.
I would recommend looking into some of the samples for optimizing the external axis position - the automated solver is not optimal in many cases - especially for a DKP.
Best,
Johannes

...I now saw how they do it at 11:15 in the video - then you would need an external axis to rotate your part.
Best,
Johannes

Geometrically, doing something like this is definitely possible, however you need to take into consideration that a lot of work went into a program like the one you linked to. So I would strongly recommend not to look for "universal solutions" that do everything, but to pick a challenge relating to your project and start with that.
I have put together an example using an external tool, which should be useful for winding. The example does not show a proper winding toolpath, though.

Best,
Johannes

Hello,

I'll try to put it into an example.
You have got the offset from the robot to the turntable, let's say X=1000 and Z=500
Then you define an offset base, that is slightly higher, so Z=100.

If we now make a PTP movement to 0/0/0 and set a base that is tagged as an offset base, the robot will move to 1000/0/600 in absolute terms - however in the KRL file it will say 0/0/0.

If you don't set an offset base, the absolute position will be 0/0/100 instead. It will still say 0/0/0 in the KRL file.

The offset bases are in the normal list of bases, they just get an extra tag when you calibrate them as an offset base.

Does that make sense?
Best,
Johannes

Hello,
That is interesting, is it on the same KUKA|prc version?
Best,
Johannes

Hello,

My guess would be that you did not calibrate the base as an offset base. An offset base is constrained to an external kinematic system, so in the case of a turntable it rotates along with it.

Please give that a try! When you calibrate an offset base on top of a turntable, you will get very low XYZ values as it is in relation to the turntable, rather than in relation to the robot.

Best,
Johannes

Hello,
If the robot isn't following its toolpath accurately, then this can indicate a problem with its mastering. Have you got an EMD to check the mastering?
Best,
Johannes

Hello,
I see what you mean, it makes a full circle and then goes back to the seam along the circle and from there goes to the next layer.
However, considering that these are basically all LIN movements, I don't really see how this could be coincidental. Are you sure that in your slicer it's only doing it once?
Also, your G-code is around 1000 lines and generates around 700 LINs - considering that there is a lot of header, that sounds very plausible - I don't think that a bug is generating extra movements somehow.
Best,
Johannes

Hello,
That was a bug, it will be fixed in the next release - thanks for pointing it out and sorry for the inconvenience!
I can send you the fixed release in advance, I just need your eMail address plus your affiliation (as the Import component is a member-only component). Please send me an email with that information (johannes@robotsinarchitecture.org).
Best,
Johannes

Hello,

Can you post (or send me) your file including the g-code? Generally g-code is a very wide term, so it might be a parsing problem.

Thanks,
Johannes

Thanks a lot for sharing the solution, I'm glad that it's working now!
Best,
Johannes

Hello,
Of course that is not a problem at all.
I modified the example from the tutorials section, it is using a grid for pick up, but instead of a grid you could also use the Series component to set the pick-up height on the stack - then create XYZ points where Z is coming from the series and X and Y from the position of the stack.
Best,
Johannes