Topics

I wish that the Analysis output for Angles were null for each axis which is out of range.
This would allow to make custom axis value displays as in the attached, but with a specific warning for the relevant axis.

[no]

Hi Johannes,

You remember I asked for an enhancement of the "Tool axis offset" component which would allow to control independently the speeds of the various phases of travel :
-"Flyover" speed (typically high to avoid losing time between operations
-"Dive" speed (Typically a bit lower)
-"Process" speed -> Here, I actually wish there was no input since the speed is set upstream ; this component should only be relevant to the offset movements and the "Flyover".
-"Retract" speed

Thoughts ?

I wish it was possible to apply a transform to the paths defined by a "Fusion 360 NC import" component.
I feel that it would be more natural and easy than to mess with the Base coordinates.

Carthesian offset writes no values in this case ...

"Wait" component writes no time value .
How does the controller know how long to wait then ?

The new "Tool offset" component turns "PTP" commands into "LIN" commands.
Why ?

When I opened my definition today, the custom tool mesh had disappeared, and the tool effector point was on the robot flange.
I plugged in a new "Custom tool" component, and everything went back to normal.
Bug ?

Hi Johannes,

I started reading the KRL documentation after three years of owning Wall-E :)
I realize that the .src generated by KUKA|prc uses a "E6POS" data type to define the trajectories, and this includes 4 values for external axis.
Since I have no external axis, it would make the files much smaller if I could toggle an option to use just a "POS" data type with no external axis values.
Specially for milling, this would allow me to generate longer tool paths...

Would you consider including such an option in the main component ?

Cheers,

I think that the "Play-Pause" component should have a more evolved UI which would include :
-A slider
-The Analysis graph
-A "speed" option to accelerate or display the kinematics in slow motion

I think that the robot list would be better hidden in a component's specific UI instead of all the tiny icons.
This would free the "02|Virtual Robot" toolbar , and the dialog box that would pop-up when clicking the "Robot choice" component would display for example high-resolution thumbnails of the various robots, with a few data points.
This occured to me because I often find myself fumbling around in the robot icons to find my specific model. Moreover, there are multiple robots called KR6, and the tiny icons really don't help much in picking the right one.
This tool could even include the "Custom robot", and allow to adjust the angle parameters in an existing robot, without having to fully define a custom robot.
For example, I'd be able to tweak the Axis 3 angles of my KR6-arc for which the range seems slightly more narrow than the preset values, and programs often fail because of this : "Axis 3 angle exceeded !".

I mentionned this in an old thread, but I think that the Fusion 360 NC import component deserves a separate thread.
So first of all, despite my general dislike for Autodesk, I found the CAM workflow in Fusion to be extremely well done : everything makes sense in the way the interface is layed out and the images+tooltips are a fantastic help for someone not too familiar with CAM.

Now, the first issue I have with the KUKA|prc importer is the faulty CIRC commands that generate the dreaded "Start point equal to mid point" error message.

I wish that either there was some error trapping in the component to prevent this from happening, or an option to convert circular paths to lines.

The second issue is how the "Reduce PT" does not seem to reduce the point count on linear paths.
Since I had to bake the paths because of the "CIRC" issue, I was able to use the Rhino "SimplifyCrv" tool, which got rid of most of the intermediary points in strait-ish paths.

Maybe also add an input for Lead-in and Lead-out speeds when the"Feed toggle" is set to "False".

Cheers,

Hi !

While running a simulation, it would be nice to have components which inherit in real-time the I/O values so as to display some kind of user-friendly indicator.
I like using Human's "Render text to screen" component to have a "glass cockpit" feedback of what's going on.

I'm still not very happy with the overlay mode of the simulation graphs : when zoomed, it often gets in such a position that it can't be closed.
Also, the zooming makes it pixelized, and the I/O indications are still not very helpful shown like that.

Cheers,

For the same reasons I like the base and tool settings to be exposed (or expose-able to be exact), I would also like the "Start" and "End" positions to be tweaked from the GH canvas.
I find that the initial position can affect how some axii wind themselves up, and that's also where I have most of the tool/part collision problems.
Being able to adjust these key positions with sliders would really help.

I might as well suggest right now that every option should be exposed to be consistent with the Grasshopper spirit...
:)

Cheers

It's not a huge deal, but I noticed that the "Show robot frames" option toggles "on" by itself sometimes.
It can happen when opening a file, or when changing stuff in the main dialog.

Cheers,

Hi !

Being now in the mid 40ies, it's becomming more difficult for me to see tiny things, and I wish that I could enlarge the analysis graph.
In particular, I find the IO graph and it's legend completely microscopic...

Cheers,

Hi !

Since I've been using the "Axis move" component to unwind my axii in the middle of a job, I'm getting lots of kinematics suddenly stopping because this or that axis has exceeded it's max speed.
I wish that KUKA|prc warned me upfront so that I could find other axis values or geometric conditions that would avoid this situation.

I can use the axis graphs to "guess" where this is likely to happen by looking at the curve slopes, but the plugin could do an even better job using the derivative or the angular graph to get the angular speed, and warn the user graphically ; perhaps using an other color than red on the relevant axis.

Cheers,

I just used the "Axis movement" component for the first time, and find that it induces an error message during execution.
I set the "Vel" input to a value of 10, which is 10% of the max speed if I understant well.

So what could be the problem ?
The message states that I am exceeding the max speed by over 600% ; this seems completely crazy...

Here's a screen capture of the pendant : https://goo.gl/photos/tgKrVTGVtCuUongj8

Cheers,

If I make changes to the "Custom tool" values, I can't see any way to close the box and discard any changes like in the "KUKA|prc settings" box where I can "Exit" without applying the values.
Did I miss something, or is there no other choice than confirm changes to exit ?

Cheers

Hi !

I have updated my 2D cutting definition to integrate the I-O s of my plasma cutter.
Just to be sure that the output which triggers the plasma is "OFF" or "False" at the start of the program, I have added a command from the "Set digital" component at the very beginning of the command stack.

Sadly, this does not seem to register in the .src file (see attached).

Cheers

Hi !

I think it would be nice to have the parameters (number, coordinates, angles) for "Tool" and "Base" exposed outside the "Tool" and "Core" component.
Not only would it be a good way not to fool ourselves in which tool and base number is used, but also, it would be nice to have direct control over the coordinates.

I know that it's supposed to be the other way around : first do the tool and base definition on the robot and then push the values in the simulation.
But look at it this way : suppose you have a table which is a good base.
You might want to figure out where to place it (along with whatever you want to process on that table)so as to have a successful simulation.
In that case, it would be nice to use sliders and fiddle a bit until you get rid of any angle overshoots or collisions.
Then, you will just move the physical table as close as possible to the simulation values, setup the base and input the precise real-world values in the simulation.

Cheers,