Messages

Hi Chris,

Ah, that is super valuable information with the old controller generation. We had an option for that in KUKA|prc, but I never needed it in PRC so far. I have now backported it in the most recent release that I just uploaded at https://portal.robotsinarchitecture.org/download. It's now an option in the KSS-KRL code generation settings ("KRC1-KRC2 Legacy"). I've also attached an example SRC file - please check if that is accepted.

Regarding the memory leak, that is still very weird. We had a browser bug where a tiny indicator was taking up quite a lot of CPU/GPU capacity that has since been fixed, but it didn't touch the memory to my knowledge. My tendency would be to blame it on Eto and/or its WebView as it interfaces with native libraries and memory can get stuck more easily. What you could try is launching PRC.Server without the UI wrapping it. So in macOS, open a terminal and put in that command:

Code Select Expand

/Applications/PRC.Server.app/Contents/MacOS/PRC.Server --headlessIt will then only show the terminal interface and you can access the UI from your browser via

Code Select Expand

https://127.0.0.1:5001/
If you come across that again, please let me know.

All the best,
Johannes

Sorry, I must have missed that post. The error codes are in the documentation. 414 is timeout, so either a crash on the robot side or connection issues. 507 is wrong FB order. So maybe a network issue that messed with the communication?
Best,
Johannes

Hi Chris,

Hmm.. That's weird, thanks a lot for letting me know! I'll look into these things ASAP, however I need some more details to troubleshoot.

In my experience memory shouldn't be a problem, unless you have several millions of robot frames. And garbage collection usually prevents these things in managed languages, not causes them. GC may just introduce lag while it's working.

That being said, it's totally possible that there is a bug that is causing the issues. Do you have a specific file I could look at? And what is "quickly" in that context? Like within a few minutes?

There is a drop-down for selecting your KSS version as there are some slight compatibility changes between them. What KSS version are you running and what kind of error are you getting?

Best,
Johannes

Hi Chris,

In the PRC settings, you just need to tick the Save File box. The default directory is your Desktop, but you can change it in the settings as well.

Please let me know if that works! As PRC is in very active development, it might also be a bug or one of the many safety measures of macOS, if it's blocking the file generation. If there are issues, I'll try to resolve them ASAP.

Best,
Johannes

Sorry, I phrased that wrong - you are right of course that A4 is the missing axis compared to the regular 6-axis version.
If you say that A4 and A6 are doing "the same", does that mean that A5 is 0? Then you are in an area that is a singularity for 6-axis robots. If KUKA shares a lot of code with the 6DOF version, then this might still be problematic with your 5DOF robot.
What kind of movements are you using? PTP? LIN? Axis?

Best,
Johannes

Hello,

But if it is a fivve version, it is missing the sixth axis. Could that be the reason?

Best,
Johannes

Hello,

I've attached a ZIP file with some Rhino/GH files and a Word file with links to the tutorial videos. They were made during the lockdowns, but the general concepts still apply!
Hope that helps!

All the best with your new robot!
Johannes

Hi,

That went better than expected. I'll send you an email with something to test in a minute!

Best,
Johannes

Hi,

Unfortunately that doesn't exist yet. Honestly it is one of the features where I didn't know if anyone was actually using them.
It might be simpler to implement it on the Grasshopper side - I'll check if I can introduce a setting override for that and put together some simple code. But that will take a while to integrate...

Best,
Johannes

Hello,
I recently fixed some issues, send me an email if your issues is still current and I can send you a new build!
Best,
Johannes

Hi Sam,

That shouldn't happen. We had some issues with tiny arcs that the robot controller really didn't like, but those are resolved in the import code. Are you sure that the units are accurate? That would be my first guess - that your file was output in m and therefore the arcs are 1/1000 of their actual size and replaced with lines.
If you can share a file, I can take a closer look!

Best,
Johannes

Hello,

But if you compare the two screenshots you shared, the new model is of much higher resolution?
If you need to go even higher, you would have to define a Custom Robot. I can help with that, if needed. The integrated robots have to take a middle ground between resolution and performance.

Regarding the singularity, you can change the Singularity Factor in the Analysis graph window if it is not sensitive enough. Otherwise I can also take a look at the file - if it's confidential, you can send it to me via email as well, of course.

Note that the goal of the singularity checker is to identify areas where the axis speed is exceeded. Maybe you are going through a singularity but slow enough that it isn't a problem. Are you running the robot at 100% AUT speed? That can also help. Of course you need to be careful so that a proper speed is used, as the robot will try to exactly match the programmed speed. But the robot runs "best" on 100% AUT, compared to let's say 20% T1.

Best,
Johannes

Hi,

You must have enabled the low-resolution robot model in the Advanced Settings - then it will show up nicely again.
There is no real reason to use that unless you are displaying 100s of robots for some evolutionary optimization algorithm.
And KUKA|prc should highlight potential singularities in yellow in the Analysis graph! Please take a look if that matches with your experience!

Best,
Johannes

Hello,

I guess you are referring to singularities, in your case most likely when the wrist (A5) is close to 0, so around when the object reaches the height of the robot?
Unfortunately there is no easy fix, the best levers are to change the position of your work object and the angle of the tool holder. But that only postpones the singularity to another point in the process.

Beyond that there isn't that much you can do, singularities are inherent to the standard industrial robot kinematic setup. Technically you could try to use tightly spaced PTP motions on areas where singularities occur (with a switch in posture where A5 transitions), but I would say that something like this is only useful, if you produce an object many times and you can afford the time to hand-tune everything, with some verification cycles on the actual robot.

Regarding the screenshot: In Rhino, right-click the name of your viewport in the upper left corner of each viewport. Like "Perspective". Then go to "Capture" and select either Clipboard or File. In the next window you can then also set a multiplier for the resolution.

Best,
Johannes

Hi Kailey,

I wrote back with some troubleshooting steps.
My best guess at the moment is that the robot model isn't the right one.

Best,
Johannes