Laser cutter position issues.

[chamnit]

@McNugget6750 : I've moved your question to a new issue on the Grbl v1.1 issue threads.

@chamnit Thank for the great work on grbl! I now converted over to v1.1 but I still have some issues that I had before and maybe you have the answer to these issues:

• I'm using grbl on an Arduino Nano on my K40 laser.
• I used grbl 0.9j with some extensions to be able to laser engrave at a decent speed using planned S commands.
• I have issues cutting arcs as can be seen in the pictures below:

This is the dxf file I'm trying to cut. A small quad copter design. This is the import within DXF2GCODE http://www.microforge.de/grblproblem/DXFImport.PNG

This is the interpretation of the generated gCode loaded into grbl Controller http://www.microforge.de/grblproblem/DXF-GCodeInterpretationBy%20grblController.PNG

And this is the cut that comes out of grbl. Please note that some parts are cut correctly but some larger parts are cut completely asymmetrically, the holes are in the wrong locations, the complete shape of the quad base place is asymmetrical and the motor mounts at the arm extensions are entirely unusable. http://www.microforge.de/grblproblem/LaserCutPartsByGRBLv1.1.JPG

Even though it looks like a step error, I'm very certain it is not a mechanical issue. I cut several parts before with no issues and only more complex files seem to produce these errors. I remember that I have seen this before a couple of years ago when I tried to implement a mill with this toolchain...

Here is the gCode file: http://www.microforge.de/grblproblem/completeCopter.nc

Any ideas?

[chamnit]

@McNugget6750 : This looks like mechanical error to me, but I could be wrong.

• First, does your g-code generate any Grbl error responses? If there were, you'll need to fix your program to be compatible with Grbl. Grbl will ignore those lines with errors.
• Second, does Grbl tell you its position correctly throughout of the problem areas of the job? If so, Grbl is outputting the step pulses correctly, since it directly computes machine position from step pulse counts.
• Third, are you using an Arduino Nano with a legit FTDI chip? Or a CH380? The latter has known issues with communication corruption.
• Finally, it wasn't clear if this issue is specific to Grbl v1.1. It looks like you had this exact same issue on your modified version of v0.9j? If it's not exactly the same, how was it different?

[McNugget6750]

The issue does not seem to be consistent so your theory might be valid regarding the china clone of my Arduino. I have an CH340G on the back side of my Nano. I heard this for the first time when I read about PicSender. I will try to get my hands on aa genuine Arduino nano and let you know how it goes.

BTW: GCode sender is not able to properly send this gCode to grbl. It stutters all the time at every arc and corner. I'm using my own gCode streamer that was inspired by your stream.py which works much better but doesn't implement complete communication with grbl but only the necessary commands.

[chamnit]

@McNugget6750 : UGS and bCNC both run about as fast as the stream.py script. The last time I checked that is. I'm pretty confident that your issue will resolve with an FDTI based Nano. The type of error you get from a CH380 USB-serial chip is similar to what you have shown. Anyhow, let me how it goes.

[maudette01432]

