Messages

Hello,
I would see state machines and behavior trees as typical examples for such design patterns, yes.
The reason why there isn't a standard is probably the lack of standardization in robotics.
What is a reasonable approach with software X may be completely different in software Y - e.g. the geometry-heavy, visual programming based approach of Grasshopper versus how ROS is used.
Same applies to robot brand X versus robot brand Y.
So unfortunately I cannot offer any good advice here...!
Best,
Johannes

Hello,
That seems to be working as intended, the last value is E1=90 at then you defined the straight line with E1=0, so you have got the 90 degree turntable rotation in-between.
I cannot really think of a easy way to get rid of that (technically you could rotate the line by -90 degrees and keep E1=90, but that is a bit of a hack). But if the turntable movement is slow I would just use a PTP movement between the end of the spiral and the beginning of the line. That should speed things up!
Best,
Johannes

Hello,
I see that your Base 4 is all zero, could you try to calibrate it via 3 points? The resulting values should be in relation to the origin of the turntable (rather than the origin of the robot). So very low numbers if it is close to the root point of the turntable.
Best,
Johannes

Hello,

Sorry, I don't know the terminology of KSS in French compared to English and German, so I have to ask again: Did you calibrate the base as an offset base, rather than a normal base?
With an offset base, if you rotate E1 in a Cartesian movement mode, the robot tool will keep its position in relation to the turntable, i.e. it will rotate around the tool axis.

Best,
Johannes

Hello,

I looked through the video and it looks like at the beginning with the external axis at 0 everything is fine, but then it starts to differ. Did you calibrate the base as an Offset Base, or as a regular base?

Best,
Johannes

Hello,

I cannot say much from the screenshot, but usually the KUKA would not stop while repositioning, all the movements are done in parallel. So stopping would happen if you have got very little TCP movement but a large change in the turntable.
However I notice that you are providing extremely tiny values, like 0.03 degrees if that is a turntable. Maybe your point density is simply too high?

Best,
Johannes

Hello,

For the G-code import if you set the mapping to e.g. E1 it maps the extrusion to an external axis, with e.g. D1 it maps ON or OFF to $OUT[1]. The external axis should also work without a physical axis attached (you may need to configure a simulated axis, but try it without it first). On the robot via the sps.sub you could map the current E1 speed to an analogue value that gets output to the extruder.
Just an idea!

Best,
Johannes

Sorry, that is very hard to troubleshoot remotely. Are you sure that it would crash and that you haven't just moved the table geometry in Rhino to the wrong location in relation to the robot?

Looking at the screenshot of the tool I would assume the the tool is not mounted the same way as you placed the mesh.
I would recommend moving the robot to it's standard position (0, -90, 90, 0, 0, 0) by hand and then looking at the tool. If it's not looking downwards, rotate A6 until it is and then rotate the mesh geometry with the same value so that they match.

Similarly to, activate the same tool and base as you are using in KUKA|prc and manually move the tooltip e.g. to the calibrated origin. Then look at the axis values. Enter the axis values e.g. as start values in KUKA|prc, move the simulation slider to 0 and then see if the tool is pointing to the Rhino origin as well.

Best,
Johannes

Hello,

From the screenshots it looks like you are doing everything right. The tool and base values look plausible and in the visualization you see that the XYZABC of the tooltip also matches with the mesh of the endeffector.

Do you maybe just need to place the toolpaths somewhere else? In KUKA|prc the base origin is always the Rhino origin. So if you calibrate for the corner of the table, place the table at the intersection of the coordinate axes.

Best,
Johannes

Hello,

In your screenshot it shows that you are using base number 6 with XYZABC all set to 0. Can you double-check that base 6 is also set to zero on the robot? KUKA|prc by default only references the base number but does not overwrite the current base numbers. That can be useful if you e.g. mount a new piece that is only off by a few millimetres.

Best,
Johannes

Hello Luigi,

How are you currently controlling the extruder? With the method that maps just to a digital output for on/off?

Best,
Johannes

Hello,

The Custom KRL component allows you to add any commands to the output KRL file. Just note that those commands won't be simulated.

Best,
Johannes

Hello,

That applies primarily to processes like milling where the rotationally-symmetrical tool provides you with a degree of freedom for optimization. So rotating around the tool axis will leave the process mostly identical, but may greatly improve reachability.

Best,
Johannes

Hello,

In that case, here is an example!

Best,
Johannes

Hello Luis,

We did not really optimize the code in order to be readable for external users, so take that under consideration.
That being said, attached is an example how you can write your own LIN movements, the other types work similarly enough. I would recommend going through the KUKAprcLibrary.dll rather than the more abstract KUKAprcCore.dll (where the classes are originally located).

Best,
Johannes