Missunderstandings in G-Code interpretation

[VirToReal]

Hello everybody,

i made an CBC-"Milling" Machine by myself. It also can print in 3D if i had made an extruder ;-). I decided to use Marlin as Firmware on an Arduino-Board with a RAMPS-Shield 1.4 on it. It works pretty well but i got some annoying fails on milling with Marlin (i already know: "its not designed for that")...

At First: I used some Python-Script to convert PyCam ngc Code into RepRap-Gcode for 3D Printers (scaled-down settings / add Z axis and movement Speeds while Cutting / Traveling). The Result could be watched here: https://www.dropbox.com/s/iyifm093criudfr/VirToGravTest4_converted.gcode?dl=0 (converted) Original: https://www.dropbox.com/s/em8l3p4eqd9uimg/VirToGravTest4.ngc?dl=0

It works pritty awesome except of these 4 faults: (Dont mention that letters in the background)

Vir(T)oGrav: The letter "T" got an smaller right "outrigger"

VirT(o)Grav: The surrounding of the letter "O" dont stop at its starting point

VirToG(r)av: The surrounding of the letter "r" dront stop at its starting point

VirToGr(a)v: The "a" also got some awkward issues with its surrounding

I dont know why this happens, but it happens all the time, i made this milling 18x Times with always the same Results. I tried different speeds, differed jerk values, different highs, at last i let a pen draw the lines ;-).. always the same result.

Then i got a clou from a friend of mine: I use auto-bed-leveling to recalculate the large milling area (600x380mm) because its terrible uneven. With auto-bed-leveling its quiet great! (awesome feature btw.). The Idea was, these calculation in X Y because of the uneven bed will cause fluctuations in calculating the axes (because auto-bed-leveling is still under process (i thought)). So i tried without -> same result ;-(

I'm out of ideas and tired of this Problem... the gcode looks okay to me, cant see the issue until it became reality. Maybe someone can see something, maybe its an issue in Marlin.. I can only guarantee one thing: it is not of mechanical nature

[brainscan]

I think it's the gcode that's the problem, there are some interesting moves in it. Have you only tried this one file because if so that would make the most sense. You are using marlin in an unconventional way so I don't think it's really an issue with the firmware. Most of the part you have pictured looks good so I'd assume marlin is working correctly and is trying to interpret bad code. That happens when slicing parts for printing too so sometimes you have to make a new file or correct the code manually. I don't have any way to test your code at the moment to see if that's the problem, sorry.

Sent from my iPhone

On 21 Apr 2015, at 20:42, Benjamin Hirmer notifications@github.com wrote:

Hello everybody,

i made an CBC-"Milling" Machine by myself. It also can print in 3D if i had made an extruder ;-). I decided to use Marlin as Firmware on an Arduino-Board with a RAMPS-Shield 1.4 on it. It works pretty well but i got some annoying fails on milling with Marlin (i already know: "its not designed for that")...

At First: I used some Python-Script to convert PyCam ngc Code into RepRap-Gcode for 3D Printers (scaled-down settings / add Z axis and movement Speeds while Cutting / Traveling). The Result could be watched here: https://www.dropbox.com/s/iyifm093criudfr/VirToGravTest4_converted.gcode?dl=0 (converted) Original: https://www.dropbox.com/s/em8l3p4eqd9uimg/VirToGravTest4.ngc?dl=0

It works pritty awesome except of these 4 faults: (Dont mention that letters in the background)

Vir(T)oGrav: The letter "T" got an smaller right "outrigger"

VirT(o)Grav: The surrounding of the letter "O" dont stop at its starting point

VirToG(r)av: The surrounding of the letter "r" dront stop at its starting point

VirToGr(a)v: The "a" also got some awkward issues with its surrounding

I dont know why this happens, but it happens all the time, i made this milling 18x Times with always the same Results. I tried different speeds, differed jerk values, different highs, at last i let a pen draw the lines ;-).. always the same result.

