All the arc’s & circles I create in my CAD/CAM software get converted to small lines by the time the toolpaths reach my Sienci recommended G-code sender. Also I’m told that their control box firmware supports G2 & G3 arcs. The software chain is post processor to G-code sender to firmware. Can anyone out there narrow in on the cause of this problem and edit the software responsible. I will gladly pay anyone who can fix this.
Sounds like you need to ratio the project up in G Code sender? Are you saying the project looks too small in the Sender?
I can’t see how it’s a scale problem. I’m saying the arc’s are broken into small lines instead of remaining a true arc. This problem increases the number of code lines by 5 or 6 times and the lesser the number of line breaks results in an increasingly jagged arc or circle. I have six GRBL post processors and tested them all on the same CAD/CAM file. You can tell by the number of code lines which post processor has retained a true arc and which has broken the arc into lines. Yet the G-code sender shows them all as broken arcs. I think desktop CNC manufacturers need to get together and develop their own G-code sender and firmware.
Out of curiosity, what CAD/CAM package are you starting with?
If I understand what you’re reporting, you’re saying that even in the cases where the GCode is smaller, indicating the use of more advanced arc code, the post processor still down converts that to stepped lines? Suggesting UGS sees something it can’t handle at the moment and simplifies it on the fly?
I’m using BobCAD/CAM 3 axis mill version. They have over 150,000 users worldwide and great support. As I stated earlier the GRBL post processors I tested will produce true arc’s or broken arc’s as an NC file. These post processors can be edited to produce either. The true arc NC files open by my G-code sender will still be broken into lines and create error 20 or 30 codes when run. The broken arc NC files appear to work fine with no errors but I want to take advantage of true arc codes. Its a software problem in this chain somewhere. I need a programmer.
Hmm ok so the sender is actually seeing arc codes and breaking them in to line codes on the fly. That’s interesting and surprising. I am out of my depth on this, but off the top of my head it seems like any Cartesian gantry CNC should be able to do the arc if the motor steps are fine enough (and I don’t think that is any issue these days).
And @SDS are you not actually getting clean arcs, but rather straight segements that approximate a circle? Or are you just saying you would rather 1 line of code not expand to 20 lines of code and any attendant delay that goes with it?
I’m trying to think what would necessitate breaking true arcs in to line segments in the sender. I guess the issue is if the controller itself knows what an arc code is? @andy or @chrismakesstuff is that what would be happening here?
I don’t entirely understand the relationship between the controller/firmware and the sender. I suspect the firmware on the controller is directly related to the GRBL project or has a core library from it, and this is why UGS would break it up, perhaps because it knows the GRBL firmware library doesn’t accept the advanced arc gcode command? If that’s the case, the core GRBL libraries that are incorporated in to the firmware is where the change would need to take place.
Hopefully Chris or Andy can provide some insight and then a peek at the GRBL roadmap or UGS roadmap would be the right place to look for more detail?
I just read this post by Chris: Permanent fix to "An error was detected while sending 'M6..."
Note in the screen shot that there is a check box for “Arc Expander”. Perhaps an explanation lies in there?
I think the Arc Expander is exactly the option you’re looking for:
" Program Slows Down and Send Freezes
If you notice slowness while running your program, it may mean UGS is running out of available memory. There are a couple things to try:
- Check the controller settings, and make sure “Arc Expander” is not enabled. This can take a small program and turn it into a very large one by converting arcs into many small movements."
From here: https://winder.github.io/ugs_website/guide/troubleshooting/