Hi Jog works ok after changing the wiring of Z and Y (which worked ok 2 days earlier ) I still have the problem of over size cutting, I have re checked the settings on the gble and no offset on G54,also the settings in sketchUp ,I have drawn a 50mm circle and it came out 60mm .gcode attached. Thanks
There is no way that the direction of an axis can just reverse all by itself. You need to find the cause of the problem instead of just bandaiding it by reversing the motor connections. Check to see if your EEPROM is corrupted by comparing the initial settings with the current ones. If $3 has changed from it's original setting, likely this is the reason your axis directions have changed. The circle in the g-code is exactly 50mm diameter. So, the problem is likely in your calibration. You should have approximately 200.000 in each of $100, $101, and $102. If not, change them. At some point, you need to do an actual measured calibration of machine movement and set $100-$102 accordingly. If any values are different than the ones you loaded in, change them back, and reset the Arduino before proceeding. I have seen a couple of instances of EEPROM corruption in GRBL, unknown what cause them. In one instance, all the Steps/mm settings reverted to their defaults (250), but nothing else changed. In the other instance, the entire EEPROM was filled with garbage numbers. No idea what caused either of these. MG
My GUI reads workspace settings. Presently I retrieve these by issuing a $# command and parsing / scraping the values I want from the response string. I suppose I could activate the Worskpace Setting, e.g. G59, and then get a status response showing the MPos / WPos mapping, and then "revert" to the previous workspace, but that sounds quite round-about too. Is there a more direct way of asking "give me the current WCS6 offsets?" (e.g. G10 writes values for coordinate offsets. What is the easiest way to read those values back?) Thanks Peter
It doesn't look like there is. If you look at the Wiki, it says that the best way to talk to grbl is to send it text strings and wait for an OK or ERROR message.
you need to use the spindle PWM pin and laser mode to achieve what you want. this is because in laser mode GRBL avoids stopping motion when the 'spindle speed' is changed. other commands like M8 and M9 always cause a motion pause for safety. You need to read all about it at gnea/grbl Knowledge is power!
No, its not familiar. My own sender and GUI. My machine is built on an aluminium frame. It is just very convenient when I mount a new workpiece to measure the X and Y distance where I want the origin to be from the frame struts. So at a glance on a tape measure or a little automatic beacon I place at the origin I can see XY=(190,230), say, from the side struts. (I don't yet have a beacon just to put at the origin on the table, but it is in my head.) So I have a little GUI feature that lets me goto an XY position relative to the side struts. I have the origin of the side struts presently stored in WS6. (The origin of the struts just happen to be outside soft and hard limits, so it needs a bit of care.) So to do this I need to pull the WS6 workspace offsets from memory, add on my measured XY, and jog to that absolute position. Then I can do little small-motion refinement jogs with a keyboard or joystick if I need to. Long-range jogs are nice and smooth, and they move at fast G0 speeds (so its not a typical start-stop jog each small step), and yet the long-range jogs can still be cancelled, unlike a G0.
Hi. are you cutting inside or outside your 50mm circle? Have you calibrated your machine HOWTO Calibrate your CNC Machine for MACH3 or GRBL BTW you have some incorrect settings in SketchUcam. Please turn off 'use end position' and 'use home height' until you have read and understand this: SketchUcam: HOWTO set default options and this SketchUcam: HOWTO set default options home height must always be less than max_z and even then can cause a crash when you use thick material.
Dear community, I'm building a small cnc project, which will run always the same Gcode (2500lines) and what I'm trying to is to leave it work independently, meaning that I dont want the Arduino to be connected to a computer. My question would be if it is possible to "insert" the gcode inside the arduino, and make GRBL run it when something activates (for example, a pushbutton, or a timer output) would be very similar to a factory production line, based on repeating the same moves all over the time. Would appreciate any kind of help! Thanks in advance!
the GRBL processor does not have enough memory for this. the minimum you will need is a Raspberry Pi that can send the Gcode to GRBL. automatiing the RPi to send the code at set intervals is easy (-: you just need a shell script to do the sending and a crontab entry to activate the shell script.
David is correct, in principle: you need some attached computer, even if this is not your laptop. For $8 you can get yourself an ESP32 dev kit, more "minimum" than a Raspberry Pi. You can host a file system in the 4MB flash memory, and let it stream the gcode to the arduino. The ESP32 also has wifi and bluetooth, so in principle you can maintain the files, initialte and control the job etc.over the air.
Brilliant! Will try to got that way! We are trying to get the smallest thing possible, so will investigate the ESP32, since I already have the arduino and everything, if that doesn't work properly, will change to RasPi! Thanks a lot!
ESP32 are 3.3V devices, Arduinos with a CNC shield is probably 5v. Technically you're supposed to use one of those little logic level shifters to interface the 5v to 3.3v. I've never bothered and just tie the pins to one another, but then I don't win gold medals for good engineering design either. Bangood, less than $5 for 10 of them.
Great! Actually, I'm using MP6500 to run the nema-8 steppers, and the "generic CNC shields" being sold nowadays are not compatible, so I might design a new one (Current regulation is on I1 and I2 inputs of the driver), knowing that the ESP32 needs 3v3 supply, might design a "generic" PCB to include the microprocessor, 3 MP6500 and the Logic Level Shifters! So glad I posted this message on this forum, thanks a lot for your help!!
Might be a long shot, and this isn't so much grbl specifically as an Arduino problem, but since said Arduino is running grbl, I thought I'd post here. So my z axis motor only turns in one direction. After some prodding and poking, the answer was the obvious: pin 7 (Z DIR) is stuck low. I have some replacement stepper drivers on the way just in case- apparently bad drivers can make for bad Arduinos, which can get expensive in a hurry, and my only spare Arduino right now is a legit "Genuino" Uno destined for the mill conversion. I also tried moving the drivers around on the shield, and the spotty behaviour (moving only in one direction regardless of positive/negative values in g-code) followed that particular driver, but also stayed on the z axis. One would think, that if the driver was blowing the main board pins, that it would permanently damage the other DIR output pins, but no- putting the drivers back how they were fixed the problem and I'm back to having a useable x-y stage (which is technically all I need for the time being, of course, being a laser). This behaviour seems illogical and irreproducible, so I'm not sure what to make of it. However, this is where my question comes in. On my current setup, pin 7 IS switching. It's just that it's switching is between 13mV and... 25mV. Blown internal resistor? Something else? What could possibly explain the odd behaviour seen on the other arrangements? Anyone else come across this? @Metalguru, @Sonny Jeon, someone? I'm guessing the answer is "replace the potentially bad driver and the Arduino, and use it for something that doesn't require a pin 7", but just in case... Meanwhile, I'm going to try reflashing grbl 1.1 (maybe via compile instead of hex this time) and see if that changes anything. Maybe the pin got stuck, for some reason, apparently that happens occasionally.
13mV and 25mv are still logic zero. What kind of hardware setup is it? Arduino with a shield? Separate drivers that connect through wires? Optocoupled? Something seems to be pulling pin 7 to GND. Did you try unplugging everything from the Arduino and then checking if the pin switches between 0-5V? If you have a multimeter, set it to resistance measurement mode and measure between pin 7 and GND. If the value is very low then something is blown inside the chip causing it to short. Also look for any physical shorts on the board.
Hi Rob: It's potentially a blown output pin on your Arduino. Though it is pretty unlikely that the pin was blown by the stepper driver. Most stepper drivers just have the LED of an optocoupler along with a resistor in series, it has no connection to anything else in the circuit. This isolates your Arduino from the power and ground of the stepper motors. May have been a wiring error or static zap that took it out. If you are using any standard Arduino, you didn't say whether it was an Uno or a Nano, they are really cheap to buy and you can likely get one on Amazon for under $10 and in a couple of days. You can usually buy them locally at any 3D printer shop or electronics supply store, like Frys' . That would be my first suggestion, replace the Arduino, reload GRBL on it, and test it without connecting it to the driver to make sure it flaps the Z direction pin properly. You could test the driver by just connecting the Dir input to either 5V or ground from the Arduino, and see if it reverses direction properly. As you say, try reloading the GRBL software, I have had a couple of the Chinese clone Arduinos act funny, although nothing specific to the output pins. More with EEPROM not programming or randomly changing. Speaking of EEPROM, I had a machine the other day that would only work on one axis, not the other two. Drove me nuts for a while, until I realized that the acceleration values for the two axes that weren't working were set to 0. Whether I just forgot to set them or the EEPROM got stupid, I don't know, but as soon as I set the acceleration values to a nonzero value everything started working. Good Luck! MG
Well right, that was my point. Arduino with a shield- one of the cheap $15-25 4x a4988 StepStick shields. Hmm, I like these ideas! Let's see... Pulled the shield off the board. Looks like you were right, something was pulling it to ground, but not sufficiently to be causing the issue; 91mV in one direction, 193mV in the other. Resistances are all over the place. Disconnected from USB, it shows about 280 ohms. Pins 6-3 show between 9.3 and 11.6M, so I'm guessing the resistor is, indeed, kaput. Which means that this... Is definitely the order of the day. I have another mini project- not secret, I'll probably post it as a build here just for fun soon- using a 1602 LCD shield that I can just change the pinout on before compile, so I'll try ripping that Arduino out of that project and see what it does. Fingers crossed! Appreciate the quick responses!
The solution: both a bad board and a bad driver. The only thing that explained the weird behaviour, but seemed like too far a reach to be likely. New board, new flash (compile rather than hex, though it shouldn't matter), good pin resistance readings, still doesn't work on z. Swapped the x and z drivers, now z works perfectly, x exhibits the single-direction behaviour. So the new drivers will give me my z axis back. For now, I'll continue getting things wired up! EDIT: Apparently I did something good recently, because I just remembered I saw a random (Pololu Black Edition) a4988 board in a box somewhere in the shop the other day whilst looking for something else. I burned out several in a row a few years ago, so there was a good chance it was one of those. However, not only did I manage to find it again (I'm gonna pretend due to my organization skills) but I brought it up to the office (where the bench supply and oscilloscope and PC running bCNC are for the time being) and it was the single board that I didn't kill several years ago. So now I have a fully functional battle station 3-axis machine by sheer luck of the right parts lying around!
Is this a CNC machine or something else? I ask because an A4988 driver is not a real good choice for a NEMA23 driver for a CNC... MG
By the way, you didn't mention initially that it was an A4988 driver. These are not optoisolated from the Arduino. Yet another reason not to use these, there is no isolation between the computer/arduino and the stepper power supply. This can couple a lot of noise back into the computer/arduino causing some hard to diagnose problems. I assumed it was an isolated driver like a DQ542 or similar. You know what assuming does... MG
Appreciate the handy troubleshooting points! Ah, yeah, I was wondering, because I'd never heard of them being optoisolated before. Not to worry, it was my lack of clarity (presumably for the sake of speed, but pure forgetfulness isn't off the table) that was to blame. I have been very careful about cutting motor power before making changes this time, however, and it seems to have paid off thus far. This is on the 3-axis diode laser etcher build (Portable Diode Laser Cutter) so no worries, all NEMA 17s. The a4988s are because it was started in 2016 as a cost-conscious project, but has since become something more. I have a DIV268N/TB6600 driver on the other project, I like it a lot, and considering how inexpensive they are these days there's a very good chance I'll replace them- as you say, lack of signal and power isolation is less than ideal, and since the build needs a separate electronics enclosure anyway, I really don't lose anything, it just gets made a little larger. You're not kidding about the noise, though- this is what was coming back through pin 7 from the bad driver (and you could hear it when powered up, too): That'll be a yikes from me. Appreciate all the input!
For NEMA17's, I like the Panucatt Gradus M1 Pro board. You can use A4988's on it, but they also offer a bunch of more modern driver modules, including the 5984, 6128, 2224, and 8825. Some are capable of 128th microstepping... They also offer the larger Bigfoot drivers in a couple of styles which will supply up to 3 A and have more pins with an SPI interface for setting current remotely. It still has the capability of running GRBL, and it has an isolated USB port to prevent ground loops and interference. Under $70. IMHO WAY better than the xPRO at half the price. MG
Interesting. I don't know if I have future NEMA 17 projects coming up, but I'll bear it in mind- it's definitely worth the price once you account for fried Arduinos (fried pin 11 on the new Arduino yesterday, I'm now onto the final genuine one... Forgot that I had a power MOSFET and not a logic-level one ) and driver breakouts. Seems nice and compact, and I do like the look of those DRV8825 boards. Thanks for the tip!
I like the 6128 drivers. They are much newer design than the 8825's ir the 4988's.. Those dessigns are getting a bit long in the tooth. The bigfoot drivers will handle most NEMA 23 motors, they just need fan cooling... MG
Toshiba has a new driver out that will handle 4A in a step stick standard format. The new SuperGerbil board will be shipping with those.
