Messages

Thanks, Johannes.

I haven't tried that but I will tomorrow afternoon. It makes sense how I could make that work. Thanks again.

Mark

Hi Johannes,

Here are some samples of what I'm making.

https://www.instagram.com/p/DQm1ecvjxNJ/
https://www.instagram.com/p/DPSH1gZjw4w/

Generally, it is working well, or well enough. However I'd like to dial it in further to get it more refined. And the way I'm having to generate rotary motion is a challenge.

The rotary on this setup is E1. It isn't part of the kinematic model with A1-A6. I compute the rotation, normal vector, and speed for every point. When both E1 and A1-A6 are in motion together, it works well. However when A1-A6 move very little, but E1 moves a lot, LIN moves are problematic. An example is printing a ring of clay at the top and bottom of a circular form. A1-A6 don't move. Only E1 moves. When this happens, if I use a LIN move, E1 spins very fast. Because A1-A6 aren't moving at all, it 'thinks' it just needs to instantly put E1 there. So it spins way too fast. Earlier in this thread, you helpfully suggested using PTP moves instead. So, I detect and special case when E1 is very dominant in the motion, and then I switch to using PTP moves. These can be specified as a percentage, and thus I can better control the speed. But I think it's only an integer percentage, so it's not that great of control :)

This also happens at moments in printing in general, where the moves to print are nearly E1 only. It's too fast relative to the other motion, and the clay bead winds up being too thin, or torn, because the rotation was too fast.

I think I was hoping the Custom Turntable component would magically solve my problems by building E1 into the kinematic model along with A1-A6. But it sounds more like a visualization tool. I fight on...

Mark

Bringing back this old thread because I'm still working on this setup...

I've had some success switching between PTP and LIN movement to control the rotation of my setup. But there are some subtleties to the speed that I can't really manage.

I'm wondering if the Custom Turntable component is a possible solution to this type of rotary motion.

I need more information about setting up a custom turntable. Are there tutorials available?

Thanks!
Mark

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