Messages

Hello Math,

According to which criteria do you want to trigger the output? The easiest way is of course to segment your toolpath and add an IO command.
If the triggering happens according to a function based on a system variable, you could just put it into the sps.sub. Note that it would then trigger with all programs (unless it depends on another variable that enables that part). Also, do not put any WAIT or movement commands into the sps.sub and make a backup before you change anything.

Best,
Johannes

Hello Stefan,

Internally the new KUKA|prc works as before, so it wouldn't be a problem to provide you with an extra component if you miss it so much ;)
I'm just a bit swamped with work at the moment, could you send me a reminder in 1-2 weeks or so?

Thanks!
Johannes

Hello,

The problem here is that - ideally - the programmed speed of LIN movements is the same across all robots, while the PTP speed depends on the motors in the robot - i.e. you may have a robot that is externally identical, but with different payloads, and due to the different motors the PTP speed will be different. Also, the robot will not always reach the programmed LIN speed due to e.g. singularities.

In general, when using wirecutting I would rather use LIN movements than PTP movements anyway. You can set the movement interpolation (right-click on the component) to C_VEL, so the motion blending tries to keep the speed steady. And of course try to keep the robot far way from singularity positions, in your case you probably want to minimize the time when A5 approaches 0.

And of course the speed between T1 and T2/AUT mode will be very different!

Best,
Johannes @ Robots in Architecture

Awesome, glad to read that you got it to work! I was away the past days and somehow missed the post.

Best,
Johannes

Hello Joanna,

What you are seeing are so called singularities, which basically happen when two robot axis "overlap" - in this case, it's the A4 and A6. This video shows it quite nicely: https://www.youtube.com/watch?v=zlGCurgsqg8
In general - this applies to all 6-axis robots - you want to minimize these positions. In a best case, these singularities only cause the robot to slow down (i.e. the tooltip moves slowly, while there is much movement in the back), in a worst case the robot may stop with an error message that the required speed exceeded the allowed maximum.
As you've experienced, just slightly moving the toolpath will solve these issues.
Status defines the posture of the robot, with 010 and 110 switching the rotation of A4. Take a look at the PDFs that came with the robot for a detailed explanation - or send me an eMail if you cannot find them.

Best,
Johannes

Can you change your eMail to your official eMail, or send me an eMail from your university address?
Then I'll unlock your account and give you access to the member section!

Best,
Johannes

Hello,

What's your affiliation? As a member you should have access to the member version and much more recent versions of KUKA|prc.

Best,
Johannes

Hello,

I'm currently on my phone, so I cannot check the file. If you want to, I can issue you a temporary license of the current member version so that you can check if that resolves your issue.
You can reach me at johannes@robotsinarchitecture.org

Best,
Johannes

Hello Doug,

I don't have access to MasterCAM, so we would have to try to find a 5-axis postprocessor that creates code that is easy to parse. Or create our own, if there is an easy postprocessor-generator.
I've attached a simple G-code file that could be parsed by the existing KUKA|prc 5-axis import (though the example just uses three axis, A and C are at 0 - was the first file I could find).
You can also get in touch with me via johannes@robotsinarchitecture.org

Best,
Johannes

Hello,

Hmmm... Not really my area - it does not sound like an easy to solve problem, as e.g. shiny metal surfaces can be complicated for some optical inspection systems.
Maybe it would be possible to go the other way by implementing a system that measures the reflectivity of the part (I guess the forged part is matte and then gets shinier with polishing) and the robot performs the grinding, checks the piece, and then repeats it if the finish is not there yet. I guess that could be easier than determining the time to polish beforehand.

Best,
Johannes

Hello Dan,

The RSI is great when you need actual real-time response, i.e. within a few milliseconds. The issue with RSI is that you have to take care of the entire pathplanning and do that on a real-time capable PC. So I definitely wouldn't recommend streaming data from Grasshopper (and Windows in general) to the robot via RSI, but create a custom RSI server running on a real-time capable system that postprocesses data. Because of this we never implemented RSI into KUKA|prc - also, it's quite easy to really damage the robot with it, either by streaming a wrong coordinate, but also by excessive torque at the axes.
One more thing that RSI is very useful is for offsetting toolpaths in real-time, e.g. using the data from a force-torque sensor.
At Rob|Arch we'll be presenting an implementation of mxAutomation, which is not real-time capable, but uses a command buffer. On the other hand that means that it can work similar to a KRL file (i.e. LIN, PTP... commands, regular speed values, motion blending...), except being "dynamic". So if you want the robot to catch a ball, it won't be a good solution, but if you want to circumvent the file transfer via USB stick and/or have parametric toolpaths that (with a certain lag) react to external input, mxA is awesome.

Also, mxA on the KUKA controller should cost quite a bit less than 1000EUR for universities and does not require any additional hardware. Our mxA implementation will be a free feature for the member version of KUKA|prc.

All the best,
Johannes

Hello Ludo,

You are correct - you can buy KUKA motors and use them basically for everything, from obvious things like turntables to custom machines like Wes' rod bending setup.
You need to use KUKA motors that are attached through a power-pack of the appropriate size. From my experience used KRC2 components are rather cheap, while for KRC4 it gets quite expensive (a couple thousand Euros for the powerpack).

Best,
Johannes

Hello,

I believe that the automated solver should work with tilt by default as well - otherwise you can quite easily calculate that yourself, basically get the vector you are interested in, calculate the angle to the how it should align in the plane of the tilting table, and then use it as the input (or possible the inverse, depending on what you want to achieve).
As I mentioned before, you can also send me a file via eMail and I can look into it.

Best,
Johannes

Hello Dan,

While we do quite a bit of milling, I'm not really an expert. Anyway, from my experience 6kW is plenty, though sometimes 8kW spindles are even cheaper as they seem to be more popular. Personally I would definitely go for a tool holder like HSK or ISO so that you do not have to calibrate your tools all the time - as you said correctly. I've never found too much use for a fully automated tool changing rack in a university environment where speed is not as important.
One important consideration for a spindle is cooling. Personally I'm tending towards air cooling as there is one less part that can break - just a simple fan, no leaking tubes, no pumps, no problem if you don't use it for a couple of weeks. Water cooling has its obvious advantages as well - if you are using the robot exclusively and frequently for milling it definitely makes sense to use it!

Best,
Johannes

Hello,

Ah, there is a misunderstanding there - the E1 to E4 values are angles, not points. At the moment, Grasshopper is turning the point coordinates into numbers, probably by first casting it as a vector and then calculating the length of the vector.
That is why it's looking systematic, but strange :)
Basically you have to think of some kind of formula that adjusts the tilting of the table, which may involve some trigonometry. Alternatively you can look into the automated solver.
Note that if you are picking something up from outside the turntable, you have to manually set the E1/E2 value so that this position is always constant. If you set coordinates manually, that will override the automatic solver.

In order to help you a bit more, it would be helpful to have a better idea what you are trying to achieve. Please send it via eMail if you don't want it to be publicly online.

Best,
Johannes