One other thing.... has there been any thought on making a version of grbl which would run on an ESP8266 so that control could be over wifi?
Hey Sonny thank you for teh response. /grbl/spindle_control.c in the edge branch line 145ff says: void spindle_run(uint8_t state, float rpm) { if (sys.state == STATE_CHECK_MODE) { return; } protocol_buffer_synchronize(); // Empty planner buffer to ensure spindle is set when programmed. spindle_set_state(state, rpm); } Is edge the true current dev-content or is it more like a testing release? Since i want to use it for commercial purpose i can spend quite a bit of time and hack it into the code myself to have it ready for use soon. I promise i will not spam you with pull reqs. Just a small advise if the plan is the probably the right approach to add the functionality would be really helpful. thanks.
The helical arcs will work fine, just like make sure you use either quarter arcs if using R format, or use IJK fromat if you want to use full circles. Seems to work better that way. If you want to see helical arcs in action on your machine you can use sketchup+sketchucam to generate helical bored holes, just use the 'depth first' option.
Hello all I have just finished building my Mill (300x600mm table, Ball screws, Grbl 0.9j, fixed gantry, moving table ) Homing working perfectly, manually entered G0 codes move as expected, in all dimensions (still trying to get used to the negative space paradigm in my head though!) then my co-builder wanted to see the machine draw (currently the spindle is a felt tip marker) a circle. I used the example GCODE from the grbl Wiki (below) Code: G17 G20 G90 G94 G54 G0 Z0.25 X-0.5 Y0. Z0.1 G01 Z0. F5. G02 X0. Y0.5 I0.5 J0. F2.5 X0.5 Y0. I0. J-0.5 X0. Y-0.5 I-0.5 J0. X-0.5 Y0. I0. J0.5 G01 Z0.1 F5. G00 X0. Y0. Z0.25 and the movement results in a very distorted "s" shape - and when i perform a ? it reports that it thinks it is back to where it started. it doesn't sound like steps are missing. the image is the result of a number of attempts. Any suggestions would be greatly appreciated.
It's an unreleased testing version, but it's pretty much done. No significant bugs have been reported from the select few people that have been running it. The only delay is finding the time to wrap things up. I mentioned earlier in the thread that we've had some family health issues and it's the main reason development has stalled for so long. Please be patient. Things seem to be finally getting back to normal.
After trying this several times, along with several reinstalls of the IDE and still finding GRBL visible at the bottom of the libraries list, I found that there's files of it stored in several places - even after you've uninstalled the IDE. I realise many of you will already know this but thought I might as well share it for other beginners like me who might have the same problem. Success with the mega2560 but also in the meantime I ordered an UNO, not surprisingly that one loaded up fine first time Thought I should probably start with the board that GRBL caters for the most. After looking at the pinouts/in, would I be right in thinking that if GRBL were to evolve much in the future it might need more pins, such as on the Mega?
Yes. I will be moving Grbl on from the UNO after v1.0, but it'll be a perfectly useful CNC controller as it will be. It'll be maintained but not actively developed. In the interim, I'll start developing for the Mega2560, just to add a few things like 4th axis and lathe (threading) support. However, most of my energy will be invested in continuing to develop a completely re-written ARM version of Grbl, rebuilt from the ground up. It'll be different and much better in a lot of ways that I will not expand on. Basically, it'll leap frog just about everything out there.
That's great news, it may affect which board I use. Quick backstory of where I'm up to... Originally intended to build a Shapeoko before moving on (if that was successful) to converting a bench mill and possibly a lathe. Then I looked at the Ox and decided the framework looked more rigid. In the meantime I came across an Emco Compact 5 CNC lathe in fantastic condition at a price I couldn't ignore. I bought the lathe and decided to convert to GRBL with a Raspberry Pi and 7" screen built into the machine's own console. Now, if lathe threading is planned to be eventually introduced to GRBL it might be worth me trying to work out the pins for the Mega. If it's years away I think I'd be better off just using the UNO.
Hi, In GRBL, with hard limits enabled, we have encountered an issue that the limits are triggered when the xPro is set to fast decay mode. This happens even if no limits are actually connected. This is probably a hardware issue, but i thought i would put it on here as well, in case anything can be done about it in the firmware. Also so others know about it if their machine keeps triggering for no reason Ryan
Yes. It's a hardware issue. The limit pins pins need to be electrically isolated/buffered to prevent issues like this. You can try adding a small capacitor from ground to each limit pin to help buffer this.
GRBL changed it's interfaces baudrate from 9600 (V0.8) to 115200 (V0.9 and up). Is there any more info on why this was done ? I am interfacing to GRBL with a 'good old' RS232 and have set it to 19200 baud. Are there any risks / drawbacks / known issues for not using 115200 baud When using RS232, would it be possible to use the parity check (given that also the sender, eg UGCS uses it). I am trying to make the interface between PC and CNC as reliable as possible.
I still think it would be useful to 'log' what caused the problem. Initially I got false triggers of limit switches, but by the time you can look at the machine status, limit-switches read 000 as if all switches are open ... (using UGCS with 500ms status updates) So when the error occurs, it should log enough info to know where to search. Just a 1-byte error-code returned could do the job
115200 baud and increasing the rate increase throughput and how fast the g-code streams. Depending on your g-code program and machine, your stream may not be fast enough to not starve Grbl's buffers, which can be a common occurrence with programs with complex curves with lots of tiny line segments (3D carving/laser cutters). If so, Grbl will stutter a lot but should still finish the job ok. Sure why not. You'd have to make sure the serial.c code is written to support it as well. However, you'd also have to address how to handle a parity error in the comm protocol as well. It's better to do a check of the message via parity or CRC and report back to the GUI via an explicit protocol reply. That's slated for the ARM version, where we have plenty of cycles to compute a good CRC. Yes, I can see it being useful. Again, this is still a problem of available flash on the 328p. v1.0 is right at and exceeds the flash storage depending on the options enabled and if an Arduino Uno or non-Uno without Optiboot (Duemilanove/Nano) is used. Every byte is precious at this point.
Ok, I am aware of this. Made some small calculations though : suppose a 3D carving would result into 1mm segments each segment could be something like X123.000Y456.000Z789.000 which is 25 bytes or 250 bits at 19200 baud that would still be 19200/250 = 76.8 lines/s or 76.80 mm/s or 4608 mm/min feedrate which is rather high for a (home-made) CNC Anyway, for some reason I can't get my RS232 to work 100% reliable : the Arduino crashes/resets for some reason when using RS232 io USB, haven't been able to pinpoint the exact cause. So I am back onto USB/115200 for the time being.
That is definitely the way to go - I will spend some thinking on this and send you a proposal for the future GRBL on ARM.
Yes. You don't need a lot of throughput theoretically that 115200 allows, but you do for certain situations like 3d printing. You can often exceed 10000 mm/min and have line segments as small as 0.1mm, depending on the quality and settings of the CAM program. Grbl can move a belt-driven hobby CNC upwards to 25000 to 35000 mm/min (personally verified), and a user demonstrated that it can cut at 15000 mm/min with HSM tool paths on the same machine. So, it's feasible to achieve these speeds or faster on purpose-built machines. However, if you combine that with the communication latency penalties involved with USB and the USB-serial converters, you'll find that 115200 is barely enough in certain situations with Grbl's send-response protocol. This is why you see 3d printers often running at 250000 baud, which still use this protocol. As for 100% reliability, some Grbl users pinpointed one reason as being the CH380 USB-serial converters on knockoff Arduinos being a culprit. Their firmwares are poorly written and often will overflow their buffers when a lot of comm traffic is put through them. Other problems are usually EMI-related, like having the USB cable too close to a spindle power cord. USB cables with ferrite cores on them help, but moving sensitive electronics away is usually the best medicine for this problem. Lastly, 115200 isn't the most stable speed on the Arduino at 16MHz (see spec sheet on this). There are others that are more accurate like 250000, but in testing, this doesn't seem to have any correlation to users having comm issues, which by the way isn't common.
Thanks! all good to know. My problems with RS232 are most likely not EMI related, as I can reproduce them with steppers and spindle-power disconnected. I'll investigate in more depth some time later. Thanks for your replies, support and your great work on GRBL.
I know this thread isn't about 3rd party GUI's but I was wondering if anyone knows of a way to hide or remove an axis (Y) from the display screen of either bCNC or Universal G-code sender (or any others for Raspberry pi) ? It's only really an aesthetic thing but it would be nice, for a lathe.
Thank you first for your effort and work you have taken up. I just completed my build on the C-Beam and can't make anything move with the Grbl software. I don't know how to input the Grbl settings jpg image into the Grbl settings panel window. Power supply is working, the X Pro2 lights up through the USB connection, but I still can't get my motors to move. Any suggestions?
You have to go step by step : 1. Is the XPro controller getting power (leds ?) (seems that is ok in your case) 2. Does the XPro respond when you plug in an USB cable and start (eg.) Universal G-Code Sender (or even Putty if you want to go really basic) : you should see some response after resetting. When you type the '$$' commands into UGCS, you should see your current settings displayed. You should then try to SET your settings. 3. Make sure all your settings or correct. Remeber that when you have homing and limit-switches enabled, GRBL will boot into an Alarm-Lock mode and only start accepting commands after homing is completed ($H command) 4. Are your stepper motors properly wired ? Measure with a volt-meter over the A+ A- terminals. check that the stepper motor coils are connected properly : 1 coil to A-A+ and the other to B-B+ From your remark it looks like using GRBL together with UGCS (or PUTTY) is the first thing you need to master. Then you will get your settings right, then you can trace back all hardware matters.
I'm at my wits end. I've built an enormous cnc router but I cant get Grbl to behave. I'm using a mega2560 powering tb6560 boards. everything is pretty straight forward and similar to common builds. My problem is that when I power the machine up it moves all the axes like a homing sequence but in 1 step per second ticks. as soon as I open a serial monitor it stops moving and pretends to be working fine but when I send it Gcode it just doesn't do anything but tell me everything is fine. As soon as I turn off the serial connection it goes back to ticking in the same direction it was before. P.S. If someone can point me to a mechanic friendly tutorial on how to get Grbl on a mega2560. Pretty sure I've hung myself 6 ways from Sunday with all the shoe stringing I did.
Did your controller come pre-flashed with Grbl? If not I suggest contacting the supplier & see if they have a known good Grbl you can flash to your controller.
i have some problem in configuration of grbl setting.my homemade cnc made by cnc shield and grbl . stepper drivers are A4988 . i use belt and pulley and for x and y directions in one rotation of stepper motor belt run 92 mm. for x direction i use 1.8 deg FH6-1570 01 (TYPE 103H7121-1741) sanyo denki stepper and grbl setting sets : $100=2.000 (x, step/mm) $110=10000.000 (x max rate, mm/min) $120=20.000 (x accel, mm/sec^2) $130=200.000 (x max travel, mm) x stepper runs very but stepper runs very slowly and not continuous. is there any problems or stepper runs well?
$100 should be closer to =80 Most steppers with belts and a 20 tooth pulley use 80 steps per mm. That will give you a better starting point. try $100=80 (x, steps/mm)
when i use $100 more than 2.222 belt runs to fast and it is not accurate.for example when i command to run 10 mm it runs 100 mm.
Found this github for anybody in a similar position looking for a stable mega2560 grbl build. ( GitHub - LETARTARE/Grbl-xx_with_Arduino: To build Grbl-xxx in Arduino-xxx (actually xxx=1.0.5 or 1.0.5r2) ) With this copy Universal Gcode sender speaks with my board now and not just my arduino serial monitor. will update when I get a chance to power up the gantry again.
