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

[nophead]

AFAIK there is no arc detection in Marlin. That is done in some slicers. Marlin simply has G2 and G3 arc codes and I get the impression those are buggy, so nobody uses them for 3D printing.

[Wurstnase]

maybe a problem with the Dir-setup? could you try this branch? https://github.com/Wurstnase/Marlin/tree/outbits_rework

[brainscan]

I did think that was probably the case but thought it worth checking. Still scratching my head on this one.

Sent from my iPhone

On 12 May 2015, at 21:55, Benjamin Hirmer notifications@github.com wrote:

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

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

[VirToReal]

@Wurstnase what do you mean with Dir-Setup?

https://www.dropbox.com/s/q6nwsnw7mspa2of/error_compile.txt?dl=0~~~

~~~it have to be something about the servo-engines ;-) (use one for auto-bed-leveling)
i rechecked the configuration files twice with a program called meld, everything should be fine, maybe you want so see them yourself:
https://www.dropbox.com/s/wvv3v1u8ah56aai/Configuration.h?dl=0
https://www.dropbox.com/s/lscrrsqoolv8nl6/Configuration_adv.h?dl=0~~~

EDIT:
sorry i'm stupid... i just moved your folder in my old one :-1: 

[Wurstnase]

This is now in the development branch. You need only to download it again.

[VirToReal]

@Wurstnase i uploaded your branch but the results are sobering :-( see yourself: the new x-driver came today, i replaced the cheap one but the results (as mentioned) are the same.

Now i figured something out... It seems there is some kind of grid and with its resolution the g-code will be interpreted. I made some example: Left: interpretation of the G-Code (made by pycam) with Chillipeppr. http://chilipeppr.com/tinyg Right: the drawing of Inkscape (i poorly draw the letter O) seems the gcode interpreter always makes this big steps when something changes on its grid. i think thats the cause of these issues but in fact i absolutely have no idea how this works anyway ;-) (just a guess) i will test this out

[thinkyhead]

@HardRainbow The planner does approximate sometimes, and then there's the whole issue of acceleration on 4 axes… But, can you also show a detail of the same region of that "O" from your GCode, as it appears in a graphical GCode viewer, such as Repetier Host, Cura, Pronterface, etc?

[VirToReal]

The left picture was made with an gcode viewer https://github.com/synthetos/TinyG/wiki/Chilipeppr Same shape like the inkscape one

Scott Lahteine notifications@github.com schrieb:

@HardRainbow The planner does approximate sometimes, but can you also show a detail of the same region of that "O" as it appears in a GCode viewer, such as Repetier Host, Cura, etc?

---

Reply to this email directly or view it on GitHub: https://github.com/MarlinFirmware/Marlin/issues/1954#issuecomment-104113530

[thinkyhead]

@HardRainbow Great. Ok, well I suppose the next thing is to somehow log what's going on in the planner that might differ from the input.

[VirToReal]

I'm very very very sorry..... its an mechanical issue... It was very hard to find out, but its the Belt-Length on the Y-Axis. I tried out the Belt-Tightening at the very start. I was not able to see it because it only appears about 270° of the tightening-screw... My Skills in seeing necessary thinks wasnt good enough, too. I cant solve the problem by tightening the belt, seems it is quite to long... i looking for some software solutions..

I will post some pictures for showing the differences soon.

Thanks on all of you for helping me out! And sorry for all of this...

[brainscan]

I don't think there is any software that can correct mechanical problems. It would surely be more difficult than just fixing the mechanical problem and would be specific to one problem on one machine.

Sent from my iPhone

On 13 Jun 2015, at 12:06, Benjamin Hirmer notifications@github.com wrote:

I'm very very very sorry..... its an mechanical issue... It was very hard to find out, but its the Belt-Length on the Y-Axis. I tried out the Belt-Tightening at the very start. I was not able to see it because it only appears about 270° of the tightening-screw... My Skills in seeing necessary thinks wasnt good enough, too. I cant solve the problem by tightening the belt, seems it is quite to long... i looking for some software solutions..

I will post some pictures for showing the differences soon.

Thanks on all of you for helping me out! And sorry for all of this...

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

[VirToReal]

the only problem is, it cant be fixed mechanically ^^ the printer is just to big... only solution would be adapting to trapeze threaded rods. For the cost of speed... Also the layout have to change completely. I try to find out some other solution ;-) maybe there is one, if so, you will hear from me

[brainscan]

How about using pulleys and carbon fishing line like they do on some deltas and corexy, it can be put under huge tension. I haven't tried it myself but from what I read about it would possibly suit a larger printer.

Sent from my iPhone

On 13 Jun 2015, at 15:44, Benjamin Hirmer notifications@github.com wrote:

the only problem is, it cant be fixed mechanically ^^ the printer is just to big... only solution would be adapting to trapeze threaded rods. For the cost of speed... Also the layout have to change completely. I try to find out some other solution ;-) maybe there is one, if so, you will hear from me

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

[VirToReal]

@brainscan Sounds nice but read this:

Sorry for this... its not over yet... i was wondering because of the R Problem which shows no differences at all...first one is okay, the other one is wrong. So i made an test, with the R- Itself, and its last previous Z0 Point. I also moved that previous Z-Point on its hight. By moving above the starting point of the R-Surrounding, its start position is higher than bevore...

Sorry, got no Cam here, will show pictures as soon as possible. Seems its some rounding mistake at all.. i tested with an friend of mine on his old 2013 Marlin firmware, its fine at that machine (most identical hardware setup). Would be nice if that G-Code file can be tested on other new Marlin Firmware.

Here the Test-G-Code Files: https://www.dropbox.com/s/m5eiy1ewvabkxik/VirToGravTest_R_Test3_converted.gcode?dl=0 https://www.dropbox.com/s/8atis8npzhtr5kp/VirToGravTest_O_Test2_converted.gcode?dl=0

Some Viewer to look at it: http://chilipeppr.com/tinyg

Here the "R"-Test: (printed multiple times in same position)

Here the "O"-Test: (printed multiple times in same position, row 1. got a different direction than row 2.)

Some Visual Help for the "R"-Test, First the Pen dropped left near the R-Surrounding, if the Pen dropps above the hight of the "R"-Surrounding the error appears (last 2. "R" letters)

[VirToReal]

Ah sorry, it seems to be an mechanical problem too... i used the firmware we know it worked, it dont work on my machine so it must be mechanical.

Sorry ... i close this and let it closed ;-)

_EDIT:_ I got a solution: If the Belt is tightened to strong, the gaps between the teeth’s of the belt have more space and the pulley wont fit well in it. If the belt is not tight enough, the belt itself begin so expand and relax in motion. The longer the belt, the more this problem will show.

Thanks to @AnHardt because of his Test-Pattern. I also made some picture-post in the previous post of that pattern. Just for notice: its not good enough if you want an perfect result. The lines have to fit perfectly to each other.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.