Then i got a clou from a friend of mine: I use auto-bed-leveling to recalculate the large milling area (600x380mm) because its terrible uneven. With auto-bed-leveling its quiet great! (awesome feature btw.). The Idea was, these calculation in X Y because of the uneven bed will cause fluctuations in calculating the axes (because auto-bed-leveling is still under process (i thought)). So i tried without -> same result ;-(

I'm out of ideas and tired of this Problem... the gcode looks okay to me, cant see the issue until it became reality. Maybe someone can see something, maybe its an issue in Marlin.. I can only guarantee one thing: it is not of mechanical nature

— Reply to this email directly or view it on GitHub.

[Wurstnase]

gcode looks ok for me. You should tighten your belt. This is maybe to loose and you have a backlash.

[brainscan]

I've never seen a loose belt give exactly the same result 18x in a row at different speed settings. I have seen bad code run over and over again with the user expecting different results, which is also a sign of madness.

Sent from my iPhone

On 22 Apr 2015, at 08:22, Wurstnase notifications@github.com wrote:

gcode looks ok for me. You should tighten your belt. This is maybe to loose and you have a backlash.

— Reply to this email directly or view it on GitHub.

[Wurstnase]

Yes, right. Just took a look at the gcode. If that would be the issue, the end at the VirT(o)Grav should be under not over the starting point.

What are your steps/mm? What kind of driver you are using?

[brainscan]

Have you tried running the code through a simulator/visualiser? That would confirm or not if its your problem, when I get home later I might copy and paste your code into something like slic3r or repetier and see if likes it or not. There are plenty of free ways to check it so if they don't work I'll try something else.

An alternative might be to create the file using slicing software and then just manually alter the code so it mills down rather than printing up, hope that makes sense.

Sent from my iPhone

On 21 Apr 2015, at 20:42, Benjamin Hirmer notifications@github.com wrote:

Hello everybody,

i made an CBC-"Milling" Machine by myself. It also can print in 3D if i had made an extruder ;-). I decided to use Marlin as Firmware on an Arduino-Board with a RAMPS-Shield 1.4 on it. It works pretty well but i got some annoying fails on milling with Marlin (i already know: "its not designed for that")...

At First: I used some Python-Script to convert PyCam ngc Code into RepRap-Gcode for 3D Printers (scaled-down settings / add Z axis and movement Speeds while Cutting / Traveling). The Result could be watched here: https://www.dropbox.com/s/iyifm093criudfr/VirToGravTest4_converted.gcode?dl=0 (converted) Original: https://www.dropbox.com/s/em8l3p4eqd9uimg/VirToGravTest4.ngc?dl=0

It works pritty awesome except of these 4 faults: (Dont mention that letters in the background)

Vir(T)oGrav: The letter "T" got an smaller right "outrigger"

VirT(o)Grav: The surrounding of the letter "O" dont stop at its starting point

VirToG(r)av: The surrounding of the letter "r" dront stop at its starting point

VirToGr(a)v: The "a" also got some awkward issues with its surrounding

I dont know why this happens, but it happens all the time, i made this milling 18x Times with always the same Results. I tried different speeds, differed jerk values, different highs, at last i let a pen draw the lines ;-).. always the same result.

