Hello All, I'll try to explain what I'm wanting to do, and what I'll be using. In the past I have built my own 3D Printer's and used RAMPS/RAMBO boards to upload and tweak Marlin software using the Arduino IDE. I want to drive a laser to cut from point-A to point-B. over and over again from same point-A to same point-B. The steps, as I see it are: Laser is “home” @ X0 Y0 Get signal from micro-switch - move laser from home (XY) to Point-A (XY) Set stepper motor speed - turn ON laser Move laser to point-b (XY) @ stepper motor speed - turn OFF laser Return laser to home (XY) and wait for signal from micro-switch. I plan on using an EleksMaker Mana SE V3.2 2-axis Stepper Motor Controller Driver Board and the GRBL software on an Arduino. So, I guess my question is; can I somehow add code to the Arduino (that already contains the GRBL software) to do this simple exercise? Can I maybe add a tab in the grblUpload.ino to include my code? TIA, Muggs
If you are referring to gnea/grbl, you will pretty quickly run into the code space limitations. The ArduinoMega has a bit more space. For a more structured approach, take a look at grblHAL running on one of the ARM chips. It is designed to allow adding code via a plug-in model. I have a Teensy 4.1 based grblHAL breakout board that has a lot of free space but there are others as well.
If that's all it has to do, i wouldn't bother with Grbl? Code it in Arduino itself: - read buttons and limits - run motor OpenBuilds/ArduinoStepperDriver - analogWrite PWM to pin for laser
Yeah. No point in making it CNC if it's doing a repetitive task. It's really not hard to program stepper motion in Arduino, with or without stepper libraries.
I have an openbuilds leed machine with which I'm trying to get lightburn to work. Flashing my Uno with Openbuilds Control has me moving but I need to exert more control over the grbl settings. Specifically, I'd like to experiment with changing some of the defaults in grbl's config.h. This requires me to compile grbl and I'll be flashing my Uno with the arduino application. Is there is a place I could view the finer grbl settings Openbuild Control is using? Specifically I'd like to see grbl's the precompiled config.h and defaults.h which Control uses for flashing the Uno. Is there a web address or GitHub address where a copy of these files reside?
We use stock-standard Grbl from github.com/gnea/grbl - with just ONE change, we set $4=1 by default as BlackBox's drivers needs an inverted Enable signal.
I have all the electronics installed in an old computer housing. The wire for the limit switches are connected to the Arduino and to plugs in the housing. The wires are maybe 30cm or so, maybe less. I get the switch triggered warning even though the switches are not connected to the housing. It's just the EMI from the wires in the housing. I had the same wiring previously connected to Mach3 and I never got an error, even when the switches were connected, and they have really long wire leading to them. The Arduino is very sensitive to the EMI I guess. Is there a filter, or something, that can be installed in the housing? I didn't even try yet to connect the probe or the spindle to the Arduino. I shudder to think what will happen once I do.
What's the EMI coming from? A PC case should be more or less a solid steel box, almost entirely shielding everything inside. Normally the ground comes through the ATX PSU case as a metal-to-metal contact. Maybe you need to re-add the ground if your PSU isn't directly connected to the case. 0.1uF ceramic disc caps between SIG and GND wires on all signal wiring (limits, interfaces, etc) should be SOP too. The most convenient place to install them is at existing terminal blocks, or on GX receptacle solder cups: (Green wires are XYZ limit SIG, 22ga black is logic GND (18ga black is 12V power COM). Y cap has 1/16" heatshrink sheaths to avoid signal shorts and noise shunts, but unlikely to actually practically make much of a difference) Those three little caps killed all my EMI woes. Six months of frustration, gone overnight. If problems are more severe than that, re-enclosing the Arduino with a 24V optical buffer shield would be a good plan. Far as I'm able to tell, you can hook 24V signalling up with a bare coat hanger and it'll be just fine. I guess that's why they use it in industry.
There are a number of things you can do. use NC limit switches (different wiring, invert limit inputs) use Low Pass Filters and/or optoisolators. use shielded wiring You would be better served using a BOB that has these things in place. The black box can support that sort of thing. If you have external drivers you can use a decent CNC shield that has filtering/isolators or try my Breakout Board for grblHAL.
Thanks, Rob, I'll try that now. I'll have to find which pin is the logic GND on the Arduino but I guess that should be not much of a problem
I was going to use a Teensy 4.1 once I got my problems solved but it says on tindle that the board is not available.
See https://user-images.githubusercontent.com/1461231/34397640-bbb8628c-eb45-11e7-91ca-f53a38e70566.png
Thanks, Peter. I ended up doing what Rob suggested and it worked a treat. Now everything works just the way it should. I may try, at a later day, make the filter with the resistors, just for just in case, unless at some not so distance point Phil will have his boards available and I will switch to the Teensy 4.1 and grblHAL.
I have found that the most bulletproof solution is using an optocoupler on each limit input line. A 2K resistor on the transistor side, and a couple hundred ohms on the diode side (for 5V) works like a charm. No noise is ever going to get through an optocoupler. The Arduino, and especially the Nano, are extremely sensitive to noise on the inputs. The internal pullups on the Mega328 are something like 50k-100k ohms, and it's very easy to induce enough voltage on this high value resistor to get false triggering. I used to have an IR motion sensor light in my shop, and everytime the motion sensor went off my machine would die. There are several opto boards out there made specifically for Arduinos/GRBL limit inputs. The cap trick works ok as well, if this is not enough, add a 2K pullup to +5V as well on each input. MG
Not too sure how to start a new thread on this but Im having an error 22 while jogging, after changing GRBL settings, now the machine wont jog without displaying that error, everything else work, it will still cut a G-code file no issue, just have to man handle the table into position
Error 22 (please include descriptions or screenshots of error messages (; lol, had to go look it up) is "Feed rate has not yet been set or is undefined." So check that you didn't backspace out the feedrate value in below the Jog buttons?
I'm using GRBL in a custom machine in a rather simple scenario. The only functionality I need is the ability to control 3 stepper motors with a limit switch each. It is working fine, but I am wondering if there are any simple ways to make a smaller, lighter custom build that removes functionality related to stuff like spindles, coolant, a 4th axis, etc.? My brief hunt through the source code didn't spot any flags to remove unneeded parts of the code. (I can continue on with the full build, but I can't help but wonder about a lighter build that eliminates all the warnings about low memory on the Arduino)
The low memory warnings are definitely annoying. But the repo is well tested and mature. Personally, I'm trusting the developers that they know their hardware requirements.
the low memory warning simply does not matter, GRBL is stable and mature and will work fine, but I can guarrantee that it will go horribly wrong if you mess with it (-: Having things (that work perfectly) in the code that you are not using is much better than having bugs lurking, lying in wait for the most inconvenient day to raise their heads.
that is a different can of worms entirely. grblHAL will run on the Teensy, among other 32bit platforms, but the user is then all on his own regarding setting it up and maintaining it, whereas OpenBuildsCONTROL + Blackbox is much simpler and well organized, with low risk of failure.
Stock GRBL does not compile for the Teensy, only the Atmega 328 on the Uno, and there is a version for the Mega256, both 8 bit processors with very similar architecture. The Teensy requires a lot of rewrite of hardware level stuff that precludes using the usual GRBL code on that processor. Which is what gave rise to the GRBL/HAL project. terjeio/grblHAL
A video for being able to restart or Pick Up from the approximate last point in the G-Code where the machine was stopped in process, would be extremely beneficial. Also pointing out how to determine by the code, which direction the machine is going to move when restarted, so that a crash does not occur, would also be greatly helpful. Thank You in advance. Mike
That's more like a video series - how to read and understand gcode. It'll come to you eventually, but resuming is not for beginners, just too hard. More importantly (and easier) is to resolve the reliability issues - one shouldn't need to recover in the first place. Avoid the job stopping: - reliable workholding - proper CAM - reliable machine - backup power to safely pause / UPS - break work into strategic sections to fit into shorter runs with planned stoppages - maintenance: check router brushes, machine, endmills, etc before starting a job