Re: Controllers for 3D cutting
Originally Posted by
SteveS
"Unless the 3d op toolpath is aligned with an X or Y axis, it’s going to be line segments. It’s a fundamental limitation of many controls and probably fusion."
When you boil the G code down to the controller level, all moves are converted to line segments. The controller only understands steps or encoder pulses, it has no idea what an inch or a millimeter is. Arcs are also converted to line segments at the controller level, there is a lot of trig happening there. Arcs are converted to a series of X/Y/Z coordinates measured in steps or encoder pulses. So a simple G2 move that is one line of G code, might be 1000 or more lines of segmented moves at the controller level.
Fusion outputs line segments only in 2D adaptive, except for the leadin/out moves, not sure about 3D adaptive because I have not used it. I'm not sure about any other CAM software. One thing I have noticed about Fusion is that it does not create the best tool paths and seems to waste a lot of time on moves that make no sense. There are some settings that you can tweak to reduce the tool lifting and that type of thing, but I have not figured out any way to get it to work from one side to the other in a logical sequence without unneeded rapid moves from one side of the work to the other.
On my lathe, many times I hand edit the G code to optimize the tool path. Fusion seems to waste a lot of time with unneeded moves. But the lathe G code files are very small and are easy to edit. Hand editing a 200,000 line mill G code file would be next to impossible and would take more time than you would save in cutting time.
Question – Is there logic to the controller affecting the cutting time?
It could, but if there were any significant delays in processing the commands you would notice a jerky motion in the movements. I would expect to see a difference in the controller performance between a million dollar machining center and a home shop machine. In the high end controllers there is some optimization and trajectory planning done on the G code as it's processed with a deep look ahead. You are not going to have this in a low end controller.
Are there controllers that are better at performance for 3D tool paths? It is interesting to me that none of the files cut so far have any lost steps, loss of detail or failed.
I think not in the controllers that would normally be found in a home shop. That they work as well as they do has always been amazing to me.
The on screen running gcode steps are in sync with the machine movement and code scroll stops when the spindle rises to return home.
The display should stop until the tool has moved to the position commanded by a particular line of G code, it won't execute the next line of code until the move is complete.
I am not sure if the code scroll indicates the controller not “feeding” drives in real time or not.
It depends on the CNC software. Some software may take the G code line by line and process it in real time. Others may compile the entire G code file into something the controller can understand and drip feed it to the controller. The latter is how I do it, the entire G code file is processed, converted to controller compatible code, and stored in memory, and is fed to the controller as there is room in the command buffer. As the command code is being executed, there are pointers that select the correct line of G code on the screen so there is a visual representation of the program progress.
Jim Dawson
Sandy, Oregon, USA