Then i got a clou from a friend of mine: I use auto-bed-leveling to recalculate the large milling area (600x380mm) because its terrible uneven. With auto-bed-leveling its quiet great! (awesome feature btw.). The Idea was, these calculation in X Y because of the uneven bed will cause fluctuations in calculating the axes (because auto-bed-leveling is still under process (i thought)). So i tried without -> same result ;-(

I'm out of ideas and tired of this Problem... the gcode looks okay to me, cant see the issue until it became reality. Maybe someone can see something, maybe its an issue in Marlin.. I can only guarantee one thing: it is not of mechanical nature

— Reply to this email directly or view it on GitHub.

[Wurstnase]

I just visualize the code. The code isn't the problem. My guess it's something with the slow speed.

[brainscan]

I find that odd that after 18 attempts with various speed settings you think it's a speed issue, especially as apparently all results are the same. In my experience if it's a belt or speed issue the results are never exactly the same, sorry if that's not what you have experienced.

Sent from my iPhone

On 22 Apr 2015, at 12:59, Wurstnase notifications@github.com wrote:

I just visualize the code. The code isn't the problem. My guess it's something with the slow speed.

— Reply to this email directly or view it on GitHub.

[Wurstnase]

It depends on his setup. How much steps he hast for each mm. At such slow speeds Marlin can have issues. The interrupt works only on 16bit. At 2MHz it means the steprate is limited to min 32steps/s. His max speed could be at ~250 steps/s. This could makes the problem. It's just an idea...

[VirToReal]

Thanks for the interest of my problem!

I visualized the Gcode in different free programs and cant find any problem in the G-Code (i should had mentioned that, sorry ;-). Brainscan is right about belt problems, i also adjusted the tautness with no changes on the end-result.

But your comment Wurstnase about drivers, i got different types on the X any Y Axis. Maybe this can be a great explanation for my worrys? The Y and Z are driven by a DRV8825 (2x Y Axis on 1xStepperengine / 1x Z Axis 2x Stepperengine). The X Axis is driven by an China-Shit driver which came with the arduino. I used that because of the low current i needed for that "easy" Axis... i think that was an misstake :-(... i was convinced every stepper counts the same distance. I'm not sure about that now ;-)

Stepping: X: 80 Y: 80 Z: 160 steps/mm Max Feedrate: X: 250 Y: 250 Z: 4 Microstepping: X: 1/16 Y: 1/16 Z: Full-Step

I made best results on milling with 150mm/min -> 0,5mm Graver, so the engraving on the picture mentioned above.

Would it help to change the X-Axis Driver to the same one like the others?

[nophead]

For some reason your pictures just show an error message.

Different drivers shouldn't matter as long as they work and don't skip steps.

[brainscan]

Hmm, yeah I hadn't really thought about that. I also hadn't really thought about the extra force needed when milling and the fact it's using belts would show this sort of thing if they were stretching. I'm sorry for thinking it was the code too, I had a quick look on an online viewer and couldn't see a problem. Just seemed most likely to me but I was mistaken.

Strange that it's so consistent and that some letters look great and others not so.

Sent from my iPhone

On 22 Apr 2015, at 16:30, Wurstnase notifications@github.com wrote:

It depends on his setup. How much steps he hast for each mm. At such slow speeds Marlin can have issues. The interrupt works only on 16bit. At 2MHz it means the steprate is limited to min 32steps/s. His max speed could be at ~250 steps/s. This could makes the problem. It's just an idea...

— Reply to this email directly or view it on GitHub.

[VirToReal]

I will try this out with a pen and faster "print" speed.

Brainscan: i also got this problem with a Pen, dont think the belt cause this problem. But i tried only at 150mm/min. I will scale this up and report, you will hear from me tomorrow after work ;-)

[brainscan]

I know from your previous post that you had used a pen with the same result so I was fairly sure you had them tight, also because you had tried different speeds I thought that wasn't the problem. I hadn't thought that if all the speeds are still below a certain threshold you'd get the same error. I think wurstnase is on to something as I'd forgotten about how weird my printer goes if I accidentally ask it to go really slowly. Sorry for basically being unhelpful but I am interested in what's causing it.

Sent from my iPhone

On 22 Apr 2015, at 19:19, Benjamin Hirmer notifications@github.com wrote:

I will try this out with a pen and faster "print" speed.

Brainscan: i also got this problem with a Pen, dont think the belt cause this problem. But i tried only at 150mm/min. I will scale this up and report, you will hear from me tomorrow after work ;-)

— Reply to this email directly or view it on GitHub.

[VirToReal]

