Messages

Hmmm... You lose quite a bit of material, but the looks are definitely nice! You can get very stable welding tables that work for milling (also with holes for workpiece holders etc.) for less than 1000EUR - but then of course only in standard, rectangular sizes.
In general with robots, adjusting the height of a table is useful to avoid singularities etc - but of course a height-adjustable table is less stable than a fixed table, so it's again a tradeoff.

Best,
Johannes

Hello,

We had the same thing happening when the circuit breaker was not properly dimensioned. I believe it has to be for 300mA while most common ones are 30mA.

Hope that helps!
Best,
Johannes

Hello Ludo,
I somehow thought that you were using a KRC2 controller, otherwise I could have helped you with WorkVisual!
Anyway, I'm glad you got it to work - as far as I remember, if the Beckhoff modules are pre-installed they will be in the bus structure, but you would still have to map the IOs. So there's no getting around the WorkVisual ;)
Best,
Johannes

Hello Danijel,

We can also do this on short notice, just send me an eMail via johannes@robotsinarchitecture.org.
I'm commuting from Salzburg, so I probably won't be around after 5pm - maybe they can give you a longer lunch break ;)

Best,
Johannes

Hello Ludo,

I talked with a KUKA engineer yesterday as I somehow never configured IOs with KRC2. He asked what bus system you are using to connect to the IO board. Can you give me any more details?

Best,
Johannes

Hello Danijel,

If you are doing the training in Linz you can drop by at our lab - it's only 10mins from KUKA!
I've attached the WorkVisual manual, but it's also included in the installation folder - KUKA always puts the manuals into the DOC folder of the ZIP file.
You can also find attached a WorkVisual project, I believe it's a copy of the KR120 at the University for Applied Arts Vienna. It should be a rather basic setup with only small adjustments from the defaults.

WorkVisual is the configuration tool for KUKA robots, it is not the simulation environment (that would be KUKA SimPro, KUKA|prc of course also simulates robots). So it will be important for you during setup, but probably not really something you will need on a daily basis.

Best,
Johannes

Hello Ludo,

That is really strange, so if you set e.g. output 3 manually from the KCP it works, but if you call $OUT[3]=TRUE (which should be the result of the output component) in the KRL file it does not?
What exactly do you mean by mapping the output command from the robot to the PLC?

Best,
Johannes

Excellent, always happy to help!

Best,
Johannes

Hello,

KUKA provides robots geometries in the robot's standard home position, i.e. 0/90/-90/0/0/0. So you also have to provide the meshes in that position.
If you set the axis values to 0/0/0/0/0/0 then the robot will look as in your screenshot (which is correct).
There is not need to "zero" the axes when using a robot, as e.g. in older CNC machines!

Best,
Johannes

Hello,

I just went through my old photos from my time at TU Vienna where we had that spindle - that was the best I could find where the label is somehow readable: https://onedrive.live.com/redir?resid=CCAAAC61F8C818D8!186572&authkey=!APC-73xrAwFEn4A&v=3&ithint=photo%2cJPG
It seems to be that spindle: http://www.hsdusa.com/bo/allegati/Files/797_1423h0241_rev03__es350_.pdf

Hope that helps!
Best,
Johannes

Hello,

Hmm... My best guess would be that the collision occurs "between" movements, as KUKA|prc only checks at the given positions but not inbetween (as this would potentially need a huge amount of memory and computation time).
You can try to enable the LIN interpolation in the KUKA|prc settings so the collision should show up in the Analysis view. If the problem persists please send me the file via eMail so that I can take a look at it!

Best,
Johannes

Great! I'm glad that we got it to work!
Please let me know if you ever run into any other issues!

Best,
Johannes

Hello,

There are two (documented) reasons why this happens: Either some parts of the framework or some parts of KUKA|prc are missing.
In regards to the framework this happens most often with Windows XP users, as e.g. in Windows 8 everything necessary "should" be included. You can get the .NET Framework from Microsoft's download section: https://www.microsoft.com/en-us/download/details.aspx?id=30653
The other occasion when I've observed that issue was when someone manually copied the KUKAprcCore.dll and KUKAprcNew.gha file, but forgot to include the OxyPlot files that are necessary to show the analysis graph.
Another thing to try out: We are signing our files to make sure that they are not blocked by Windows, but you can try to right-click each of the KUKA|prc related file in the components library (Grasshopper > File/Special Folders/Components Library) and see if it offers an option to "Unblock" the file.

If the error persists please send me some more details about your setup, i.e. operating system, version, Mac?, etc.
Please either reply here or send it via eMail to johannes@robotsinarchitecture.org

Sorry for the problems that you're having with KUKA|prc!

Best,
Johannes

For anyone with a similar problem:
I tried the file on a KRC4 and got the error message "Inadmissible module name" which is more helpful than on KRC2.
Turns out there was an empty space in the filename and projectname (with probably the latter causing the issues).
We just pushed out a new KUKA|prc member release, the version after that (in 1-3 weeks) will check for empty spaces (and not just for numbers at the beginning of a project name, which also wouldn't work).

Best,
Johannes

And did you try copying a file to D: as I suggested before?