From Pauls kickstarter "Toshiba has released a new step stick TB67S109 which delivers an impressive 4 Amps which puts them in the top leader board in terms of performance and credibility.
MG, from this web page they are TB67S109 step sticks (4Amp). Here is Toshiba's info on the chip: TB67S109AFTG | Motor Drivers | Toshiba Electronic Devices & Storage Corporation | Americas – United States This looks promising for the CNC Shield users.
Hi, My cnc openbuilds workbee 1000mm x 1500mm, with board gShield v5b - systhetos + arduino uno (original) Y axis = 2 trapezoid screw Z-axis = trapezoid screw X-axis = gt2 belt 1-Question: (I used aspire8.5, followed by Universal Gcode Sender 1.0.9). And the key ($H (home) don't work, when I turned all axis at zero and move some axis next I send to the home ($H)point and it don't move, next I changed the $22=0 (homing cycle, bool) to 22=1 and alert a red message error, I ask, is possible the $H works correctly? 2-Question: If you can help me with this board (gShield v5b - systhetos + Arduino uno (original) it is possible, connect the 6 micro Limit switch kit with mounting plate, in this cnc with this board + arduino? Someone have a picture or some graphic to connect it, if in the board gShield or in arduino uno? Thank you for your help, from Portugal
One trick I used is that the Arduino can run everything without needing a CNC machine or driver chips or hardware: So you can just plug it into your computer and use the console interface of some GUI to query the status, issue move commands, etc. 3 switches are needed to find home, and they will cause a Hard Limit error if they are closed when your machine is not seeking the Home position. The other 3 switches are for hardware limit switches on the opposite side of each axis. So I suggest you start with just three switches, and turn off "Hard Limits" ($21). Also check $5 - it controls whether the limit switches are expected to be opened or closed when the machine hits the limit. For most setups I think the switch is normally open (not at the limit), and then it closes when the machine reaches the limit. So the Arduino will pull the limit pin high, and the wiring will be from the pin through the normally-open contacts of the switch, the other contact of the switch grounded. So when the switch closes the pin is pulled down to ground. You can try this on your desk away from your machine, get the homing logic working, etc. Also, remember that Home is at (0,0,0) (and the machine will pull-off to (-3,-3,-3) so that the homing switches open again. (You can set the pull-off distance $27). But all machine coordinates are in negative space. So after homing, G0 X 10 will probably give an error, G0 X -10 should work (and you can check the status frequently to see where the Arduino thinks the machine is).
Read this page: gnea/grbl $H is "perform homing cycle", not "go to working 0,0,0". Judging from your second question, you don't have homing switches installed, so it cannot physically run a homing cycle. That's probably what the error messsage is telling you (there's an error response decoding page here: gnea/grbl). Just use G90G00X0Y0Z0 (for working/G54 home) or G53 (to go to machine zero, might be better to use G28 if you actually have a workpiece in the machine, read up on that too). In terms of limit switches, grbl only takes in one input per axis on the Arduino board. How you wire the six switches depends on your switch type. If they're active low (ie. push-to-break), wire in series (so that the circuit gets broken no matter which switch is opened). If they're active high (push-to-make), wire in parallel, so that either switch being closed will independently complete the circuit. You'll also need to tell grbl which type it is, so that it sets the pin resistors appropriately. This is also on the wiki: gnea/grbl Basically, read all of the wiki in its entirety. Sonny and his community have done a great job with the documentation.
Thanks for the clarification. Which one do I need to choose? About the connecting normal open or closed end switches, model for my openbuilds cnc 100cm x 150cm ? N this moment I just have 3 switches, I need to bought more 3. Yesterday I make a simple exemple of work in MDF and I put the X axis near rhe end of the end (at 1300cm)of the Y axis and when I started the work, (have 2 nema 23 in Y)the right motor nema 23 make a noise and don' run like the left nema 23 at the same time and stoped at 2bcm + -, and the left nema don't move, can you help me please? Many thanks
I have a simple UNO + CNC shield to drive my motors. So I have wired my two motors for Y in series with each other. So when one steps, the other should also step. My arrangement of belts and pulleys means my motors must move in opposite directions (one clockwise, one counter-clockwise) to move the carriage in the same Y direction. You can reverse the direction of a single stepper motor by reversing just ONE pair of its wires to one of its coils. If your motor fails to move / just makes a noise, the two most common reasons I have found is a) not driving sufficient current to the motor (but adjust your driver current with care if they are adjustable, and watch that the driver chips do not get too hot). But the more common reason has been b) a poor connection on one of the two motor coils, typically from header pins on my CNC shield. On my cheap CNC shield I found a weak failure point was the header pins and jumper cables connectors. A driver chip like the A4988 or rhe DRV8825 can produce one or two amps, and any resistance in the connection overheats the puny header pins and melts the header pin plastic. So I've soldered heavier gauge wire directly to my header pins, rather than use breadboard jumpers.
Either one is fine; some people prefer normally closed because a system failure would be in the error position (ie. open, and stopping the machine) rather than an unknown fault and not activating when needed. This makes sense on a higher power or higher cost machine where crashes could be more catastrophic. Right now you could just use the three to get a home position, and then use soft limits instead of hard limits for the other end of the axes. grbl uses a look-ahead system so that any move that takes it beyond the soft limits won't execute (in fact, it may not even start the entire cycle, if I recall correctly). Originally I had a CNC shield with the A axis mirroring the Y axis. I kept frying Arduino pins because CNC shields aren't optocoupled. Then I got discrete TB6600 drivers, which worked much better, but my Y axis was spotty- sometimes it was fine, sometimes one side would drag or judder. Once I split the logic between two drivers, instead of splitting one driver between two motors, everything started working and smoothed out. The thing with steppers is, even if they're the same make and model, if they're slightly different coil resistances or operational impedances, one (thanks to Kirchoff's laws) will take significantly more of the drive current than the other. Increasing the current output may cover up the problem, but not always, and in some cases could lead to motor overheating. Best to use two separate drivers, where each individual driver can tune itself to each individual motor. Try plugging the second y axis motor into the x axis driver (instead of the x axis motor) and then executing something like G91G00X50Y50. If it operates your y axis smoothly, you need separate drivers (which is best practice anyway). If it's still not smooth, there's likely a connection fault (those stupid Dupont connectors are horrible for this stuff, I've just spent the last hour rewiring some myself). If you replace the plugs, or direct wire them in, and it's still not smooth, it could be your frame; the gantry may be racking due to loose wheels, your Y rails may not be perfectly parallel and square to the overall structure, etc.
I wired my two motors in series, so current must be the same in both. Even if the coil resistances are a bit different the driver chip PWM mechanism is a current-based control mechanism. So in my case with higher resistance in the circuit the driver chip will need to drive for a longer PWM period, and the driver chip might run a bit hotter. If you do use two separate driver chips you will set their current limits independently, so you could end up driving one motor a bit harder than the other, but that should not be a problem. Your two driver chips are sharing the load, and should stay cooler. I (and others) had trouble with DRV8825 chips at very low loads. The current sense mechanism is disabled for about the first 10% of the PWM cycle to allow the sensing voltage to settle, so the driver can never clip the current to less than 10% of its maximum. Here is one hack: Power Cabristor: DRV8825 missing microsteps
Good morning/evening everyone! I came to this forum some weeks ago to solve a problem, involving a "Self-Working" CNC machine, without the need of a directly wired computer to run the gcode, and the solution I was given was to use an ESP32 instead of arduino, since the Arduino can't handle GRBL + GCode inside. I investigated and found out that I can use ESP32 to hold the Gcode, and a small command to send it to the arduino so he can start milling. But the problem is that The project leader doesn't want an Arduino, so I have to fit the Gcode and GRBL both inside the ESP32. This is completely possible, since I saw a post where someone developed this and made a video of it (Grbl CNC Firmware on ESP32 at Buildlog.Net Blog) The problem is that I can only do one of the 2 parts, load GRBL into the ESP32, or prepare the script to send the GCODE inside to an external device. Has anyone done that or something similar? I would really appreciate some help! Thanks a lot!
just use 2 ESP boards. one for GRBL (which is best because you dont want to interfere in any way with the step pulse generation) and one to feed the gcode. remember that project leaders cannot always get what they want, the best technical solution is better than what they want (-: right now the best solution is an Arduino Uno running the latest GRBL code and some other processor feeding it the Gcode. be sure to read and obey the instructions in the wiki for feeding GRBL the gcode, if you don't follow the instructions the machine will fail, possibly expensively. grbl interface
Yeah, I like the idea of a completely self-contained device, but trying to put a realtime kernel and an offline I/O module into the same piece of hardware doesn't sound like the best idea to me. Would he prefer an ESP32 and a "custom ATMega328P-based board" as a solution? The "no Arduino" seems incredibly arbitrary- is he ideologically opposed to microcontrollers or something?
Hahaha! The "No Arduino" is because there are several "industrialization" problems with it, since it is not well seen and you can't get several certifications with it, at least here in Spain, unlike the Raspberry Pi, used in a lot of IoT devices to connect the electronics to the cloud. Basically, you both recommend 2 devices if I'm not wrong, one to hold and send the Gode when I activate my "external input" and the other to receive the Gcode, load it into GRBL and run the Nema-8 right? Will try to do that using a Raspberry running the GRBL, and the ESP32 holding the GCode, if that doesn't work, I'll go back to Arduino + ESP32 ;-) Thanks for the fastand helpful answers!! Appreciate it!
well, you can get industrialized versions Rugged Circuits AND let us not forget that Arduinos are made in Italy and so should be CE certified. Is that not enough? but what about the boards like the xPro that are made to be built into machines? maybe certifying one of those would be possible? or even build your own board. it is just a 328 chip and a 16Mhz crystal and a few resistors. um, no. There is a no GRBL build for Raspberry Pi. Only for Arduino Uno and Mega (and a few ports to other processors that may not be stable) what runs on a RPi is the GUI to feed Gcode to the Arduino. Like bCNC, UGS, CNC.js and others. what about this (you could build your own if needed) Raspberry Pi CNC Board / Hat (i would not use those drivers) which make the GRBL processor into an attachment on the RPi. once you have an RPi you don't need any other processor since the RPi can send the Gcode you need an many ways. even the simple_stream.py that comes with GRBL will do it, and that can be triggered by a cron job, or a button press, or a network event, etc.
HI, just joined the forum. Using GRBL 1.1, Arduino UNO, bCNC and UGS. Trying to control a GarvoGraph XV, this has an original controller board and NO home switches. Up until recently i had this working with LinuxCNC fine, and used it a fair amount. But the pc i had died and i was told this was the way forward, which made sense. But im having some issues, the home switches are left and bottom of the workplate, z axis is at the top. Head moves left to right and workplate moves from front to back. i have the unit moving manually if i override the homing function, jog right moves the head right and left makes it go left. Down moves the workplate back and up moves it forward. ( so it appears the head is moving relative to the workplate). So all dierctions are ok. I hit home and the z axis moves up as expected , but in small steps, it then hits the home switch and continues to try driving, fortunatly its on a slip drive so its not doing any damage. I then get an ALARM 8 or 9. The bar at the top on bCNC then goes red and shows [Z], which indicates the Z switch is made. if i try the other switches i get them appearing in the bar. Sometimes it then moves the X and Y axis after its hit the Z switch and i do another home, but these axis also do a small step and bring up an error if the switches are made. heres my config. $0=10 $1=25 $2=7 $3=7 $4=1 $5=0 $6=0 $10=1 $11=0.010 $12=0.002 $13=0 $20=0 $21=0 $22=1 $23=6 $24=100.000 $25=1000.000 $26=10 $27=5.00 $30=1000 $31=0 $32=0 $100=63.000 $101=63.000 $102=38.460 $110=1500.000 $111=1500.000 $112=500.000 $120=10.000 $121=10.000 $122=10.000 $130=360.000 $131=310.000 $132=200.000 I could do with some assitance or guidance on what im doing wrong please. Thanks Mark Happy New Tear
I haven't yet added my switches into my config, so I'm not sure how helpful I can be just yet in practical terms, so that notwithstanding... The first thing I see are the feed rates for homing, $24 and $25. These seem quite high to me unless you're using proximity switches- and even then, it depends on the inertial coupling of your drivetrains. What happens if you drop them to say, $24=50 and $25=200? That would be the first thing I'd attempt- just to make sure the switches work at all. I guess try $27=10 as well, while you're on, just in case it's not properly re-seeking home. The other possibility, given that they're active high/NO switches and therefore have no inherent error checking (ie. if the wiring is broken, there's no natural change in state as there would be for an NC/active low switch), is that your wiring inside is bad, or there's an intermittent connection fault, or something along those lines. Grbl isn't gonna catch this and alarm out in an NO system, and it could easily cause the intermittently variable errors you've been seeing. The pulsing... How heavily are you microstepping? Apparently some stuttering can happen at high levels due to the controller instruction throughput being overloaded on the Uno. If it's very heavy, bring it back to say, 4x or 8x (and adjust your steps/mm settings accordingly). Other than that, I'm not sure I can think of anything off the top of my head that would prevent smooth motion. Does it do the same thing if you issue a G00 command (within safe distance parameters) without homing first?
I know, This is a common Occurrence, but I Am Stumped. I've read all sorts of problems, but none seem to meet my criteria. My experience is limited but have played with a 3d printer/miller/Laser Engraver (Boxzy) for about the last year. It doesn't use GRBL. I am not an electronics wizard by any means, Most of my knowledge comes from countless hours of Youtube. I am trying to make 1 stepper motor turn using GRBL Mega Version. Once I get one moving, I plan on Adding more. EccentricWkshp/grbl-Mega-4axis I've Flashed it to my Arduino Mega and have a GRBLDuino Shield Attached to it. GRBLDuino Mega Shield-GRBL 1.1 Arduino CNC Shield by The Eccentric Workshop Store on Tindie I'm using Universal G Code sender to send a G Code to the Mega. Power Supply is 19.1V 190Watt max. So plenty of power. I've supplied the Arduino with 5 Volts as I've found out that the shield doesn't supply power to the Arduino. I'm using Pololu DRV8825 Stepper Drivers. I have followed the procedure from pololu on setting up the driver for max current. I have it set at 200ma which should be proper with the 0.4amp rating of the motor. The Motor is a small Bipoler Stepper motor. Nema 17. Rated for 0.4 amps per phase. It does say 12Volts on my Data Sheet. But from what I've read I can run 19 volts for short periods of time. I've got 19.1 volts when I test the driver across the motor power supply. (Vmot - GND) I've got 5 Volts when I test the driver across Gnd - Sleep & Gnd - RESET My jumper settings are set to 1/16 step according to my datasheet on the GRBLDuino Pololu - DRV8825 Stepper Motor Driver Carrier, High Current Universal G Code Settings Firmware = GRBL Port = COM3 Baud = 115200 I Click Connect and my console comes up with my GRBL Settings And is in a State of Alarm (UGC Console Output) ************* **** Connected to COM3 @ 115200 baud **** Grbl 1.1g ['$' for help] >>> $$ [MSG:'$H'|'$X' to unlock] $0 = 10 (Step pulse time, microseconds) $1 = 255 (Step idle delay, milliseconds) $2 = 0 (Step pulse invert, mask) $3 = 0 (Step direction invert, mask) $4 = 0 (Invert step enable pin, boolean) $5 = 0 (Invert limit pins, boolean) $6 = 0 (Invert probe pin, boolean) $10 = 1 (Status report options, mask) $11 = 0.020 (Junction deviation, millimeters) $12 = 0.002 (Arc tolerance, millimeters) $13 = 0 (Report in inches, boolean) $20 = 0 (Soft limits enable, boolean) $21 = 0 (Hard limits enable, boolean) $22 = 1 (Homing cycle enable, boolean) $23 = 0 (Homing direction invert, mask) $24 = 500.000 (Homing locate feed rate, mm/min) $25 = 2000.000 (Homing search seek rate, mm/min) $26 = 250 (Homing switch debounce delay, milliseconds) $27 = 5.000 (Homing switch pull-off distance, millimeters) $30 = 1000 (Maximum spindle speed, RPM) $31 = 0 (Minimum spindle speed, RPM) $32 = 0 (Laser-mode enable, boolean) $100 = 80.000 (X-axis travel resolution, step/mm) $101 = 80.000 (Y-axis travel resolution, step/mm) $102 = 4000.000 (Z-axis travel resolution, step/mm) $103 = 8.889 $104 = 8.889 $110 = 1200.000 (X-axis maximum rate, mm/min) $111 = 9000.000 (Y-axis maximum rate, mm/min) $112 = 300.000 (Z-axis maximum rate, mm/min) $113 = 1440.000 $114 = 1440.000 $120 = 300.000 (X-axis acceleration, mm/sec^2) $121 = 300.000 (Y-axis acceleration, mm/sec^2) $122 = 100.000 (Z-axis acceleration, mm/sec^2) $123 = 100.000 $124 = 100.000 $130 = 200.000 (X-axis maximum travel, millimeters) $131 = 200.000 (Y-axis maximum travel, millimeters) $132 = 200.000 (Z-axis maximum travel, millimeters) $133 = 360.000 $134 = 180.000 ok >>> $G [GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0] ok ********* I can then Send the Code "$X" to go to a state of idle Now is when my problems come into play Jogging the X movement will not do an **** thing to the motor. UGS will tell me that the x axis has moved and I can continue to play with it in all directions but nothing moves. After playing around a bit I have managed a few noteworthy things. Disconnecting and connecting has on occasion made the motor twitch once like it does on my 3d printer when I connect to the computer. So I know that there is power making it to the motor. I once had the motor very difficult to manually turn. But have not been able to recreate that and don't know what I did to get it or lose it. I have no limit switches wired in. I have tested the pairs of the motor to make sure that they match the data sheet provided. I have tested with multiple stepper drivers. For some reason my instinct tells me it's a software issue or GRBL Setting issue that I'm not aware of. I don't think its a wiring issue. (Although I could be wrong) it should be as simple as power the shield and Mega. Then the 4 wires to the motor.
no limit switches meand you do not need homing cycle active, so please set $22 to 0 then it will not turn on in an alarm state. I would : set $100 to 1 (1 step per mm, so every mm movement we command is one step) set $110 to 3200 (which is 200*16, steps per revolution) set $120 to 100 $130 to 20000 now I would issue a command like G0 X3200 and I would expect the motor to turn exactly one revolution, slowly. (should take a minute actually) G0 X0 will turn it backwards to where it started if the motors are easy to turn then I think it means that the enable line is not correctly set. check that.
I would not microstep to begin with: go back to full-step mode. Also. if you set $1 to 0, the current drive will not turn off after movement. (So keep an eye on driver chip and motor to intervene if anything gets too hot.) The motor should be hard to turn, against the holding power supplied by the driver. And the driver and motor should warm up a bit, but I would not go even near "hot to touch" if there is no load on the motor. Because you don't have homing switches, I think all valid table coordinates will be in negative space, so g0 X -16 should move 16 steps or 16mm away from home, and then stay powered in its new position. (Assuming you follow David's advice of 1mm per step). You have soft limits off, so it should also work to go "off the table" into positive space. Now measure current or voltage (easier) over each motor winding. In full-step mode both coils should be partially energized. Another 1mm to the left should switch polarity on one of the coils, then another step switches polarity on the other, ... After 4 steps your coil voltages or current should look the same as they did when you started. If your motor is rated for 400ma your 200ma current might be a) not what you think you set it at, or b) too low. Voltage doesn't really come into it at 19V. The driver chip will measure current and clip the time the current is allowed to flow. Also, Pololu changed the value of the sense resistors at some point in production (Pololu - A4988 Stepper Motor Driver Carrier) So you have to use a modified formula to set the VREF voltage for the correct current. My clone A4988 drivers have a sense resistor marked R100 (100 milli-ohms). There is an explanation on the Pololu site as to how to set VREF correctly once you know the value of your sense resistors, and know how much current you want But if you can feel or hear the motor vibrating or trying to move, and nothing is getting too hot, you may want to push up that trimpot and supply a bit more current. I don't suggest you leave the $1 setting at 0 once you are over your current hurdle.
alarm numbers are here 8 Grbl '$' command cannot be used unless Grbl is IDLE. Ensures smooth operation during a job. 9 G-code locked out during alarm or jog state neither of which make sense during a home cycle. puzzling make that 255, you do not want drivers going offline during a cut (assuming the hardware can do it) is that far enough to release the switch? I see nothing scary in there except that debounce setting. Unless you have very good hardware debounce this will probably need to be longer which then also might need slower feedrates so it can stop in time. Can you confirm that if you disable homing you can in fact run a cutting job? Remember that you don't really need homing. The only essential thing is to turn on with Z high. That prevents crashes. For ease of use you can also park X and Y at the same place before turn off. (industry standard is +X and +Y). Doing this means you can easily restart a job after a power failure or crash. In bCNC you can make this easy by setting a macro button to Code: G90 G17 G53 G0 Z0 G53 G0 X0 Y0 and just click that before you turn off. Then when you turn on (with the head in that same place) your G54 offsets will still be correct.
[QUOTE="if the motors are easy to turn then I think it means that the enable line is not correctly set. check that.[/QUOTE] This made me do some research on these Drivers. Pololu says that when the Enable pin is high motors are off, and vice versa for LOW. However when I Check these pins, I have just about 5 volts between enable and GND. After I send a G code thru UGS and check these pins, I still have just under 5 volts. If I were to take the shield off, and check between D13 (Spec Sheet says D13 is Driver Enable) and GND on the Arduino. Am I supposed to have 5 Volts out in Idle? Cause I don't..... I don't have 5 Volts either with running a Gcode.
I also tested a bit more on the Driver pins I’ve tried switching the setting $4 in GRBL to 1 and 0 Step and Dir are pulled low in Idle when set to 1 Step and Dir are pulled High in run when set to 1 Step and Dir are pulled low in Run when set to 0 Step and Dir are pulled High in Idle when set to 0 Enable pin is high no matter what setting I choose, in run and idle modes.
Confusing. Are you looking at the enable line a) from arduino output, b) at board input, or c) on the driver chip EN leg ? If you look at the Pololu driver site and pop out one of your drivers you'll see the EN or ENABLE signal is shown with a "negation" bar above it. So this means "active low". Stick your $4 setting in GRBL back to how it originally was. All your evidence is consistent: ENABLE never goes low, motors don't drive. My next suggestion is to disconnect the enable line between the Arduino and your board. And to set $1 to 0, otherwise you might only get a fleeting pulse on the enable. Then strap ENABLE low on the board (I would use a 330 ohm resistor to ground on the strap just in case it is being driven high somehow,) Now the motors should be hard to turn, driver chips and motors warming up, current flowing, etc. Put a LED through a 2.2K resistor to +5 on the ENABLE pin. Now when the pin is enabled (LOW) the LED should light and help you debug things. Does the Arduino (with the EN line disconnected) drive its output pin low when you initiate a move? If not, your problem is on the Arduino side. There are some ugly header files in the Arduino code that have pin mappings for different hardware. Are you sure the code is compiling for the correct Arduino board, and the pin that is being mapped for ENABLE in the ARDUINO software is indeed the hardware pin that your shield is connected to? Good luck Peter
Ok. So I can answer a few of these questions right now. I am testing the EN Line from the Driver pin Leg. But I have also disconnected the shield and tested D13 with my volt meter. In Idle, I have 0.578V. When I run a G0 X1000, UGS says that the X position is moving, But the Voltmeter continues to tell me 0.578V. Now I have also confirmed that the version of GRBL that I am using is the version that came with the shield. They gave me the link to download the GRBL Software. I also opened up the cpu_map file in the Arduino code and scrolled down to find this: // Define stepper driver enable/disable output pin. #define STEPPERS_DISABLE_DDR DDRB #define STEPPERS_DISABLE_PORT PORTB #define STEPPERS_DISABLE_BIT 7 // MEGA2560 Digital Pin 13 #define STEPPERS_DISABLE_MASK (1<<STEPPERS_DISABLE_BIT) I don't know much code yet, but this tells me that enable is supposed to be on D13. I didn't change anything in the file. I haven't done suggestion with the LED and resistor. I can work on doing that tonight. when you say (with the EN line disconnected) Are you referring to disconnecting the entire shield, or actually cutting the leg of the En pin on one of my driver boards. Thank You
I haven't tried the LED option yet, I think I need a bit more explanation with that one. I have the things I need to complete it but not quite sure how to go about it. What do you mean by "Then strap ENABLE low on the board" (Is the driver still attached with a cut-off Enable pin?) I have been looking at other options, Could it be that the driver I'm using is just the wrong driver? I noticed that the pololu drivers on their website are actually SLIGHTLY different. And I have emailed them also. They said the same thing that I need the enable to be low for the motor to drive. Attached are the drivers that I bought on amazon. They are Black and the differences that I can find, is the EN doesn't seem to have a line over top, and the VRef doesn't seem to exist. Now I bought 5 of these....They all operate the same when I switch them around. However. When doing some more testing. I found that I could hook up the Enable pin and the GND with my voltmeter, on the shield without the Driver in them. Then send the appropriate G code to "run" Them. Again, it stays at 5 volts no matter what I do. My gut instinct is telling me it's the Arduino not sending the right command to enable the motors to turn.... But then.... this is my first real project involving GRBL and Arduino So my gut instinct, might be way out to lunch.....
Hi. I recently purchased a grbl shield v4 for arduino nano but I encountered some problems. After I loaded the hex file wirh grbl v0.9 witx Xloader into the board, I noticed that the pins for the direction and steps are switched. I modified the cpu_map file for pins 2,3,4 with 5,6,7 and loaded the program into Arduino with Arduino IDE. Unfortunately, no software connects to the board, perhaps because it is not an genuine Arduino. So if the hex file from here (grbl/grbl) works but the pins specified above are reversed, can someone help me with a hex compiled grbl for the Arduino Nano 328p Old Bootloader with pins switched? Many thanks
Hi twiens99:: I don't think you should be cutting legs off anything . I imagined (wrongly) that you had wires and could unscrew just one. But it is possible to run grbl without a shield at all, and give commands, and UGS should still tell you that things are moving. There is actually no "feedback" data that flows from your shield to grbl, (other than some trigger signals from limit switches, etc.) The voltage should have been around 5v (HIGH) on the enable pin (before motion), then getting pulled down to 0 for motion. So if you repeat the experiment with the shield completely unplugged and you don't see it change from High to Low you have a problem. What is puzzling me is you see 0.5v (LOW) on the Arduino pin 13, but 5v(HIGH) on the socket in the shield. I'm guessing now, but I would expect that they should be a direct path between the two. Check out the other sockets on your shield too. With the shield unplugged, you should get continuity (close to 0 ohms) between all four EN pins in the sockets (grbl uses just a single enable line for all the axes). And I would expect continuity to the pin that will connect to pin 13 on the Arduino. (You might be able to see the track on the shield, if you are lucky). So whatever happens on Arduino Pin 13 should also happen on the driver chip enable leg. If you took my earlier advice and set $1 to 0, it may force the pin to stay low. So set it back to 255, and idle grbl should have line 13 HIGH, and you should see a low-going signal when you try to induce motion. If you're going to move enough steps that should be easy to see with your meter. If you're still stuck I would go back even one more step: abandon grbl for the moment, create a new sketch and see if you can manually drive line 13 HIGH then LOW, something like this ... void setup() { pinMode(13, OUTPUT); } void loop() { digitalWrite(13, HIGH); delay(1000); // 1 second digitalWrite(13, LOW); delay(400); } Now examine pin 13 with your meter. You should see the pulses, long high, short low. If that works, see if you can do the same using direct port "bit-banging" like grbl does. I don't have the exact syntax in my head, but something like PORTB = PORTB | 0x80 should do the same as digitalWrite(13, HIGH) and PORTB = PORTB & 0x7F should make pin 13 low. Peter
First, I have to tell you the Board Maker told me this in an email a couple days ago. Pretty sure this will influence the following tests. * The enable pin is connected to D13 and R1 is its pull-up resistor connected to 5v. I know these boards will move the steppers with the default GRBL settings so I would suggest reflashing GRBL to get a clean instance then trying again with the fixed board. When I’m testing, usually all I do is set $1=255 and $21=1. Once it moves, then configure the settings to match your machine. * That's what the Board Maker told me. Tried that a couple days ago. When testing Resistance between Enable pins, the resistor and D13 pin. I get what I would expect, Little to no resistance between enable pins, 10k ohm resistance resistor 10k ohm resistance between enable pins and D13. This goes for All enable pins, they are definitely connected. Nothing out of the ordinary. So what this tells me is the resistor is what is making the enable pin high. but what I don't understand, why won't Arduino set that pin low. I've tested D13 again to make sure that I didn't do something wrong last time. No matter what I do I can't get GRBL to set D13 Low. I've sent G Code, Jogged the controls in all directions, nothing. Still 0.5V. Isn't Arduino High supposed to be 5V and Low 0V? Why am I getting 0.5V? So I tried that code you wrote for enabling pin 13 high and then low. Worked Flawlessly. So my interpretation from this is GRBL is not doing it's job with D13.
