Issue with Large Number of Points when Generating G-code for TX60 Robot

[moutemio]

Issue with Large Number of Points when Generating G-code for TX60 Robot
Hello everyone,

I’m facing an issue with the TX60 robot and the CS8C controller in a robotic 3D printing application. I generate G-code by dividing the contour and infill curves into points (targets) for the robot to follow when depositing material.

However, when dealing with large parts (around 3 million points), the robot’s teach pendant starts to crash or slow down significantly, making it impossible to execute the task. I suspect this is due to the controller being overwhelmed by the sheer number of points.

Context:
Robot: TX60
Controller: CS8C
Process: Dividing contour and infill curves into several points (targets).
Problem: The teach pendant freezes when loading a large number of points (approximately 3 million).
My Question:
Does anyone have suggestions on how to optimize the number of points or handle this kind of overload in the context of G-code generation for a 6-axis robot? I’m open to ideas such as curve simplification, trajectory segmentation, or any other mechanism that could help the controller better manage large trajectory datasets.

Thanks in advance for your help!

[visose]

Hi, you should try two things:

• Reduce the number of targets. Grasshopper has several components, like Curve to Polyline, Reduce, and Pollyline Collapse that can help you remove unnecessary points. Make sure the resolution of your toolpath is not smaller than what would be appropiate given your bead size and blend radius (zone). Also make sure the relative resolution/tolerance is consisent along the toolpath, this means that parts that are more curvy should have a higher density of points than parts that are less curvy, with parts that are not curvy (straight lines) having no points at all between the start and end.
• Split the program into sub-programs. Identify places where a stop point and stopping/resuming extrusion is convenient and use these as transitions between different programs.

[moutemio]

When segmenting a .pgx file, is it sufficient to only modify the .pgx file, or do we also need to update the corresponding .dtx file containing the joint positions and other data?

[visose]

I mean you can split the program in Grasshopper.

[moutemio]

Could you please provide an example gh file of splitting the program as you mentioned?

[visose]

Closing this as answered. The two practical steps are still to reduce target count and split the generated program in Grasshopper. For splitting, use the Create Program Multi-File Indices input: each integer is the first target index of an additional file. For Staubli/VAL3, Save Program writes the .pjx, one shared .dtx, start.pgx, stop.pgx, and generated subprograms such as ProgramName_000.pgx; do not manually split only the .pgx without keeping the generated .dtx/project structure consistent.