Messages

Hi Johannes,

I'm sorry but I don't know how to set the speed, other than to wire it into the PTP Movement component. Is there another way I can set the speed?

I wasn't sure if this is what you meant: I did remove the rotation values being wired into E1. And generated the code. I still don't see any velocity values generated. But perhaps I don't know what to look for. Here's an example of the generated code after doing that:
...
LIN {X 594, Y 56.77, Z 391.431, A -90, B 83.884, C -90, E1 90, E2 0, E3 0, E4 0} C_DIS
$VEL.CP=0.00936
LIN {X 594, Y 56.656, Z 390.369, A -90, B 83.884, C -90, E1 90, E2 0, E3 0, E4 0} C_DIS
$OUT_C[71]=TRUE
WAIT SEC 0.4
PTP {X 594, Y 56.656, Z 389.369, A -90, B 83.884, C -90, E1 0, E2 0, E3 0, E4 0, S 'B010'}
PTP {X 594, Y 56.656, Z 389.369, A -90, B 83.884, C -90, E1 0, E2 0, E3 0, E4 0, S 'B010'}
PTP {X 594, Y 56.656, Z 389.369, A -90, B 83.884, C -90, E1 0, E2 0, E3 0, E4 0, S 'B010'}
PTP {X 594, Y 56.656, Z 389.369, A -90, B 83.884, C -90, E1 0, E2 0, E3 0, E4 0, S 'B010'}
...

What should a line of code that sets the speed look like?

Thanks!
Mark

Hi Johannes,

Thanks, I appreciate your help. Right that was just from a Panel. Here's from the KRL file itself:

...
LIN {X 594, Y 56.77, Z 391.431, A -90, B 83.884, C -90, E1 90, E2 0, E3 0, E4 0} C_DIS
$VEL.CP=0.00936
LIN {X 594, Y 56.656, Z 390.369, A -90, B 83.884, C -90, E1 90, E2 0, E3 0, E4 0} C_DIS
$OUT_C[71]=TRUE
WAIT SEC 0.4
PTP {X 594, Y 56.656, Z 389.369, A -90, B 83.884, C -90, E1 84.845, E2 0, E3 0, E4 0, S 'B010'}
PTP {X 594, Y 56.656, Z 389.369, A -90, B 83.884, C -90, E1 79.516, E2 0, E3 0, E4 0, S 'B010'}
PTP {X 594, Y 56.656, Z 389.369, A -90, B 83.884, C -90, E1 74.029, E2 0, E3 0, E4 0, S 'B010'}
...

What would a line of KRL which sets the PTP speed look like?

Here's some code at the top of the KRL file - it looks like this:
...
$VEL.CP=0.01
$APO.CDIS=1
$APO.CPTP=1
$ADVANCE=3
;ENDFOLD


Thanks!
Mark

Hi Johannes,

I gave this a try. It looked promising when I ran in T1. The rotary motion was nice and slow. I specify a velocity of 2% on those E1 rotation only moves. That's the value wired into the PTP component.

When I switch to Auto mode, the rotations go back to super fast.

I don't see on the lines of KRL for the PTP moves where the speed is specified. Here are a few sample lines where it switches from LIN to PTP when it detects a rotation only move:
...
LIN: X 594, Y 56.7, Z 390.4, A -90, B 83.9, C -90, E1 90, E2 0, E3 0, E4 0
 DO71=TRUE
KRL: WAIT 0.4 SEC
PTP: X 594, Y 56.7, Z 389.4, A -90, B 83.9, C -90, E1 84.8, E2 0, E3 0, E4 0 | @010
PTP: X 594, Y 56.7, Z 389.4, A -90, B 83.9, C -90, E1 79.5, E2 0, E3 0, E4 0 | @010
PTP: X 594, Y 56.7, Z 389.4, A -90, B 83.9, C -90, E1 74, E2 0, E3 0, E4 0 | @010
...

Anything you can suggest for this? Do the interpolation settings effect the speed? I have C_PTP set to 1% in the Settings dialog in the Interpolation section.

Thanks for any help!
Mark

I think I can do that without too much trouble. I'll give it a try tomorrow.

Thanks, Johannes!
Mark

Hi,

I'm getting closer and closer to this working really nicely. A remaining issue occurs when the robot doesn't move but E1 does. In the attached image, which is a trivial tester I made, it prints two lines along the surface. Then at the end it prints two rings, one at the base of the form, the other at the top. They are show as brown circles, marked with the red arrows.

In those cases, A1-A6 don't need to move, just E1. Even when I have the speed set very low (0.00001 m/s) it spins quite fast. In a way this is understandable because A1-A6 aren't going anywhere.

Any thoughts on how I can move this at a controllable rate? One hack I know I can do is just move the robot a little bit, like a tiny amount up in Z or something so A1-A6 will move. But I'd prefer not to do this if possible.

Thanks for any insights!
Mark

Hi Johannes,

Thanks for answering questions while you are away!

The suggested fix works great. I appreciate it!

Mark

Attached is a simple example. Three Kuka PRC Commands get wired into a python node.

One test just assigns them to a list and outputs them. The other casts them to KUKAprcCore.PRC_Classes.PRC_CommandData and outputs them.

