[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.