Search

Hello Andreas,
Perfect!

The problem with the robots is that there are so many aspects where you can tune. For example for the lower parts of your test piece, a different tool geometry would help a lot, but in turn would cause problems further up. Then the position of the 3D print within the robot's workspace makes a big difference, and of course also the orientation of the tool within the constraints of the physical process.
A dedicated software could have some optimization strategy ready to help, but KUKA|prc is used for countless applications, each with different parameters, so that is more up to the user. That being said, at least for prototypes, intuitive interaction with the parametric object is often faster than setting up an optimization process - that is one of the strengths of GH as a platform, in my opinion.

Best,
Johannes

Hello Andreas,

I had a longer look at your file, the general programming strategy looks sound, but I cannot find an "easy" solution for your toolpathing. Especially the lower part has got an extreme angle that leads to the robot winding itself up and/or colliding with its own tool.
Also, if your extruder is a pellet extruder, can you even print these steep angles? I would be concerned about that as you usually need gravity to feed your pellets.

With a less extreme lower curve and some tuning on the position (better do that via the base values, though) you can get a similar project to run, see my attached file.
If you want to print exactly what you have, you are probably going to need a turntable. Or mount the build plate onto the robot and place the extruder somewhere statically.

Best,
Johannes

Sorry, I cannot really help you there as the CNC tool fabricators are often quite "regional".

What I can share is that one of our collaborators bought huge foam milling bits (like 40cm long) from China for quite cheap (like 1/4 of what we would have paid in Germany) and all three would start to vibrate a LOT before even reaching the RPMs recommended in the manual. Fortunately one was balanced enough so that we could use it. That made the deal not as great as it seemed.

Also, that Chinese company tried to declare the value of three huge milling bits as 20USD, which customs also did not appreciate and delayed their arrival.

So rather than looking for a reliable, international tool fabricator we personally switched back to using a local source.

Best,
Johannes

Hello,

Thanks for the update, good that it's working now!
Maybe you had a wrong tool or base number set?

Best,
Johannes

Hello Andreas,

Thank you for getting in touch! I had a look at your file, unfortunately the three curves at the beginning are missing, so I cannot look at your exact problem.
Regarding unpredictable movements, I only see in the settings that you have "Interpolate Movements" un-selected, which I do not recommend for a reliable simulation. For further troubleshooting it would be great to get the complete file and a clearer description what "unpredictable" means in that case.
Also, I have changed your username so that it does not consist of your eMail address, assuming that you do not want that to be too public.

Best,
Johannes

Hello Sina,

So the smartPad is not properly booting up, and I guess that you cannot deploy a new WorkVisual project?
If you have got a backup of the robot software, I would personally just put on that image and then deploy the most recent WoV project.

And while I don't know if that is the case with EasyHMI, KUKA sometimes likes to put files in multiple places.
So you could attach a display, mouse, and keyboard to the controller and search for your file name in the Windows Explorer.

If you don't have a backup image, I would take this as a prompt to make a backup once the controller is back up and running. The most convenient way is the KUKA Recovery.Stick, but you can of course also just remove the SSD, attach it to your PC and make an image with any other backup software - Macrium Reflect Free works well, in my experience.

Best,
Johannes

Hello,

If the axis limits problems include A4, there is a good chance that singularities are involved For singularities a slightly different robot model, tool/base values etc. can cause a significant deviation between physical and simulated robot.

As the first step I'd suggest a quick plausibility check: Choose a (= one) position somehow representative of the area that is causing errors.
In the advance settings, tick the box "Skip End position" / "Halt at end position" (depending on KUKA|prc version) and run the program. The robot will stop at exactly that position.
Then compare the axis values shown in the simulation with those on the physical robot. If they are not very close, double-check tool and base values and the robot type.

Best,
Johannes

Awesome, thanks for the update! If you aren't using the gripper for another software, I'd change the values there instead. But either approach is equally good and correct.
One more comment: Your gripper mesh seems very high-detail, I'd recommend to mesh it, join the mesh and then use ReduceMesh to get it down to 5000 vertices or so. That will improve performance a lot.

Best,
Johannes

Hello,

When you set up the values for the Custom Tool component, did you choose the same values as on the robot, or choose values that seemed to look right?
My guess is that your tool was calibrated with another tool axis in mind - KUKA|prc has got a slightly strange standard there that can be confusing, we are aware of that...
From looking at your screenshot I would expect the tool to be something like 0,0,300,0,-90,0 in KUKA|prc

But no matter what tool axis is used, if you enter the same values on the physical and simulated robot, the movement should be identical. The tool axis only defines how the Grasshopper plane is interpreted, it does not change the internal robot logic and you do not need to "change a toolaxis" in the code or so.

I would recommend:
Check if the values are identical.
If not, choose a set of values and go with that one - you will then either have to change the physical robot's ABC values via "Numeric Input" on the smartPad, or alternatively you need to setup your planes in Grasshopper differently. Most likely Deconstruct Plan followed by a Construct Plane where you use Z for X and Y for Y should do the trick.

Please let me know if that solves it. If you are really getting a different simulation with identical XYZABC values for tool and base, please send me the file!

Best,
Johannes

Awesome, thanks for the update!
Best,
Johannes

Hello,

I would need to know which university so that I can check if the license is still valid. You can also send me an eMail if you do not want to share the information in a public forum!

Best,
Johannes

Hello,

Thanks for getting in touch!
Can you provide some more information on your license - are you using a member license, e.g. through your university, or were you using a Community Version?

Thanks,
Johannes

Hello Gergely,

Hmm, so you have got your Cartesian World and Cartesian Base coordinate system.
My guess is that there was a mismatch somewhere, so you either moved the robot in Cartesian World but displayed Cartesian Base or the other way around.
Is that possible?
It usually shows the Cartesian position of the currently activated base (see towards the top of the smartPad, next to the tool number) and on the right there is the World movement (globe icon) and the Base movement (plane icon) type.

Best,
Johannes

Hello Luigi,

I just checked your file, it did not contain a single movement command, which confuses KUKA|prc.
I will make sure that this will result in a proper error message in the next release.
For now, just add an axis movement somewhere and it should be fine!

Best,
Johannes

Hello Luigi,

Can you please send me the file that is causing the exception via eMail?
Take electronics advice from me with care, but Beckhoff IO units have got many different configurations, I don't know if yours have got a separate ground port. But if you are e.g. switching an electronic gripper, then I would personally try to either power them from the same power supply or alternatively connect the grounds. But again, don't trust me with electronics ;)

Best,
Johannes