Series of Points instead of arcs (Feature Request)

[berkut0]

There are couple important aspects to this approach:

Many consumer CNCs require recompiling the firmware to use arcs. For example, I had to recompile the marlin firmware of my 3d printer to run the resulting g-codes.

There are often problems when reproducing arcs that are too small. I am now experimenting with robots and using g-codes to convert to commands directly on the robot and too small values fall under calculation problems

[domoszlai]

I'm wondering what happens if you get unconnected dots. It is just not possible for the device to figure out the proper order to follow them imho.

It also feels like 2 different problems:

1. If your device does not support arcs, we could fall back to straight lines?
2. What about having a minimal arc/line length setting?

[berkut0]

G02/G03 clearly indicate the direction of travel

if you look at how the printer firmware is organized, you can specify the level of sampling within the firmware itself. Slicers for 3D printers most often do not generate arcs, but make a set of points on a circle. But the option to include arcs exists, although in the 3D printer it is arranged in such a way that the arc is sampled and broken up into many movements.

it seems to me it is possible to specify the sampling angle, for example or number of points the G00/G01 series instead of arcs can greatly reduce the risk of getting an error in some "unprepared" setups

Another idea is to add comments to the flavor file. In this case, the sampled arcs can be taken in scope with comments.

[domoszlai]

Let step back a bit. One problem is that some devices do not support arcs out of box. That basically means falling back two G01/G02 what is linear approximation.

3D printers most often do not generate arcs, but make a set of points on a circle. This is linear approximation imho

The other problem is arcs being too small. In my opinion, it is an approximation problem, probably the error is set too small. What if you change the --resolution? Might there be a bug in the error calculation...

getting an error in some "unprepared" setups what does it mean?

Another idea is to add comments to the flavor file. In this case, the sampled arcs can be taken in scope with comments. could you give me an example?

[berkut0]

This is linear approximation imho

Yes, perhaps I didn't put it correctly. I'm talking about interpolation. Sampling and interpolation. Roughly speaking, it would be cool to get rid of the arcs and make some kind of point approximation instead. In some cases this solves a lot of problems where arcs can be an issue

what does it mean?

Now most of the problems in my setups (which are not originally designed for g-code, but I use them in different ways) are due to arcs and their calculations. Sometimes it's on the machine side, sometimes it's on the processing computer side. One one hand It is much easier to interpret and use a series of points instead of complicated arches from g-code, and on other some machines face the problem of planning movement around such complex motion

could you give me an example?

Something like this:

; Start Arc Interpolation
G00 X0 Y0 Z0
G00 X1 Y2
G00 X3 Y4
; End Arc Interpolation

[berkut0]

I tuned the settings and I use the "-r" parameter a lot and it helps, but sometimes at the most unlikely moment, the code fails and I have to run everything from the beginning with higher values of "-r"

[domoszlai]

I think we could generalize some settings into one, like --interpolation=linear,biarc,cubic-bezier where biarc is the default (G03/G04), cubic-bezier (G05) we already have and linear (G01/G02) could be trivially added. Then --generate-bezier would be deprecated

This would work for you?

[domoszlai]

I'm more interested in how you get too small values. Could you give me an SVG when -r is propery set, and you still get some problems?

[berkut0]

Sounds great! Thanks a lot! Would there be an option for sampling level?

[berkut0]

I'm more interested in how you get too small values. Could you give me an SVG when -r is propery set, and you still get some problems?

If I encounter such a situation again, I'll post it here. But I can't always tell exactly what's causing it. The only thing that helps is to manipulate the "-r"

[domoszlai]

Would there be an option for sampling level?

I need to think about it. There should be something general, like maximal acceptable error

[Iqwertz]

I think we could generalize some settings into one, like --interpolation=linear,biarc,cubic-bezier where biarc is the default (G03/G04), cubic-bezier (G05) we already have and linear (G01/G02) could be trivially added. Then --generate-bezier would be deprecated

This would work for you?

This would be a really great option to have! Also an option to set the level of error for the linear approximation would be great.

[domoszlai]

I just released v0.2.1.0. It completely overhauls how error is calculated. gcode output should be much smaller and more accurate regarding the resolution parameter. Please give it a try

[berkut0]

I think I'll be able to try it soon. In general, only the logic of error handling has changed? But there is no "no arches" option yet?

[domoszlai]

Look at the branch linear. I need to update doc and release it (maybe next week), but you can test it already. It generates way bigger gcode for the same error tolerance and the result is not G1, but at least it proves how good the biarc approximation is 😁

[berkut0]

does it need to be compiled?

[domoszlai]

Yep, see instructions in README. Should be straightforward

[berkut0]

Please give me some clarification In what ranges should the new parameters be Especially the "curve fitting" option

[domoszlai]

linear, biarc, cubic-bezier

[domoszlai]

Any luck?

[berkut0]

I'm trying out But I encounter problems that are not specifically related to Juicy-Gcode Everything seems to be working. But I will be able to do in-depth tests only later.

[berkut0]

Actually, linear version works perfectly! It was possible only because of your tool!

[domoszlai]

Nice robot! :) I'll release it later this week

On Tue, Dec 13, 2022, 6:16 PM berkut0 @.***> wrote:

Actually, linear version works perfectly! It was possible only because of your tool! [image: изображение] https://user-images.githubusercontent.com/8849896/207398976-09593820-6b80-495d-ae88-a7a51e4f0fcd.png

— Reply to this email directly, view it on GitHub https://github.com/domoszlai/juicy-gcode/issues/17#issuecomment-1349113604, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAQ4GBMPBEZS4RYXXOLWM3WNCVNLANCNFSM6AAAAAARRXCVT4 . You are receiving this because you commented.Message ID: @.***>

[domoszlai]

v0.3.0.0 has been released, I close this ticket