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.
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.
gnea/grbl I am also now slightly unsure (not near a machine to check) but I think after pull-off move it is at zero+pulloff distance (or at least axismax-pulloff) - and zero is where the switch trips. David agrees Refer to Fusion 360: grbl post processor install (the easy way)
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.
I think I see a misunderstanding here: GRBL is the firmware that runs on the microcontroller in the controller, like the BlackBox, xPro or bare Ardiuno Uno among others. UGS is the GUI software that runs on the PC so send the Gcode commands to GRBL. There are many alternatives to UGS, OpenBuildsCONTROL is the simplest, bCNC much more advanced, and there are a few others. A major advantage of OpenBuildsCONTROL is that it makes setup very easy, for example there is a tick box for reversing Z, rather than having to think through binary math (-: One thing to watch for though is that many of the older GUI's have not been updated to work correctly with the latest versions of GRBL, so choices are limited by that. There was a change in communications between GRBL v0.9 and GRBL v1.1 so GUI's have to handle that. CNC machines have standard directions for everything otherwise the software will never work properly (because assumptions are made on the basis of the standards). if you stand in front of the machine then when you jog an axis Z, the tool moves up for + movement X the tool moves right for + movement (means the mill table moves left) Y the tool moves away for + movement (the table moves forward) If you have homing switches then they should be at the positive ends of travel, especially Z, that is not negotiable, though you can home X and Y in the other direction, it will confuse you, but it can be done (-: If you don't have homing switches then just jog to the positive ends of travel and reset the controller (power cycle or button press, NOT a soft-reset) This will set the machine co-ordinates to 0,0,0 at the reset point, which provides a 'fake home'. With home (esp for Z) in a safe place, all the assumptions made by the Gcode generators provide safety and predictable motion. in this image the tool is at -X and +Y because +Y : the table is forward (tool moved to the back of the table which is table forward) -X and the table is all the way right which has moved the tool to the left which is -X remember +X and +Y and +Z directions refer to 'tool movement' and a moving table machine appears to be going backwards but is not.
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
From which CAM application? Apart from the preview (which sometimes dislikes inches) - does the job run?
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?
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.
Share the vcarve project, gcode file in mm, and gcode file in inches please, we'd need those to analyse the differences and also to recreate the issue if needed
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.
