Hi Richard , I'm a Newbie here too , but this sound like you are hitting one of the extents limits of the workspace. What have you got them set to ? Regards Dave
Hi Dave thanks, I am going through the settings I may have set my limits to short and stopping the plunge depth. the thing that stumps me is the' open door' error ,I don't have a door. And the cut is within my work piece limits Richard
Hi Richard I'm currently getting to grips with the settings too , especially as I've just swapped out my Arduino. Are you running on a Uno , or Mega ? Feel free to post your G-code ,and I'll run it though my setup . I agree the door error is confusing, though I find the errors a little confusing at times anyway. Regards Dave Safety Door seems to be disabled by default in config.h // #define ENABLE_SAFETY_DOOR_INPUT_PIN // Default disabled. Uncomment to enable.
I've just successfully run your G-gcode , "cutting air" and it seems to behave fine. ( once I'd changed all the Z4.0 to Z0.0 , as I've only got about 2" of Z travel at the moment . I have had hard-limits ($21=1) set today and I've been rewiring various things this has been giving me frequent hard limit errors I disabled this ($21=0) when I ran your G-code. Arduino / Uno /Mega is the Microcontroller hardware grbl is running on. Regards Dave
Hi Dave Thanks, I have changed the setting for Z and in openScam it is looking good. As it is late here I will try and run a cut, fingers crossed for a good result once again thanks Dave regards Richard
The first thing is this (Generated by SketchUcam V1.3a) please get the latest version and install it! SketchUcam Then I see in the Gcode Code: (RETRACT limiting Z to @min_z) This means you have not set the max_z and min_z correctly. Please watch this: (yes it applies to V1.4d too) and this
Ok , so I've implemented an interrupt based serial write and read and working on rx1/tx1 on the mega and have "tested" by writing messages to the serial port , and echoing anything that it receives . I'm still waiting for my VFD to arrive , and Its delayed . My intention is to send suitable commands to the VFD from the spindle_init spindle_stop and spindle sync commands, though I noticed the pwm is also set continually during moves from the spindle_set_speed which is called stepper ISR. Can anyone explain to me why this is ? for my case, I think this is unnecessary , but I would like to understand the intentions of the original author. On another point are there any test within grbl to verify the performance of the stepper routines , to check that I'm not slowing those down,and if so by how much ? Best Regards Dave
basics that ISR speed setting is for engraving with lasers. if you ware never using laser, you don't need it. details: engraving with a laser involves changing laser power during a chain of moves using only new S words and no M3/M5. In laser mode issuing a new Sxxx speed will not stop the movement, but it must update the 'spindle speed' = laserpower. In laser mode using M4 means that laser power is scaled according to the current acceleration rate, again requiring that speed PWM be updated for every step.
Hello, I like many of you have built a CNC machine in hopes of ultimate diy heaven. Unfortunately my build comes to an abrupt halt when my machine will not fulfill its function properly. The problem arises when I tell the machine to cut a 30 mil square and it cuts a 29.8 mil square. With that being said I have done at the very least probably 40 distance travel tests up to 400 mils and they are all spot on. Please help
That can be from several sources, but they usually come from mechanical backlash, belt stretch, or something loose like the set screws on the stepper motor gear. Make everything is nice and snug, especially those set screws, but not too tight. Belt stretch is cause by belt tension and gets worse linearly with belt length. Most users just alter the step/mm setting in Grbl to account for that.
Are you sure you know the exact size of your cutter? 0.2mm can easily be 0.1mm each side of the cutter. This can be either cutter diameter or runout in the spindle/collet system. Measure the cutter diameter with a micrometer and use that size when you generate the Gcode for best accuracy. Also, make sure you do the calibration correctly HOWTO Calibrate your CNC Machine for MACH3 or GRBL The final result will depend entirely on how accurately you can measure the travel you use for calibration. So make sure your ruler/measuring tape is a good one. Ultimately one has to realize that 0.1mm is a small thing and only really matters on jewelry (-: Industrial machines use ballscrews which are accurately made, AND the control software allows for a table of offsets to calibrate the ballcsrew! We must also keep in mind that stepper motors with microsteps are NOT accurate from step to step since load on the system will prevent it moving a precise step. Some motors are better than others, but in the end mechanical resolution + fewer microsteps is more accurate than more microsteps. If you really need sub 0.1mm precision, then you want Clearpath systems (-:
Well when I cut the square I was making sure not to have any flex in the machine( or as least as possible). I cut the square at a depth of .04 per pass at 40 mil feed rate and had a brand new enpoint 1/8 single flute up spiral bit. When I first cut the square it was worse so I checked everything and find the wheels to be too tight. The machine is double belted for extra strength and is mounted directly to a torsion box for bed accuracy. I plan on doing wood inlay work for a side job but I won't be able to if the best that the machine can handle is .2 mils off. I would like to mention that the square is actually square but is under sized in all directions. Could it be an off set from fusion 360 or an undersized smoothing operation. Update: I checked the size on the end mil. .117 or approximately 3mm at the cutter head. That only means the problem is worse than I thought.
If the error is a consistent throughout, then it's likely belt stretch. Belts are not infinitely stiff. You can check this by moving your machine in one direction, multiple times. All motions should be slightly off and scaled. Check with a dial indicator or some other accurate measurement device. If it is belt stretch, use the measurement values to figure out what the belt stretch scale is and apply it to the step/mm setting in Grbl. If the error comes up only when you change direction, then it is likely a backlash issue somewhere in your machine. If the error comes up only when cutting, something in your spindle setup is off. Runout, tool, etc.
Can you please reverberate run-out, tool, etc. I have a Makita trim router as my spindle and it is attached using the quick and dirty method but plan on making better mounts out of 1/2 in. hdpe. But I couldn't see any other possible problems other than possible cam inaccuracy as I am still learning the lingo as well as fusion 360 or machine inaccuracy ( belt stretch, flex, etc.)
.117" = 2.9718mm .125" = 1/8" = 3.175mm 3.175-2.9718 = 0.2032mm what does this mean? you told Fusion that the bit is 1/8" reality is that the bit is smaller, this means the part should come out too big by 0.4mm (0.2 each side). yet it comes out too small by 0.2mm, a difference of 0.6m to cut around a 30mm square a 1/8" bit has to travel 33.175mm we are coming out 0.6 short, thus travelling only 32.575 from C-Beam™ Machine - Plate Maker we get the formula newstep/mm = currentstep/mm * commanddist / actualdist ergo newstep/mm = currentstep/mm * 33.175 / 32.575 you will have to do this several times to get to a final steps/mm that works over the distances you need. It is critical to KNOW the cutter diameter, and critical that Fusion does not have any cutter compensation or other offset set. You should experiment with 'stock to leave' and a final size cut to remove that last little bit with minimal cutter load (and climb cut that final pass) NOTE: you will NEVER get any better than 1/stepspermm accuracy. That is the smallest step the machine can take, and as I pointed out before, microstepping under load will very seldom do an actual precise step anyway.
run-out : when the tool does not run straight in the collet, it cuts bigger than its own size. I suggest that you redo that router mount before you go chasing 0.2mm offsets (-: Fusion is complicated, you should watch NYC CNC 'fusion fridays' on Youtube.
Hi, I'm having a heck of a time. I've been mostly successful building a laser engraver (A simple XY laser engraver/cutter). I've set up GRBL 1.1f (after a lot of trial and error) and got things working. I can jog both axis, I can import and run g-code, I can even engrave stuff successfully. What I can't do is home the thing. I have my limit switches set to NO. I've tested each with a multi-meter. I set $5=1. If I jog or have gcode that hits one of the switches everything stops correctly (which didn't always happen). When I send $H I can hear the steppers power on (I have $1=25 and not 255 for no good reason). Every time I power it on, it starts in an alarm state (product of $22 ???). When I sent $H I get the following: $H < ALARM:9 ok Grbl 1.1f ['$' for help] [MSG:'$H'|'$X' to unlock] S6705 < error:9 $X < [MSG:Caution: Unlocked] ok S6705 < ok I am really new at this and it could be something simple I missed... I hope it is. If someone could suggest what else I can look into, I'd greatly appreciate it. Below are some of my settings (let me know if there is something relevant I didn't include). $5=1 $6=0 $10=3 $20=0 $21=1 $22=1 $23=0 $24=50.000 $25=635.000 $26=250 $27=5.000 Thank you so much for any help.
According to the Grbl wiki, alarm code 9 means homing couldn't find the limit switches within the search distance. Thats related to you max travel settings. Make sure those are somewhat close to your machine travel. They don't have to be exact unless you are using soft limits. Grbl automatically throws an alarm state upon power up if homing is enabled. This is a reminder to home because Grbl doesn't know here it is relative to the switches. Homing is only useful if the machine is always homed from a fixed reference point.
I'm only a Newbie, but this sounds like you need $5=0 , That's what I have on my 3 axis router and I'm sure my limit switches are normally open, I think if you have the limits inverted it will try and drive a little way to move away from the microswitch and then rehome slowly. if it cannot move away in a short distance then I'd imagine it would set an alarm Regards Dave
Thank you Sonny. I really appreciate you taking the time to respond to my question. I'll dig into this more, thanks for pointing me in a new direction. Right now, it's not moving at all before the error. By travel settings, is there a specific setting? I only see $24 and $25, but that looks like it is only the speed. I didn't change $130, $131, or $132 because the wiki said "this sets the maximum travel from end to end for each axis in mm. This is only useful if you have soft limits (and homing) enabled, as this is only used by Grbl's soft limit feature to check if you have exceeded your machine limits with a motion command." But I'll try that when I get home. Thanks again, time is valuable and I appreciate you sharing some of yours. d
Thanks Dave! Any help is good help! Unfortunately, that doesn't seem to be my problem. I think I have it correctly set for normally open switches. However, to be safe, I also tried it the other way... But thanks again.
Have you disabled the "Homing for the Z Axis" ? I'm pretty sure I couldn't get homing to work properly until I had all three axes connected ( I first connected up grbl when I'd only build the Z & X axes ) Regards Dave
Oh wow! I can't wait to get home, that makes so much sense it might actually work!!! It tries to home the z axis first! Thank you!!! Wow. I don't want to jinx myself, but I've been messing with this for a week!
I'm currently upgrading my spindle , so I can play I've disconnected the z axis and If I home , I get $H ALARM:9 $G ok Grbl 1.1e_dah26/2 ['$' for help] [MSG:'$H'|'$X' to unlock] If I edit config.h about line 105 from #define HOMING_CYCLE_0 (1<<Z_AXIS) // REQUIRED: First move Z to clear workspace. #define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS)) // OPTIONAL: Then move X,Y at the same time. to #define HOMING_CYCLE_0 ((1<<X_AXIS)|(1<<Y_AXIS)) effectively comment lines 105 and 106 , and uncomment line 110 that should work .It did for me . Regards Dave