Neither can be used as input to the CMDS input of the Kuka Core.

I don't know how to make them into a known, valid type.

Thanks,
Mark

I need to use GH Python (Python 3 Script) to properly sequence a set of KUKA|prc Commands.

I'm taking input from the PRC components Digital Output, LINear Movement and Wait commands. These are generated by those native Kuka PRC components.

The python is just taking those lists and building a new list with them sequenced as I need. (It's much easier for me in Python than native Grasshopper!)

It builds the list no problem, but when I try to use it as input to the Kuka CORE, I get the error "1. Data conversion failed from Goo to KUKA|prc Command".

So, in Python I need to cast this so it's in the appropriate format.

How do I do that?

Thanks very much for any help!
Mark

Thanks very much. Some motor speed updates fixed it. Helpful to have access to Wes McGee :) Lots to improve but it's a good start.

Mark

As an additional piece of data about this, the points are specified quite close together. Here are a few successive lines of KRL:
...
LIN {X 594, Y 221.615, Z 374.695, A -90, B 83.884, C -90, E1 91.297, E2 0, E3 0, E4 0} C_DIS
LIN {X 594, Y 220.415, Z 374.823, A -90, B 83.884, C -90, E1 91.623, E2 0, E3 0, E4 0} C_DIS
LIN {X 594, Y 219.3, Z 374.943, A -90, B 83.884, C -90, E1 91.949, E2 0, E3 0, E4 0} C_DIS
LIN {X 594, Y 218.266, Z 375.054, A -90, B 83.884, C -90, E1 92.277, E2 0, E3 0, E4 0} C_DIS
LIN {X 594, Y 217.307, Z 375.156, A -90, B 83.884, C -90, E1 92.605, E2 0, E3 0, E4 0} C_DIS
LIN {X 594, Y 216.421, Z 375.251, A -90, B 83.884, C -90, E1 92.934, E2 0, E3 0, E4 0} C_DIS
LIN {X 594, Y 215.606, Z 375.339, A -90, B 83.884, C -90, E1 93.264, E2 0, E3 0, E4 0} C_DIS
LIN {X 594, Y 214.857, Z 375.419, A -90, B 83.884, C -90, E1 93.594, E2 0, E3 0, E4 0} C_DIS
...

So, in those lines the robot only moved 7mm and E1 only rotated 2.3 degrees. That's typical of the entire path, the locations are really close together.

Thanks!
Mark

Hi, 

I'm starting to do some clay printing on a rotary axis setup using a KR-6 robot, and an external axis (E1), driven by a stepper motor. 

Here's an image of the simulation, which works nicely:



Here's a short video of the robot doing the same toolpath. 

The motion of the robot (A1-A6) is exactly as expected. It is the rotating axis E1 that is out of sync. It seems to lag behind the A1-A6 positions when arriving at new points. 

I'm specifying an E1 position on every LIN move. Here's a typical line of KRL: 
LIN {X 594, Y 210.275, Z 375.91, A -90, B 83.884, C -90, E1 97.954, E2 0, E3 0, E4 0} C_DIS

If the E1 motor is working correctly, can I expect the robot end effector position, and the rotary axis, will always be in sync? That is, the robot will not move to the next position until A1-A6 and E1 have reached their specified positions? 

If that's the case then I know I have an issue with the stepper motor setup perhaps accelerating or decelerating improperly. It's actually fairly close to correct, it's just not perfectly synced. 

Thanks very much for any guidance, 
Mark

Hi Johannes,

Thanks for the quick response! It does seem to need those E5 and E6. And I did have to add the A1-A6 as hardcoded values. But it works so this is acceptable for now.

Thank you! 
Mark

Hi,

Our robot setup necessitates specifying all the external axis (E1 through E6). Right now PRC generate E1 through E4 in the code (all 0). But when I run a program it says "Impermissible start motion". The error occurs on this line:

STARTPOSITION - BASE IS 0, TOOL IS 4, SPEED IS 10%, POSITION IS A1 0,A2 -65,A3 78,A4 0,A5 -102,A6 0,E1 0,E2 0,E3 0,E4 0

If I add E5 0, E6 0 at the end it works.

Is there a way for me to generate those extra axes in the code that PRC outputs?

Thanks!
Mark

Hi Johannes,

Thanks, I didn't know about the right-click on the robot ... now I do!

Yes, if the Analysis component could output those transforms relative to the initial base posture we could easily use that. This is what we hacked before:
https://www.instagram.com/p/BwK1eHznBNS/?utm_source=ig_web_copy_link

Thanks,
Mark

Hi,

I wanted to log two feature requests (or learn where I may have missed these features in the existing implementation!)

1) A simple checkbox in the UI to allow A6 to not generate an error if it spins beyond the limits. We do this a lot and it confuses students when the Core turns red but the code runs just fine.

2) The ability to read the transformations of each axis at each frame of the simulation. We hacked this using the mesh at each frame and computing the transformation between mesh vertices frame to frame. A more elegant solution would be welcome! I'm using this to allow Fologram to draw the robot simulation in augmented reality.

Hoping these can be considered!

Mark