This stepper driver works well for me, on this link its $16.50: TB6560 3A Single-Axis Controller Stepper Motor Driver Board: Amazon.com: Industrial & Scientific I like it because it has the inputs on one end and the motor and power on the other end, so you can keep your wiring separated. You can find similar ones based on the TB6560 chip, but be careful. Some of them are junk. The SainSmart ones for instance work, but the switch settings legend on the board is snafu. Took me a while to figure out how to get it to work properly... I've found them on Ebay also for as low as $8. PS - they get pretty hot at 3A, even with the heatsink. I would recommend a fan.
Thanks I was looking at those but wasn't sure which ones where junk. One thing that got me confused was how to connect it to the Cnc shield . Or what pins from the arduino would go to what pins on that driver . For some reason if I remember right they use different terms .
You would use those drivers instead of a CNC shield, not with it. Well, I guess you could use it with a CNC shield, I think they do have connectors for the various drivers on the top of the board. You'd have to look at the schematic of the CNC shield. I don't think you'll find any plug in drivers for the CNC shield that will handle 4A. The 8825 drivers only handle a bit over 2A, and that's with a heatsink and fan. I use my arduino with a screw terminal shield, and just wire the step, direction, enable, and 5v into the stepper driver for each axis, based on the arduino GRBL schematic: This is an UNO with screw terminal shield
I might go with a screw shield . I was using the Cnc shield to make wiring easyier since things are labeled .
I'm having a problem where grblPanel seems to be interpreting my XY plane measurements much larger than they are in the file. My feed rate is also capped at 1000mm/min. I figure there must be a setting I've been blind to. Also, could someone direct me to this 2 hour tutorial I was hearing about?
If your measurements are in metric, but grblPanel is operating in imperial, your actual motions will obviously be 25x larger than they should be. G-code simply records coordinates, the operator dictates units and origins.
G20/G21 operation isn't the same as $13 report inches feedback, so make sure both are set properly per-run. Other than that, I don't use grblPanel, so I can't troubleshoot it. I also don't know what the tutorial video is, I just used the grbl wiki for setup.
Sonny, I would like to design/build a small device that I could plug into the GRBL/Arduino that would allow me to just jog X, Y, and Z. Ideally this would use a small joystick and a switch/button or two as the user interface. The device would send only the most basic g-code commands to reset and set up GRBL, then send only the minimal X,Y, and Z commands. One problem I see is that GRBL will accept multiple commands, until it's planning (?) buffer is full. That complicates the user interface a little since it would be hard to know when to release the joystick, for example. So, my question is whether or not there is a config.h setting (BLOCK_BUFFER_SIZE ?) that would allow for single command transfers? Thanks, Gary
Oops. Never mind. I just re-read what I should have remembered reading months ago. "Dwell" is probably what I need to do. Sorry.
For some reason, for the last couple of weeks, when I put in $$, this is what I get instead of the entire settings list. Is there a setting to control this someplace that I might've set by accident? I seem to remember that this changed around v 0.9g or before, I'm running grbl 0.9j. >>> $$ $0=10 (step pulse, usec) $1=255 (step idle delay, msec) $2=0 (step port invert mask:00000000) $3=0 (dir port invert mask:00000000) $4=0 (step enable invert, bool) $5=0 (limit pins invert, bool) $6=0 (probe pin invert, bool) $10=3 (status report mask:00000011) $13=1 (report inches, bool) $20=0 (soft limits, bool) $21=0 (hard limits, bool) $22=0 (homing cycle, bool) $23=3 (homing dir invert mask:00000011) $26=250 (homing debounce, msec) ok Steve Fox
That's very strange. This looks like a problem with some kind of corruption in your Arduino. I would re-burn the Uno's boot loader onto your Arduino and refresh Grbl. If you have a Duemilanove or some other FTDI-based Arduino, I would still burn an Uno boot loader onto it. It'll free up 1.5KB of flash and will help prevent any overwriting issues into the boot loader space, as Grbl is very close to the 30.5KB limit in FTDI-based Arduinos. Your Arduino will still operate just as it would, but you'll need to tell the Arduino IDE that its an Uno from then on.
It's loaded into an Uno. I tried a brand new one and got the same thing. I'm compiling using Arduino 1.6.3. I also tried using Grbl 0.9i with the same results. When I compile, it says sketch uses 28,916 bytes (89%). The only changes I have made to the source were I add the default settings for my machine. I did this by cutting and pasting from another set of settings and changed the appropriate ones. Is there something else that could be causing it?
Don't cut and paste settings into Grbl. It'll corrupt the EEPROM. This issue is outlined in Grbl's FAQ page. It has to do with the AVR EEPROM requiring shutting off all interrupts, including the serial ports, during a write cycle. Try using the '$RST=*` command to wipe your EEPROM to bring it back to defaults and try again by writing each setting one at a time.
I didn't cut and paste into GRBL, I cut and pasted into the defaults.h and config.h files before I compiled. I tried using the default defaults.h file and the default config.h file with the same results. I also tried loading the 0.9g hex file into the Uno and got same results. I don't see how it could be the boot loader, but I'll try replacing that.
Try not altering the default.h and config.h files. You may have inadvertently altered something enough to cause this problem, like a value that is interpreted as a float when it's supposed to be an integer for example. I would just try flashing a straight download of the source code without any modifications. If it still shows this problem, it wasn't something you did when altering the code. In my experience, the re-burning the boot loader fixed weird problems that had nothing to do with it. Just trust me on this one.
I did just that. What I changed was adding this section in the defaults.h file and the corresponding instruction to enable it in the config.h file. I don't think any of this would impact the problem, but I put the original files back in and had the same problem. I'm trying to find the cables to program the bootloader through another Uno. My programmer is in another State. I did find a genaric Uno and it performs as the other two. #ifdef DEFAULTS_OXCNC // Grbl settings for OpenBuilds OX CNC Machine // OpenBuilds OX CNC Machine #define DEFAULT_X_STEPS_PER_MM 26.670 #define DEFAULT_Y_STEPS_PER_MM 26.670 #define DEFAULT_Z_STEPS_PER_MM 50 #define DEFAULT_X_MAX_RATE 500.0 // mm/min #define DEFAULT_Y_MAX_RATE 500.0 // mm/min #define DEFAULT_Z_MAX_RATE 500.0 // mm/min #define DEFAULT_X_ACCELERATION (10.0*60*60) // 10*60*60 mm/min^2 = 10 mm/sec^2 #define DEFAULT_Y_ACCELERATION (10.0*60*60) // 10*60*60 mm/min^2 = 10 mm/sec^2 #define DEFAULT_Z_ACCELERATION (10.0*60*60) // 10*60*60 mm/min^2 = 10 mm/sec^2 #define DEFAULT_X_MAX_TRAVEL 500.0 // mm #define DEFAULT_Y_MAX_TRAVEL 750.0 // mm #define DEFAULT_Z_MAX_TRAVEL 80.0 // mm #define DEFAULT_STEP_PULSE_MICROSECONDS 10 #define DEFAULT_STEPPING_INVERT_MASK 0 #define DEFAULT_DIRECTION_INVERT_MASK 0 #define DEFAULT_STEPPER_IDLE_LOCK_TIME 25 // msec (0-254, 255 keeps steppers enabled) #define DEFAULT_STATUS_REPORT_MASK ((BITFLAG_RT_STATUS_MACHINE_POSITION)|(BITFLAG_RT_STATUS_WORK_POSITION)) #define DEFAULT_JUNCTION_DEVIATION 0.02 // mm #define DEFAULT_ARC_TOLERANCE 0.002 // mm #define DEFAULT_REPORT_INCHES 0 // false #define DEFAULT_AUTO_START 1 // true #define DEFAULT_INVERT_ST_ENABLE 0 // false #define DEFAULT_INVERT_LIMIT_PINS 0 // false #define DEFAULT_SOFT_LIMIT_ENABLE 0 // false #define DEFAULT_HARD_LIMIT_ENABLE 0 // false #define DEFAULT_HOMING_ENABLE 0 // false #define DEFAULT_HOMING_DIR_MASK 0 // move positive dir #define DEFAULT_HOMING_FEED_RATE 25.0 // mm/min #define DEFAULT_HOMING_SEEK_RATE 500.0 // mm/min #define DEFAULT_HOMING_DEBOUNCE_DELAY 250 // msec (0-65k) #define DEFAULT_HOMING_PULLOFF 1.0 // mm #endif
Did you try resetting the EEPROM with '$RST=*'? If that didn't work, try wiping the EEPROM with the Arduino EEPROM clear example.
I tried resetting the EEPROM with $RST=*and wiped the EEPROM with the CLEAR example. I tried completely removing Arduino IDE 1.6.3 from my laptop, downloaded Arduino IDE 1.6.9 and installed that. I deleted GRBL from my laptop and downloaded a new copy of 0.9j. I have the latest nightly build of UGS. I had a problem with the current stable build, but it has been a while and I don't remember what the problem was. I have tried the hex version of GRBL 0.9g, as well as 0.9i and 0.9j. In every case, I still get the same thing. I wasn't able to reburn the bootloader. Not sure why, it says it can't communicate with the programmer when in "Arduino as ISP" mode even though I can communicate with the same Uno when it isn't in "Arduino as ISP" mode. It will be a couple of weeks before I can get to my programmer. I have tried three different Unos, two have never had GRBL loaded onto them before this occurred. I'm stumped, I don't know what else to try. Steve Fox
What happens if you connect to something other than UGS? Like the Arduino's serial terminal at 115200 baud? You should be able to get a '$$' settings print out there in its raw form. FWIW, I downloaded Grbl v0.9j as well, set both GENERIC and OXCNC as the defaults, and everything works fine on my Arduino Nano (boot loaded as an Uno).
I tried it on the Arduino serial terminal and it works. How can that be? Got to be a bug someplace. I thought it would only mirror the characters to the Uno. I tried $$$ and it gave me an error. I thought maybe it was cutting one off. I'll go back to earlier versions and try to figure out when it happened. Thanks for your help. Steve Fox
Looks like UGS v1.0.9 works, but the current version and the nightly builds don't. The UGS Platform has the same issue. Two steps forward, one step back.
I am very new to this GRBL. I installed the gbrl 0.9j on my arduino board : all the motors are working properly and their limits work well if I do jog the X or the Y axes. I am using Normally open switches . There is a thing that does not work: I do get the "homing Fail " when I do start the homing sequence typing " $H " I am not really able to get rid of this problem: I am asking if could have some help please . Thanks in advance Regards
Make sure you have wired your limit switches to the correct pins. X->pin 9, Y->pin 10, and Z->pin 12. Z has recently moved from pin 11 to pin 12 to access the hardware PWM output in pin 11 for variable spindle speed output.
Thanks : I think the switches are wired ok: Y_limit is D_9: X_lim is pin D_10 and Z_limit is pin D_12 on my diagram. PWM is working well. I get homing fail as soos as Z axe has finished his motion. Just to make things simple I would like to NOT USE the Z axe and use a simple laser beam: >> how to configure that please ? Thanks Regards
Homing fails if it either doesn't find the limit switch or doesn't clear it after it finishes. For the latter, make sure your homing pull-off setting is large enough to clear your limit switch. For altering the homing cycle, please see the config.h file. There are instructions there. You'll be able to remove the Z-axis from the homing cycle.
