ARC-Support

[Wurstnase]

While searching about the pinout for CNC Shield V3, I found an interessting page.

https://tkkrlab.nl/wiki/Cnc_machine

I've talked with the guys and they uploaded the code.

I took it from Marlin and modified and optimized it a bit it to suit teacup. Unfortunately its still with some non integer math but it works quite well for the CNC we use it with

I think this is a good starting point.

[Traumflug]

Nice!

While the ZIP file is from yesterday, I unpackaged it into my Teacup sources and found it to be based on a very old version of Teacup. Definitely from before the introduction of Configtool. File creation dates hint on March 16th, 2012(!).

[Wurstnase]

Yes, it is very old. It needs a rewrite. But nothing insoluble.

[Traumflug]

What disappoints me is that these guys don't care to update. Teacup received a whole lot of great enhancements over the last four years and they don't even recognize it. Then they talk about Teacup being inadequate and recommend to move to Marlin. A bit unfair :-/

Nevertheless, the ZIP indeed fits pretty well against four year old commits. I made branch arc-support with it.

P.S.: it even compiles, if with a few warnings.

[Wurstnase]

They intended to move, but they don't after successfully implementing the arc-thing. That wiki itself is not new. ;)

Getting the arc-support will help a lot of people (CNC-users) to move from grbl or other firmwares.

[Wurstnase]

Here a quote:

Actually i have tested and changed some to integer, i tried with more integer but the rounding errors became a bit to big (if i remember well). We're running it on an ATmega644 at 20Mhz, still runs smooth. It maybe helps that the ARC function puts out a lot of small segments so it not stalls in between. Still i bet some of the math could be translated into integer and be more fast.

[jgrjgr]

correct me if i'm wrong but isn't the arc support pointless as stl files don't support arcs, the gcode generated with arcs in it is just a "arc of best fit" and most firmware like marlin and smoothie just break it up into small little moves again anyway,

wasn't it brought in mainly to solve a usb-serial issue? we all pretty much run our gcode from sdcards don't we now?

[triffid]

Advantage of best fit arcs to stl then re segment in firmware is that rough models can come out looking much nicer as well as reducing serial load and allowing firmware to choose segment length.. Plenty of models on thingiverse that are too coarse to look nice, or too fine to print well.

Relying on model segmentation only helps when you control the model, I usually use 0.5mm On 31 Mar 2016 9:55 pm, "jgrjgr" notifications@github.com wrote:

correct me if i'm wrong but isn't the arc support pointless as stl files don't support arcs, the gcode generated with arcs in it is just a "arc of best fit" and most firmware like marlin and smoothie just break it up into small little moves again anyway,

wasn't it brought in mainly to solve a usb-serial issue? we all pretty much run our gcode from sdcards don't we now?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/Traumflug/Teacup_Firmware/issues/203#issuecomment-203951598

[jgrjgr]

fair enough, i'm used to producing models with high resolution arcs in them,

[Wurstnase]

I'm not thinking about 3D-printers. DXF supports real arcs and this is useful for CNC and similar machines.

[jgrjgr]

i would advise anyone generating gcode for cnc machines (in particular the big proprietary systems) they shouldn't assume they understand the gcodes for arcs , suprisingly a lot of cnc routers sold even today actually only run hpgl and the spooler software actually converts everything to hpgl, quite scarey to see how far behind they are

[Traumflug]

You're correct in all parts, @jgrjgr.

With the dda_clock() strategy Teacup has the opportunity to actually move true arcs. Like not splitting them into straight lines, but adjusting direction every 2 milliseconds depending on where the head actually is. Hard to find the time to implement this, because such an enhancement is deep in the details, only, still this patch gets us a bit closer to it; e.g. the G-code parsing part is usable for both.

[Wurstnase]

Can we change steps and direction in dda_clock()? Could we inject steps in dda_clock()?

[Traumflug]

Yes and yes, as long as you restore a sane state after each change.

That said, an algorithm in need of "injecting" something is likely a faulty one. Possible exceptions are user actions like Marlins Babystep feature, because users are unpredictable.

[Traumflug]

Good. Rebased branch arc-support to master, so it's reasonable recent now. All conflicts rather carefully fixed, there are chances it just works. When compiling, two intentional warnings will hint you on which additional #defines are needed in printer.xxx.h.

First review:

• Implementation of G-code parsing looks exactly right.
• G-code processing uses floats without apparent need for it.
• Unconditional debugging messages in many places, easily fixable.
• There is also something called "RESUME_PIN". Whatever that means, it isn't related to arc support and should go into a separate commit, if taken at all.
• This arc thing in its current form costs almost 4 kB binary size, so it needs either drastical reduction (500 bytes?) or wrapping in pairs of #defines along with a Configtool checkbox for enabling/disabling it.
• motion_control.c: needs severe cleaning, but looks better at the second glance than on the first glance. Only substantial problem I can see so far is that Teacup might become unresponsive for a rather long time if the number of segments is higher than the length of the movement queue.

Whoever wants that support in Teacup may refine and test these two commits.

[Wurstnase]

Good. Rebased branch arc-support to master, so it's reasonable recent now

Excellent!