Messages

Hello,
Unfortunately I don't have any insights into edX, but their help text says:

All edX courses have a set end date after which the course is no longer supported by staff and it is no longer possible to complete the course for a certificate.

Most edX courses remain available as archived courses after the course ends. In an archived course you can view most of the course materials, such as lectures and readings.

Do you have problems accessing the course materials?
Best,
Johannes

Hello,

Your last sentence is correct - the robot simulation is not 100% accurate. While the position of the robot on the path gets very, very close, the acceleration and deceleration ramps are complex, not documented and therefore not 1:1 implemented. But they have got a big impact on singularities, i.e, when/if an axis exceeds its maximum speed.
The factors allows you to fine tune the sensitivity, if needed. It's mostly useful for automated processes where you e.g. want to minimize that to a certain degree. Or if you are bothered by the component showing that message as a warning.

Best,
Johannes

Hmmm... I think the way to go would be to define a single TCP and then calculate the offset from the path geometrically in Grasshopper.
Just an idea: You could try to set the TCP to the center of the wheel and offset the toolpath according to the wheel radius. That should ensure that no part of the path could damage parts of your part.
If it's more complex than that, you could look into physics/particle simulation like Kangaroo to define some constraints for your wheel.

Best,
Johannes

Hello,

You can change tools during a process and combine multiple tools. You could even create a tool with one tip on one side and another tip on another side.
Just take care that KUKA|prc is not a dedicated milling solution, you can create custom strategies yourself (which many users are doing with much success, but it needs some advanced Grasshopper knowledge to do so) or import G-code from e.g. Fusion (with the member or commercial version, or by writing your own importer).

Hope that helps!
Best,
Johannes

Hello Rodrigo,
Regarding the protocol, the shield would take care of it. Depending on how it is configured it will accept different data types, the most common one are unsigned integers. If that is the case, multiply the number by e.g. 100 before sending it and on the Arduino divide it by 100.
For the analog signal, be careful that the most industrial IO devices output either 0-10V or 4-20mA, and both will cause issues with an Arduino. You can try to limit the range on the 0-10V to something like 0-3V I guess, but lose a lot of resolution by doing so. Plus if something goes wrong the 10V might roast your Arduino.
And regarding the variable, I just can't look up the right variable now, probably something like $ACT_VEL.E1 for the E1's current speed - please take a look at the KUKA System Variable documentation. For WoV, there are plenty resources online, starting from KUKA's own documentation to YouTube (e.g. https://www.youtube.com/watch?v=CQom2cNDMt8)
Best,
Johannes

Hello Rodrigo,

The advantage with an external axes is that the robot takes care of the synchronization of the movements. So E1 in your example will start exactly at a given position and at the end of the movement will be at the programmed target position. However, you need to use original KUKA motors for external axes.

What we did in the past was that we added a simulated axis in WorkVisual (tick the according box). On the robot, you have got the sps.sub, which runs in a permanent loop in the background, like a background thread. In the sps.sub, you can now get the actual position of E1 and e.g. map that to a signal that is connected to a microcontroller, which then controls your stepper motor in the extruder.
For connecting the Arduino, a nice way would be an EtherCAT shield like that: https://www.bausano.net/en/ethercat-arduino-2
That way, you just have got one Ethernet cable going to the Arduino with all the data.

Rather than the position of E1, you might only want to output the speed of the E1. Just look for the according KRL variable. A speed variable is also more easily mapped to an analog output, compared to an absolute position value.

All of the above needs good knowledge of WorkVisual, but nothing that is super hard to do.

In KUKA|prc, to set the E1 value, right-click the motion component and enable to option to show external axis values!

I hope that helps!
Best,
Johannes

Hello,
First of all, thank you for the excellent preparation of the file, with nicely internalized planes and without tons of external plugins.
Fortunately the error was easy to spot, at the very beginning you decompose the planes to calculate the angle for the rotation. In your file, you calculate the angle between the Z-axis of the target plane and the global X-axis. Because the Z-axis changes in tilt, you get the change in orientation.
Using the Y-axis instead makes it consistent, in my testing.
Best,
Johannes

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