Messages

Hello,

Regarding the offset system: If you place the offset system close to the root point of the turntable then VERY small numbers are totally fine.
When you calibrate an offset system, it gets saved along with the regular bases, just with an additional tag declaring it an offset base. So just use the number you chose at the beginning.
You set the root point of your turntable by right-clicking the turntable component.
The dynamic vector can be tricky at times, for those occasions you can also create your own strategy, see the attached example for defining your own rotary table strategy.

Hope that helps!
Best,
Johannes

Hello,

I'm sorry if that was unclear, but at the moment there are no different CIRC movements supported.
We would need to integrate that specifically, which takes time.

For now what you could do is simply to split your 270 degrees circle into two 135 degrees circles, I guess then it should work as you want it., with the tip keeping the orientation towards the middle.
Personally I'm not a huge fan of either CIRC or SPL, usually I try to use properly spaced LIN commands with good interpolation parameters.

Best,
Johannes

Hello,

Something like in the screenshot should work, but it will not be simulated.
So while it looks identical in the simulation, it will work differently on the robot - which can be dangerous.

Best,
Johannes

Hello,

I don't really understand what you did there - you took a *.src file and embedded it into a Grasshopper program? KUKA|prc needs at least one movement component, I'll need to make sure that a single Custom KRL component triggers an error message from now on.
KUKA|prc will not simulate the contents of a Custom KRL component, it's mostly for e.g. triggering specific variables etc.
So you could make a Custom KRL component with $ORI_TYPE=#PATH but it wouldn't be simulated.

Hope that makes sense!
Best,
Johannes

Hello,

I'm not sure how you wired that up, can you send me the file?
Please be aware that data input into Custom KRL gets written into the *.src file, but is not simulated.
And no lines should disappear...

Best,
Johannes

Hello Andreas,

I don't have a Mac to try it, but I would assume that the components might work, but the UI definitely won't.
So until we find the time to re-do the UI in a nice looking, cross platform UI library, it unfortunately won't be of much use on a Mac.

Best,
Johannes

Hello,

Thanks for sharing the screenshots! We'll auto-activate the "Output Analysis Values" option in the next release.
The default behavior is that KUKA|prc generates the *.src file in the background, with the project name and directory as provided in the first page of the settings. The output within GH is mostly meant for special cases, where you e.g. need to do extra edits to the code.

Best,
Johannes

Hello,

There's a German discussion here (https://www.roboterforum.de/roboter-forum/kuka-roboter/3/t2-abschalten/5469/) that recommends setting the program speed to 10% whenever the robot is in T2:

Code Select Expand

IF ($MODE_OP==#T2) THEN
  $OV_PRO=10
ENDIF

So it's not disabled, but much slower.

Best,
Johannes

Hello,

Thanks for the feedback, you need to activate the "Output Analysis" option in the Advanced options first.
That is not clear, we will fix that in the next release!

And Circs are currently set to #VAR, there isn't an option at the moment to change it.
You could modify the SRC file, but then the simulation wouldn't be accurate.

Just a remark regarding outputting KRL through the Analysis component: Grasshopper can get really, really laggy when you have a text panel with thousands of lines of text, like a KRL program. So it's not KUKA|prc's fault when it gets slow.

Best,
Johannes

Hello,

In order to have simulation and reality match you need to make sure that the tool's number and XYZABC values are identical and that the tool is mounted the same way on the virtual as well as on the actual robot. That is usually easiest to check at the start position of a job, as the robot will stop there anyway with the BCO reached message.

Also, make sure that the base values match as well!

Best,
Johannes

Hello,

The trial version is now nearly 3 years old and quite outdated.
If you want to give it a try with the most recent version of KUKA|prc send me an eMail (johannes at robotsinarchitecture.org).
Circular movements also have several different orientation strategies like #VAR, #PATH, etc.
The jitter in the SPL may either be rounding problems or spline interpolation through an identical point. But as I wrote, it's an old version, I'll need to check if that is a bug that still exists.

Best,
Johannes

Hello Andreas,

I wouldn't recommend a KRC1 robot, first of all it's limited in regards to memory, but to my knowledge it also does not comply with the current machine safety regulations. So at least in Germany you couldn't set up a new KRC1 robot legally, you could just replace a robot in an existing cell. That might be different depending on where you are. I'd go for at least a KRC2 ed05 (runs Windows XP, supports USB sticks, larger memory, etc.)
We had some fun milling with a KR16 robot and a cheap Kress 1050 spindle which actually worked quite OK. If you've got the space for a larger robot, it actually shouldn't be more expensive than a used KR16 or similar and with it's higher weight it should be more accurate (less vibrations) while also allowing you to produce larger pieces and mount stringer spindles.
Most nice spindles with a HSK holder weigh more than I would feel comfortable mounting on a 15kg robot.
Through KUKA|prc you can postprocess your Fusion G-code into KRL.

Best,
Johannes

Hello,

I've looked at some German search results with your error message (which is useful with KUKA robots) and they suggest that the KCP cable may be at fault.
So if you've got a second KCP or can borrow it somewhere that may be worth a try.
I usually get a full HDD image once the robot is working so that it's easy to restore. Otherwise if you've got the installation medium go with that. If not get in touch with KUKA, ideally they can provide you with a new installation medium!

Hope that helps a bit!
Best,
Johannes

Hello,

If you are using a KUKA Agilus, the robot has got built-in digital outputs: the plug on top of A4.
So you need to get a fitting plug (directly from KUKA or somewhere else, see also the Agilus manual) and then you might need to configure the output in WorkVisual. In WorkVisual you e.g. define that the first digital output of the Agilus is $OUT[1], the second one $OUT[2] etc. So you are matching the physical outputs with the internal numbering of the robot.

The signal is 24V, so you will need to get it down to 3.3V or 5V in order not to fry your Arduino.
I hope this helps a bit!

Best,
Johannes

Sorry, I haven't encountered that particular message before. Is the axis maybe just not mastered?

For those basic "does not work" problems I usually recommend calling the KUKA hotline, they are very good at solving those issues.

Best,
Johannes