I made a quick test with the following result: at the last test the x-axis china-driver quitted his duty... but this is not the problem, the Y axis drive various distances.. :( Same Problem as alway, at the same points.. the 150mm/min one just looks ugly because of the ink and its time to flow out of the pen

I will test tomorrow with disabled auto-bed-leveling in firmware

[brainscan]

Even though the x driver gave up it does seem like there are fewer errors (compared to the original picture) as the speed goes up, although it is still very slow. If you are only using a pen I would think 20-30mm/s would still be slow but shouldn't lead to the problem wurstnase mentioned. If that still isn't the problem then will have to try something else.

Sent from my iPhone

On 23 Apr 2015, at 20:37, Benjamin Hirmer notifications@github.com wrote:

I made a quick test with the following result:

at the last test the x-axis china-driver quitted his duty... but this is not the problem, the Y axis drive various distances.. :(

I will test tomorrow with disabled auto-bed-leveling in firmware

— Reply to this email directly or view it on GitHub.

[VirToReal]

I replaced the defective driver with another Chinese driver and ran the test again at different speed written next to the "painting" in mm/min. I also adjusted the jerk values during testing as noted on the sheet. The last one at the bottom is "printed" with auto-bed-leveling disabled in firmware.

Btw.: these "prints" are made with mounted Dremel in place. So don't mention the "letter shivering." At the speed of 1500mm/min i stabilized the dremel on its wire during printing, because it's only mounted on its thread. Further test with speed improvements were against Max speed of the Z Axis, (because I just adjusted Speed Multiplier).

I still has no clue of that problem...

[thinkyhead]

We just increased the microstep delay to 2µs (for the sake of DRV8825 drivers). Hopefully this has no bearing on performance. As I understand it, using 32x microstepping will generate more activity than 16x microstepping and put more strain on the board. But you should still be within tolerances using a Mega2560.

[Wurstnase]

We don't have any delay at normal moving.

[thinkyhead]

Oh right, only in babystepping. I wonder if a delay would help, or is it already "delaying" in some other way, such as having some code instructions in between…?

[Wurstnase]

There is no real delay. At this slow speed, below 10.000 steps/s you can try the toshiba-mode.

[VirToReal]

I'm not using 1/32 microstepping mode, just 1/16 on the X Y Axis. The speed i noticed next to the pen-drawings on my last picture are in mm/min. The last one with 1500mm/min was the fastest one with the same issue. These would be 2000 steps/s. This is fast i think but not fast enough? What is that toshiba-mode?

[Wurstnase]

2000 step/s is ok. https://github.com/MarlinFirmware/Marlin/blob/Development/Marlin/Configuration.h#L322

[VirToReal]

Hello again,

sorry it took some time, i updated to the newest firmware because the Toshiba-stepper Firmware seems to drive only one of my two Y-Axis Steppers. So i updated to the newest and tried again, same result. Just one Stepper (the original one on the Ramps 1.4 board) burst forward, the other one won't do a thing until i commit toshiba-drivers out again.

Of course i tried with the newest firmware ;-) same result, just the sound on jerking sounds smoother ;-)

[Wurstnase]

Go in the stepper.cpp. At line ~580 you find something like this

           #ifdef CONFIG_STEPPERS_TOSHIBA
        /**
         * The Toshiba stepper controller require much longer pulses.
         * So we 'stage' decompose the pulses between high and low
         * instead of doing each in turn. The extra tests add enough
         * lag to allow it work with without needing NOPs
         */
        #define STEP_ADD(axis, AXIS) \
         _COUNTER(axis) += current_block->steps[_AXIS(AXIS)]; \
         if (_COUNTER(axis) > 0) { _APPLY_STEP(AXIS)(!_INVERT_STEP_PIN(AXIS),0); }
        STEP_ADD(x,X);
        STEP_ADD(y,Y);
        STEP_ADD(z,Z);
        #ifndef ADVANCE
          STEP_ADD(e,E);
        #endif

        #define STEP_IF_COUNTER(axis, AXIS) \
          if (_COUNTER(axis) > 0) { \
            _COUNTER(axis) -= current_block->step_event_count; \
            count_position[_AXIS(AXIS)] += count_direction[_AXIS(AXIS)]; \
            _APPLY_STEP(AXIS)(_INVERT_STEP_PIN(AXIS),0); \
          }

        STEP_IF_COUNTER(x, X);
        STEP_IF_COUNTER(y, Y);
        STEP_IF_COUNTER(z, Z);
        #ifndef ADVANCE
          STEP_IF_COUNTER(e, E);
        #endif

      #else // !CONFIG_STEPPERS_TOSHIBA

