Messages

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

Hello,
Sorry, I didn't explain it properly - for the OxyPlotSimpleDemo.zip you would need to run the included SimpleDemo.exe and see if OxyPlot shows up. You don't need to replace any files with it. It's just a window with a simple graph.

One more idea: You could run the GrasshopperDeveloperSettings in Rhino and see if there are any other folders there. Default should be no folders and COFF disabled.

Best,
Johannes

Hello,

I still don't have a solution and assume that there is another version of OxyPlot messing with KUKA|prc.
We updated OxyPlot to 2.1 in February 2022, so you could try that release: https://forum.robotsinarchitecture.org/index.php/topic,1248.0.html (with no KUKA|prc showing up as installed in the PackageManager)

To rule out OxyPlot itself as the culprit, I built the https://github.com/oxyplot/oxyplot/tree/develop/Source/Examples/WPF/SimpleDemo app and included it as a ZIP. You will most likely need to unblock the ZIP file before unzipping.

It's a bit poking in the dark, sorry that we cannot offer a quick solution...
Best,
Johannes

Hello,

What do you mean by "KUKA|prc is still installed within the Package Manager"?
Because that is what you should avoid. It should be either in the Package Manager OR in the Component Library.

These two options are completely separate and may collide with each other. Especially if the libraries exist twice in there.
Software from the Package Manager ends up in %APPDATA%\Roaming\McNeel\Rhinoceros\packages\8.0 while the Component Library is in %APPDATA%\Roaming\Grasshopper\Libraries

Regarding your concerns about NET version, OxyPlot supports NetStandard2.0 which is compatible with both Core and Framework. While I don't see that having any effect, you can try changing Rhino 8's runtime via SetDotNetFramework - restart it afterwards for the change to have effect.

Best,
Johannes

Hello,

Hmmm... Thank you for following all the steps, that error is very weird.
The OxyPlot that KUKA|prc is using is slightly outdated, I've attached the 3 DLLs of the most recent version. It might be worth trying to replace the older DLLs with the same name. You will very likely have to right-click/Properties/Unblock the ZIP/DLL files. Also your browser may complain because of safety concerns. You could also get the files from the NuGets here: https://www.nuget.org/packages?q=oxyplot
I tested it here and it seemed to work without any issues on my laptop.
If that still doesn't work, I can try to make a special version for you to support the troubleshooting.

Best,
Johannes

Sorry to hear that it is still causing issues!

I wrote the text below and will leave it for troubleshooting. In your case however, I'm pretty sure that the problem is that you have got KUKA|prc installed twice. You have to install it EITHER via the PackageManager or the Component Library. As you have got access to the member version which is updated more frequently, I would recommend removing it from the PackageManager.

//////////////////////

Here are the troubleshooting steps in more detail:

1) Make sure Rhino is closed.
2) In the Grasshopper Component Library, temporarily move all files and folders except for the KUKAprcGH folder into another folder
3) Go into KUKAprcGH and check if it contains the following files:
KUKAprcCore.dll
KUKAprcGH.gha
KUKAprcLibrary.dll
KUKAprcLibraryWIN.dll
KUKAprcLicense.json
Newtonsoft.Json.dll
OxyPlot.dll
OxyPlot.Wpf.dll
OxyPlot.Wpf.Shared.dll
System.Drawing.Common.dll
System.ValueTuple.dll
4) Start Rhino again, check if the settings work now.
5) If not, run the "PackageManager" command. Temporarily remove any installed plugins
6) Restart Rhino
7) Test again

If any of the tests is successful, you can start re-adding components to see which component collides with KUKA|prc.

Hello,

I found it in the error list but it does not provide any information on how the remedy it.
It is listed as error 1053 "CP-Vel. reduction point <point name> <dummy> by <reduction in %>"
I would just contact the KUKA hotline as it seems like a straightforward question. Maybe it is related to the linear axis, because we did plenty of projects with C_VEL and I never (knowingly) got that message...

Best,
Johannes

Hello,

That does not primarily sound like a pathplanning-related issue but more related to the robot setup.
I also wasn't able to find an error message saying "speed reduction at point..." - does it have an error number? Alternatively it might be something that was specifically implemented for your robot. Like a short code in your sps.sub comparing programmed speed to actual speed.

It is common that the robot slows down when it is close to singularities etc., but it usually will not create a specific error message for that.

Best,
Johannes