[npbrock]

I'm doing research on direct ink writing and we're using a Kuka robot to hold a fluid dispenser to do so. My part on the research team is creating a novel toolpath approach that will better support the challenges faced with direct ink writing. As such I've created my own custom CAM software. Currently I will create various complex surfaces and objects in a CAD software, export an STL file and my CAM software analyzes it and outputs various data along with a Gcode. I am able to get my Gcode into the software and have the fluid dispenser follow my toolpath but it's ignoring the ABC angles in the GCode. Also, I need the capability to modulate the fluid flow for the fluid dispenser. Currently my CAM software is outputting S commands for fluid dispensing rate and F commands for toolhead movement speed. A sample output of the CAM software is below for an older file. 

; File: Complex_Surface.gcode
G21 ; mm units
G90 ; absolute positioning
G0 Z5.0000
G0 X-63.3600 Y-70.0820 A4.9575 B0.0000 C0.0000
S0.0
G0 Z10.4105
M3
G5.2 P1 ; Begin NURBS curve
X-63.3600 Y-70.0820 Z10.4105 A4.9575 B0.0000 C0.0000 S0.0 F1200.0
X-63.3600 Y-69.3850 Z10.3644 A1.4371 B0.0000 C0.0000 S53.0 F1200.0
X-63.3600 Y-67.9910 Z10.4614 A-8.3558 B0.0000 C0.0000 S29.7 F1200.0
X-63.3600 Y-67.2941 Z10.5868 A-11.8905 B0.0000 C0.0000 S22.7 F1200.0



As you can see all of the toolhead tilt for now is done in the A direction (about the X-axis). Currently this is being ignored in RoboDK. I can change the output of the CAM software if needed, I just need some direction. I've read through and watched several videos on the topic, I know I'm likely missing and older post and I apologize if I've missed it.

[Borgis1]

S is converted to set speed in program events and probably not what you want... or? If it works it works right... but S as standard gcode does not support decimals. Maybe look into numbers in order of magnitude to get the resolution instead of decimals if you need to use S or any other letter you prefer.
I do not think robodk supports any nurbs curve gcode. only the points. I solve this at the pp of robodk where I use spline commands instead of linear movement to interpolate between the points. Depending on point distance this can be a bit of hit and miss so you need to control the points, kuka has a pretty nice readahead for these exact usage cases.

For the answer to you question you asked right now I do not know, I feel I anwered the question in your next post. Anyhow, these guys probably wants to look at you .rdk file.

[npbrock]

RoboDK is able to read the NURBS without issue, it's just not reading in the toolhead angles (A,B,C).

[Albert]

RoboDK can import G-code including tool orientation angles (A, B, C), however, this was intended for a generic 5-axis machine that may be different from the post processor you are using. Is it possible for you to export the orientation as ijk values of the cutting axis?

Also, using formats like APT should require less customization of the post processor used on your CAM software. What CAM software are you using? We have some plugins with APT/G-code post processors already implemented to send the machining path to RoboDK.

Also, have you considered using RoboDK CAM?
You can find more information here: https://robodk.com/CAM

[npbrock]

Albert, I was able to get it to work properly by getting my CAM method to output IJK vectors instead of ABC angles. Thank you for the help.

[Albert]

Wonderful, thanks for letting us know.

[npbrock]

Albert, sorry to dig this up again. So presently I'm able to use RoboDK to simulate my code using G0/G1 commands with xyz ijk controls. Unfortunately compared to NURBS this lengthens the instructions by ~10x. Additionally, for my research I'm trying to make curvature continuous parts. Unfortunately if I do arcs/circles I lose the ability to have vector control on the toolhead and if I use .apt files I lose any sort of curve commands whatsoever. Is there a way I can create curves and maintain toolhead vector control?

[Albert]

It is normal to see longer paths if you change the tool orientation. RoboDK filters program generation automatically so you generate one point every 0.05 mm by default. You can change this setting in Tools-Options-Program. However, it will still take longer time for RoboDK to process if you provide more detailed paths.

By the way, RoboDK supports arc movements using APT and the CIRCLE/MOVARC directive as well.

I took a deeper look at your project and I recommend you to change these settings:

1. Attach the coordinate system to the robot base: It will be easier to debug the frame coordinates if you change it on the robot. By simply double clicking the coordinate system you should see the BASE variable match what you see in the RoboDK frame (or very close if you adjust it on the robot)
   
2. Use the minimum tool orientation change unless you need the too to follow the path.
   
3. Move the part further from the robot to avoid working close to a singularity (joint 5 close to zero). This will help you reduce unnecessary rotations of the tool.
   
4. Set the allow tool z rotation to zero: if the path is feasible with this setting it will be much faster to calculate.