use this ^^ code and replace yours and test again with #define toshiba-stuff

[thinkyhead]

@Wurstnase Do you also recommend this as a permanent patch for Marlin, or just for certain hardware?

[Wurstnase]

I think there could be a better way which will work for Toshiba and other drivers without that #define.

The idea i have to put the 'Calculate new timer value' in the loop. Write step high, then if last step, calculate the new timer value, write step low. This will give a lot of lag in single stepping mode.

[Wurstnase]

@thinkyhead https://github.com/Wurstnase/Marlin/tree/new_double_stepping this is the idea i've talked.

[thinkyhead]

@Wurstnase Those changes seem comprehensive enough. I was wondering, with the loop gone, maybe this…

for(int8_t i=0; i < step_loops; i++) {
  advance -= advance_rate;
}

…can be replaced with…

if (step_loops > 0) advance -= advance_rate * step_loops;

[Wurstnase]

This needs also some work for the last step (break). I will prepare a PR soon.

[VirToReal]

Thanks Wurstnase, your patch worked well, but the result is the same. No differences noticeable:

Old an new Firmware "printed" also with a feedrate of 600mm/min

I noticed some differences (not related to toshiba-setting) between 2000steps/sek and 800steps/sek

(left 800 / right 2000) dont know why or whats the reason this always happens at low speeds at the same position

I also clipped out the O from VirT(o)Grav and align it at same distance and let pyCam gcode it again. The result looks fancier than bevor: Again i dont know whats the difference between placed in the Word VirToGrav and Stand-Alone... why is there a different Result? There are noticeable differences between the direction the circles are printed, i made a drawing on the left to hi-light that.

Again i made some tests as close as possible to the X / Y Engine (the others are as far away as possible) with the same result: i took the pen just a bit to far to the sheet ;-)

So, why is that? Got no ideas left :-(

[thinkyhead]

@HardRainbow Are you able to replace the pen with a ballpoint? It would make thinner lines, and it may be easier to see the movements.

[VirToReal]

here we go: nice to see here, how the letter T change his form like mentioned above between 400mm/min and 1200mm/min

hope this will help in any way

[AnHardt]

What i see, looks like backlash. Maybe it's not the belts, but tilling the z-axis under load.

[thinkyhead]

It is sometimes hard to isolate what might be mechanical issues, but begin by tightening everything – except the belts (or other drive mechanisms). You want some tension on the belts, but not too much. If you have a way to reliably tension them that is one place to start. Of course, ensure there's no play in the movement axes. Check that when the Z level goes up, there's nothing lagging... all the usual tightening and isolation. If that doesn't help then start playing with acceleration, jerk, etc... within each speed range, and hopefully some consistent variable will start to jump out.

[VirToReal]

@AnHardt I already checked for backlash of any backlash of the Z Axis with an USB Microscope, there is just a littl settldown at one Side, i made a table of that: its an older Table, cant find a newer one with nicer results jet ;-)

Measure of Z level before and after printing without any differences -> should be ok :)

@thinkyhead Youre right, it is very hard the find mechanical issues, but there are some things which let me guess this cant be of mechanical nature, the the start surrounding in letter VirToG(r)af wont fit with the end, but at the first r-letter Vi(r)ToGrav it works. No matter of speed nor position..