This to me looks somewhat mechanical as well. I saw a similar issue on our K40. The X axis belt was practically falling off the pulley the tension was so loose (it was fine for slow moves but once I started zipping left to right it would loose it. My belt finally just about fell off when I started rastering on it which lead me to probe around. On my machine if you move the carriage into the right position you can tighten the pulley through the power supply bay and the hole that's there (for a light or rotary axis). I have seen pulleys fall apart or behave erratically due to wear as well.

My other laser does weird things when the belts aren't tight.

[McNugget6750]

@maudette01432 Hm... it not the belts. It is either a configuration issue like G0 acceleration in between G1 G2 and G3 commands or the gCode is malformed and I can't see it in the grblController visualization. Or... my two completely different grbl versions 0.9j with laser engraving mods and 1.1 have issues interpreting arcs. I don't believe the latter because I'm currently the only one having problems with the grbl gCode interpreter.

I'm checking my configuration as I type. I'll also try run G1 commands instead of G0 just for comparison.

[McNugget6750]

Using G1 instead doesn't help. Here is my observation:

• When the machine runs more complex parts the error accumulates
• There is no visible error within one continues cut even if it involves many arcs and lines. Like the outline of a complex part.
• When traveling from one shape to the next, the machine stops for the new location, maks a short knocking noise which is barely noticeable and starts the cut. I believe this is the symptom of the error. It looks like it's trying to move a super tiny little bit but essentially skips those steps. But I can't see why or what in the gCode.

I will set the max speed to something stupid slow and try again tonight.

[maudette01432]

This sends fine with USGS to a "genuine" uno I did note that the G0 moves are pretty rapid. I know I have my rapids set to 5000....but I don't think I normally get there. On this big cut there are some larger G0 moves. I didn't actually cut but the positions reported back by the arduino match the positions in the GCODE. So it's stepping through everything.

What are you using for stepper drivers? Could be at the edge of as fast as they can go and the faster moves (they appear very fast as interpreted). The knocking noise is one of two things: 1 the belt is slipping as the machine tries to rapid or its stepping faster than the little stepper can handle. One thing I noted is the G0 moves reported back from GRBL appear way faster than what I would expect (i.e. the G0 federate is way up there). The one thing I note after your cut is the misplaced circle is after a big G0 move. I'm going to try a snippet of the GCODE on my laser where it seems to be doing it's thing and see if I have the same problem.

Can you dump your config? (With command $$)

I used JTECH 0.9G GRBL...have the issues with ARCS they are not followed correctly (documented but bad behavior). Not sure what the0.9J with laser mods is but if they followed the JTECH it could be something similar. That being said the start and endpoints were always right....they were just moved through incorrectly.

Version 1.1d GRBL - nice clean arcs for me.

[chamnit]

@McNugget6750 : If you have knocking, then it's mechanical. Either a belt or, more than likely, your stepper motors are skipping steps. Can you provide your Grbl settings? You probably need to adjust them. Lost steps are strongly related to too high of an acceleration and/or too high of a junction deviation setting (should be ~0.01mm). I would lower those. Max speed doesn't effect lost steps as much.

@maudette01432 : G0 moves at the maximum speed allowed. Whenever you move in a diagonal motion with two axes, it'll move at the root-mean-square of the max speeds of each axis. So, it'll move up to 1.414 times the max setting of an axis. Ever wonder why 3d printers print diagonally? This is why. You can accelerate faster and move faster in diagonals.

[maudette01432]

This cuts fine on my machine Goes back to the exact same zero every time....Definitely a mechanical issue. Forgive the wobbly lines my A3 cutter seems to have perpetually loose belts. Need to find a better solution to the stupid clips I have on there now. I upped my rapid rate to 50000 and made zig-zag G0 moves back and forth to the extreme of my machine and it returned to the same 0,0 location (note this is a G0 X0 Y0 - not a home I have no home switches).

[McNugget6750]

Thank you for all the responses so far! This is really helpful! And special thanks for testing! Now I know that it is something with my specific setup!

Here is my grbl config:

Grbl 1.1d ['$' for help] [MSG:'$H'|'$X' to unlock] $0=10 $1=25 $2=0 $3=3 $4=0 $5=1 $6=0 $10=8 $11=0.010 $12=0.002 $13=1 $20=0 $21=0 $22=1 $23=1 $24=200.000 $25=8000.000 $26=250 $27=5.000 $30=1000 $31=0 $32=1 $100=157.575 $101=157.575 $102=250.000 $110=10000.000 $111=10000.000 $112=10000.000 $120=1000.000 $121=1000.000 $122=1000.000 $130=300.000 $131=200.000 $132=200.000 ok

Tonight, I'm planning on reducing max speed first. I can't test it right now, now enough time.

In addition, here is my config.h http://www.microforge.de/files/config.h

Thanks a lot, Timo

[chamnit]

@McNugget6750 : At first glance, some of your settings are close to and exceed the 30kHz step rate that Grbl supports. To save flash space, Grbl doesn't check for this.

Your X and Y axes are pretty close to the max at 26.3kHz. Grbl should be able to handle it, but I have not tested the new Grbl v1.1 at those high rates yet. It wouldn't hurt to reduce those too to something like 8000 mm/min or less. (Also, it doesn't look like you use your Z-axis but it's about 41.7kHz. You need to reduce your Z-axis speed to something like 5000 mm/min or less, if you ever use it.)

I still think your acceleration settings are likely too high. It's hard to tell without knowing how you got the 1000mm/s^2 settings. I would start by reducing them by at least half to see if the problem goes away.

Also, make sure you use an Arduino that does not have the CH380 USB-serial chip. It may make all this testing hard to discern. We need to rule it out.

[McNugget6750]

First of: Thank you for checking everything!

I have the CH340B as it seems. Let me do the config tweeks first before I buy a new Arduino.

The acceleration is set so high because the runcat of a laser is very light weight. I had it working at 4000mm/s^2 and some guys in the K40 google Community even suggested higher settings (which I ruled out because they where unrealistic [12,000 and the like]). I need high accel for engraving properly without too much overscan.

I will lower the speeds in general. 4000 to 6000 seems to be what I can safely use but I'll follow your advice and turn it down significantly until I know everything works.

Honestly, I have personally not seen any communication errors at all with this chip. I have errors only in grbl when I give it wrong commands and of 10000 lines in a gcode file none gets an error response. Having said that, I don't know if all commands and transmitted numbers are received correctly. My indication that everything works is based on programming and verifying the 328p. But to be sure I might run a large loop back test with gCodes and the echo setting in config.h and let you know.

EDIT: all the spelling mistakes that sneaked in there by typing on a smartphone.

[McNugget6750]

Gentlemen, I found the actual symptom! Now we need to solve it.

I noticed, my motors shut down immediately after a command has been executed. Like G0 X50 Y50. At first I thought that's normal. I mean Marlin doesn't do it unless I tell it to, but hey, this is not Marlin, it's grbl. But then I noticed just now... the clonking noise I hear is the motors powering back up! Wait.. what?

It seems the motors power down in between every single command. There is no M84 in my gCode so I have to assume it is either a weird configuration that should not be possible or it is an issue with my board. Some cross talk or something.

However, during the split second in which the motor power is down I can move the run cat manually! That also includes the moment when the run cat is supposed to be stopped but there is still tension on the belt... and it moves a step by itself! This also explains why I can't see it during a continues motion, only after quick moves - but I can force it to skip in between commands by applying some small force to the run cat.

Video for more details here: https://www.youtube.com/watch?v=vwPfqWacUV4&feature=youtu.be

[chamnit]

@McNugget6750 : Set your $1 setting to $1=255. It'll prevent your steppers from disabling.

[McNugget6750]

Reporting problem solved!

Is that setting milliseconds or microseconds?

Thank you so much! Looks fantastic now:

[chamnit]

@McNugget6750 : It's milliseconds. Please read the Wiki page on configuring v0.9. It shows that when $1=255. It'll keep your steppers enabled all of the time.