Ask Grbl CNC questions here.

Hi, i have a problem with my grbl (maybe software setup). When I use laserGRBL software for laser engraving and use "line to line tracing" mode, speed wont be constant. Picture like 10x10cm engraving more than 5hour? I just like constant speed. My problem is in link below.
Greetings

 

Is your feed rate constant? (i.e. what's the feed rate in your GCode file). Doubt it's GRBL doing it. Looks like binding. Check your rails and bearings. What happens when you jog?

 

Feedrate I set in LaserGRBL software. Feedrate is not constant. Rail in bearing is good. Problem is in Laser GRBL settings.

 

Make sure you have $32=1 in your grbl settings. It may be pausing to allow the "spindle" to come up to speed.

 

What do I have bozo'd that is causing G53 G0 Z0 to slam into my Z stop?

The machine has been homed. I've also set a WCS to a mere 9.5mm under the Z-stop. G53 G0 Z-1 works a treat. So much so I've swapped out the G53 G0 Z0's for it.

 

G53 is machine co-ordinates, so you are telling it to hit the Z stop.
Alex.

 

Is Z0 at the switch actuation position or at the pull-off position? I thought it was the latter.

Check your pull-off distances, check for missed steps on Z. Other than that, this just seems odd.

 

pull off position? I'll look into that.

The g-code is from the openbuilds grbl thingus for fusion. Oh, I did reset a bunch of -10s to 0s. Well. That might be a problem.

 

I have a question about feed rate precision. I have a camera gimbal that I want to use to track objects that more along a mathematically predictable path. I calculate the motion, getting azimuth and elevation numbers, on a 32-bit Arduino M0. I then send this information to grbl, running on an Arduino Nano.

The "number cruncher" calculates the position every five seconds, and passes the "next" position to grbl using X for azimuth and Y for elevation. Units are in degrees. I have the steps-per-unit right, because the gimbal always moves to the right position.

However, if I command a movement at a low speed, the movement occurs much faster than I command. I have tried G93 and G94 feed rate modes, but both exhibit the same problem. What should take exactly 5 seconds takes less than 3. I printed out '?' data and fed some of the numbers into a spreadsheet (included below). I've also attached a sample Gcode file.

I got the status at 1-second intervals and calculated the actual movement during that time, based on the difference in position. As the speed increases, the "anti-lag" gets smaller.

How can I make grbl stick to the commanded feed rate for small moves?

Code:

                                                       Actual           Commanded
    X          Y      dX        dY      Dist           Rate(deg/min)    Rate
-117.88     25.093   0        0        0               0 
-117.683    25.43    0.197    0.337    0.3903562475    23.4213748529    17.44
-117.472    25.768   0.211    0.338    0.3984532595    23.9071955695 
-117.275    26.116   0.197    0.348    0.3998912352    23.9934741128 
-117.134    26.353   0.141    0.237    0.2757716447    16.5462986798 
-116.938    26.69    0.196    0.337    0.3898525362    23.3911521734    18.64
-116.727    27.027   0.211    0.337    0.397605332     23.8563199174 
-116.516    27.376   0.211    0.349    0.4078259433    24.4695565959 
-116.333    27.68    0.183    0.304    0.3548309457    21.2898567398 
-116.122    28.017   0.211    0.337    0.397605332     23.8563199174    19.97
-115.911    28.355   0.211    0.338    0.3984532595    23.9071955695 
-115.686    28.704   0.225    0.349    0.4152420981    24.9145258835 
-115.475    29.041   0.211    0.337    0.397605332     23.8563199174 
-115.222    29.424   0.253    0.383    0.4590185181    27.5411110887    21.45
-114.997    29.773   0.225    0.349    0.4152420981    24.9145258835 
-114.772    30.11    0.225    0.337    0.4052085883    24.3125152956 
-114.547    30.459   0.225    0.349    0.4152420981    24.9145258835 
-114.463    30.582   0.084    0.123    0.148946299      8.9367779429 

 

I suspect you are running into the issue of acceleration. Have you played with the settings? You will never be able to get truly linear because of it but you might be able to minimize it's effect.

 

I don't know about that. Wouldn't acceleration issues make it take more time to complete the move, not less?

 

Short intervals will never get up to full speed. Long intervals will spend most of their time at speed. So, long intervals will have an average speed close to the F number and thus their time will be closer to F*t. Short intervals, much less.

Note also that grbl (or any cnc controller) doesn't guarantee precise speed because of the acceleration issue. It's much more concerned with getting position correct and ensuring coordination of multiple axes so a straight line is, indeed, straight, for example.

 

I tried difference acceleration rates, and longer and shorter segments. Nothing had much effect. All of the segments are about the same length, and it's the slower moves that exhibit the problem.

 

A low acceleration rate shouldn't disproportionately affect a low-speed move because it comes to full speed much earlier in the move.



Minimum pulse rate is quite low, assuming ~20 steps/mm or so, that's just a few steps a minute.

However, I'm slightly confused about the table. 0.4 degrees is about 0.2 steps. So what exactly is the mechanical setup of the gimbal? It's hard to diagnose pure numbers.

 

There's a 10:1 reduction on the pitch (Y) axis, and 8:1 on the yaw (X). With 16x microstepping, that gives a steps per degree (mm) of 71.111 X and 88.889 Y

 

Hello! I recently got a mini CNC mill, and iv'e been trying to use grbl as the controlling software. I have the newest version of it, and i have an older version of it that works with my machine, while the newer version gives me a lot of trouble for it. Trying to use the older software, and the newer along with the UGS (Night time and regular) i get an issue where my z seems to be inverted. Iv'e tried looking onto the wiki on multiple pages, and have tried to go through all of the trouble shooting errors to try and flip it back to normal.

In more detail. When I go to load a file into the machine, it starts the file fine, but once it gets to cutting, when it NEEDS to cut, the Z raises instead of lowering into the material a little, and when it doesn't need to be cutting, that's when the spindle dips down and actually starts cutting.

If you could get back to me asap that would be much appreciated.
Thanks, - Jeremy.

 

You need to invert the z axis direction via $3 in grbl. It will be the 3rd bit (if $3 is 0, you need to make it 4, if it is 4 you need to make it 0)

Look at gnea/grbl for more info. You should probably spend some time reading it cover to cover as it will answer a lot of questions you don't even have yet.

 

Hi. I am not really sure how to start a new thread on this forum. but my question is concerning the openbuilds post processor that I select when saving my tool paths. If I select the mm one it seems to work. If I select the "inches" one all I see in the openbuilds control software is a big X and Y and nothing happens. I am not sure what I am missing. Can you help? Thanks

 

I am using vcarve. The metric one runs the job and the inch one stays at the x=0 and y=0 and does nothing. Is there any issue with creating it with inches and saving the tool path as metric?

 

Thanks for your help.

 

Use the grbl (mm) (*.g-code) post processor in Vectric. You can still design in inches - it should correctly convert units and put the right code in the header to tell grbl that the code is metric. The grbl (inch) (*.g-code) should also work - what controller and control software are you using?
Alex.

 

Thanks Alex. The controller and software is the blackbox and the free control software from OpenBiulds.

 

You're welcome, as @Peter Van Der Walt said, post your V-carve file, g-code files in mm and inches so we can see what's going on. Also please confirm that you are using the Grbl (mm or inch)(*.g-code) post processors.
Alex.

 

Actually there is a problem with the Openbuilds grbl post processors in Vectric - they don't include G20 or G21 in the header. The generic grbl (mm)(*.gcode) and grbl (inch)(*.gcode) do.


Alex.