i tried something: i turned the SVG in Inkscape at 90° and run pyCam again,

i also increased the z-level on drawing on a hard drive ;-)

same results :-(

@Wurstnase in toshiba-stepper mode (with your patch), after a "print", i manually change to position of the "extruder" with relative positioning -> 100mm -> he increases speed and at 2/3 of the way he slow down and looses steps after slowing down (on X and Y Axes). After reset of the arduino everything works fine again. I dont know if the reason is because of toshiba-driver-setting or your patch, because i cant use this setting without your patch ;-) hope this description will help you :-S

At the End: i ordered a new stepper for the x axis, so every driver would be of the same kind (DRV). I hope this will help (i dont guess so), you will hear from me soon ;-)

Greetings and thanks to everybody for the interest in my problem

[thinkyhead]

@HardRainbow Excellent to have it isolated to the software. This is the kind of very subtle behavior that would be impossible to see in plastic, but which a ball-point makes so much clearer! The "T" shape is a good controlled test, so let's keep focusing on that little anomaly and see if we can isolate some cause. It might be some unavoidable artifact of the interaction between the mathematics, stepper timing, and mechanics, but fixable or unfixable, that's what we want to know.

Do the artifacts scale up and down also? Or, do they only appear when printing certain shapes at certain sizes? And how many segments are in those regions where the glitches appear? Are there a lot of very small segments, or is it a simple hard corner…?

[VirToReal]

Scale Up and Down Test:

Speed: 600mm/min

Speed: 1500mm/min (Detached Dremel)

I reused this logo and made up some new Shape-Sizes. The original one measures a size of 90mm width, so i made examples with 60 / 75 / 105 and 120mm (Resizing with Inkskape and slicing with pycam). At the size of 75 i forgot the "infill" ;-), i thought it wouldnt be necessary

Every "print" in their speed category made in its original place, i just repositioned the sheet. The sheet at the speed of 1500mm/min is made at a different position. The results are exactly the same!! I just noticed differences between 60 and 75:

Of course the GCodes are different (With different start and ending points): https://www.dropbox.com/s/1i0z4dig9fezhvv/VirToGravTest4_resize_60_converted.gcode?dl=0 https://www.dropbox.com/s/mva4wqtl3qrgtna/VirToGravTest4_resize_75_converted.gcode?dl=0 https://www.dropbox.com/s/iay4l6akqeb6niq/VirToGravTest4_resize_105_converted.gcode?dl=0 https://www.dropbox.com/s/9e7pc0rxkdojtx9/VirToGravTest4_resize_120_converted.gcode?dl=0

I also made a Movie of the "engraving" of the 120mm one: https://www.dropbox.com/s/t55mn8kfz3z0k5g/VID_20150508_175440.3gp?dl=0 Dont mention the "stucking" of the Z Axis, its the error i at fast speeds i already mentioned Wurstnase in a previous post because of the Toshiba-Setting and/or the replaced C-Code. I didnt set back to original yet. You can watch its couse at beginning and right bevor the letter "O" Also dont mention the clicking, its the sound of the auto-bed-leveling because of the Z-Axis threads are guided by bearings at the top.

these would be the resize test. Im looking forward for getting more ideas in mind to get closer to this problem.

Collected Information yet: Shapes changed its behaviour between the size of 60 / 75. 75/90/105/120 looks exactly the same. No changes between the speed of 600 / 1500 mm/min.

[nophead]

I think you simply have backlash. What type of pulleys are you using?

Note pulley backlash is not like gear backlash. You don't get a dead spot when you change direction because the teeth don't slip. What happens is when you change direction the new teeth engage at the opposite side of the valley. After half a turn in the new direction all the teeth are engaged on the new side and the distance travelled is a little bit short. So where it stops depends on which direction it came from and also how far it travelled in that direction. I.e. the backlash is distributed over a full half turn rather than happening immediately on direction change.

To check for it make a simple pattern such as a large H ( bigger than half a pulley revolution). You should see the verticals misaligned top to bottom.

[VirToReal]

@nophead, Good Idea, never thought about that! I got GT2 Belts on a 20th Teeth Pulley -> 40mm each Turn i made some pattern for controlling if there is any backlash because a couldnt see any difference with the Letter H in different sizes: This one was "printed" 6xTimes:

G-Code File with randomly printing of Squares: https://www.dropbox.com/s/7oyn0kkge5cskdb/PatternV2_converted.gcode?dl=0

Testprint with X-Boxes:

G-Code File with randomly printing of X-Boxes and Squares: https://www.dropbox.com/s/c275u3236d4d44z/PatternV3_converted.gcode?dl=0

Seems there is no backlash, and if, its not that big like mentioned in all my other problem posts.

But thanks for the idea!

[thinkyhead]

@nophead That's a very good description of pulley backlash. If it's alright I'm going to borrow some of that verbiage and make a page for Backlash on the RepRap wiki, which somehow doesn't have one yet.

From what I understand the best test for backlash is to print circles at different sizes. If there's backlash it will be pretty obvious, because they will come out as ovals.

[nophead]

Yes fine to use my verbiage.

Circles reveal conventional backlash (where there is a dead spot during reversal) as you get two flats but they don't show pulley backlash as you are not going to notice an oval where one diameter is say 0.2mm less than the other.

The best way to show it is draw two lines that should meet end to end, but draw one having come from more than half a pulley circumference in one direction and the other the same distance from the other direction.

[AnHardt]

; Backlash test pattern

G21 G90 F500 G1 Z1 G1 X0 Y0 G1 X10 Y10 G1 Z0

G1 X20 G1 Y20 G1 X30 G1 Y10 G1 X40 G1 Y20 G1 X50 G1 Y10 G1 X60 G1 Y20

G1 X50 G1 Y30 G1 X40 G1 Y20 G1 X30 G1 Y30 G1 X20 G1 Y20 G1 X10 G1 Y30

G1 X20 G1 Y40 G1 X30 G1 Y30 G1 X40 G1 Y40 G1 X50 G1 Y30 G1 X60 G1 Y40

G1 X50 G1 Y50 G1 X40 G1 Y40 G1 X30 G1 Y50 G1 X20 G1 Y40 G1 X10 G1 Y50 ...

Ideally there will be a perfect cross in the circle.

[VirToReal]

Good idea @AnHardt , my idea was not that efficient ;-)

I made that test and i guess its pritty good, sooo what next ;-)

[AnHardt]

I'm seriously impressed. :-) But without an idea for now. :-(

[VirToReal]

i tested with different arg segment and arc correction values (was not my idea :-) thanks to Holger :-), the idea was if there is a bug which will result in a mad behaviour. But it seems it quite works well.

Will try it also with complete 0 values and will place feedback if something changes

[AnHardt]

As far i remember the ARC settings only apply to G2 and G3. There are no arcs in your code.

[VirToReal]

this make sense, but take a look at the "V" letters, you will see differences on decreasing the values, it loses it smoothness :-O

[brainscan]

Was the paper completely flat when you took this picture? The lines aren't straight or parallel with each other. It looks good but when I placed a grid over your picture it shows they're not straight. It could be because I'm only working from the picture and it could distorted but it's worth checking again.

Sent from my iPhone

On 12 May 2015, at 16:59, Benjamin Hirmer notifications@github.com wrote:

Good idea @AnHardt , my idea was not that efficient ;-)

I made that test and i guess its pritty good, sooo what next ;-)

— Reply to this email directly or view it on GitHub.

[AnHardt]

Anyone out there who knows a bit more about the ARC_DETECTION feature in Marlin?

[VirToReal]

@brainscan the picture was not completely flat (not much space in my cellar ;-), took the paper home and here we are: