Hi Sonny, please can you explain me implementation of Bresenham algorithm in stepper.c I only find stepper counting like this if (st.counter_x > st.exec_block->step_event_count) { st.step_outbits |= (1<<X_STEP_BIT); st.counter_x -= st.exec_block->step_event_count; if (st.exec_block->direction_bits & (1<<X_DIRECTION_BIT)) { sys.position[X_AXIS]--; } else { sys.position[X_AXIS]++; } } But where is some math? Thanks
That's the beauty of Jack Bresenham's insight. You don't anything other than addition/subtraction. The algorithm accumulates deviation (error) of the actual discrete points (steps) from the computed position as you move/draw a line. When the error exceeds, typically, 1/2 of a discrete point, it adds or subtracts the full step. This gives you more detail. I think everyone who writes code should understand this as it has uses in a surprising number of places.
hello,, I'm new to this cnc business,,, I have a small desktop cnc for engraving and routing into wood. ive been able to get my images into g code for the grbl and Arduino powered cnc,,, my problem is that when I send the code to the machine,, it doesn't get all the way down to my material. ( 1/4 inch plywood) what am I missing? thanks in advance. (ive attached the file that I'm trying to engrave onto the plywood)
Your code has a tool change command that GRBL cannot process T0 M6 remove that line then there is the question of 'where is zero?' you need to set the set the tip of the tool on the surface of the wood and set Z=0 at that point. you don't say which GUI you are using otherwise I could give specific instructions. Here is an example from UGS you can see that the machien position for Z is -114mm but the current WORK position is 0. I did that by jogging to where I want it then pressing the 'reset Z axis' button. BTW if you are using UGS 1.0.9 then you need to update to the latest stable or nightly build Download - UGS (down at the bottom)
thanks for getting back with me so fast,,,,the gui I'm using is grbl control,,,, I searched through the code, but didn't see the TO M6 code,,, is there a gcode checker to see if code with work when converting a jpg to g code?
IIRC 'grbl control' has not been updated to work with GRBL 1.1 so you need to check what version you areusing. GRBL itself has a check mode Grbl v1.1 Commands · gnea/grbl Wiki · GitHub
I have made a picture about the state machine of GRBL, from how I understand it from the wiki documentation. Probably nice to share and also hear if anything important is missing/incorrect. Grt, Patrick
Hi all, following up from some posts back in August. First of all, thanks for all your help and input! TL;DR version at the bottom. I'm trying to us GRBL for interactive realtime control - and I'm 99% successful - but there's some timing inaccuracies I still need to resolve. I know that GRBL isn't written with this use case in mind, but I've learned (the hard way) that libraries like AccelStepper simply can't run fast enough for my needs. My hope is that with a combination of settings and (hopefully minimal) code tweaks I can repurpose GRBL to simply pass through a stream of gCode with as little latency and as much temporal accuracy as possible. Here's my current setup and problem. I'm using GRBL to play back animation for a kinetic sculpture. As an animator I work at 30 frames per second, so I've run my animatino through a python script that generates 18,000 lines of gcode commands. Each command contains an X and Y coordinate and the speed it should use to get there (I've also tried a version that uses G93 mode to let GRBL calculate speed - each move should take 1/1800th of a minute - with similar results). This approach is >99% accurate but not perfect. Over the course of a ten minute animation I have a +/- 2 second deviation in playback time. Each time it plays back (very) slightly differently but, since I'm syncing the motion with video that's not good enough. What I can't figure out is why it should be different at all! I'm streaming the same commands at the same speed to the same hardware each time. I've also cranked GRBL's acceleration settings to be the same as its max speed setting (since my animation has eased acceleration built in), so calculating eased starts and stops shouldn't be interfering. Eventually I'd like to stream realtime generated commands for interactive sculptures, I really need timing to be perfect. SO two questions: Why would timing be different from one run to the next? And what's involved in disabling as many of GRBL's advanced features as possible and simply using it as a dumb passthrough for your very smart stepper driving command queue? Thanks again and happy 2018 everybody! --David
The timing crystal on an Arduino isn't perfect. It has some variation in it. You are likely seeing this. Or it could be slight variations in the g-code stream, but this would not matter if the streaming is relatively slow (< 50 lines/sec).
Lol! That looks way more complicated than what I have in my head. I'm hoping I can clean that all up in the next major version.
Sonny thanks for the fast response! I'm definintely aiming for < 50 lines/second. My animation is specifically tuned to 30fps so by that measure should be fine. Can you think of any other sources of inaccuracy - or any tweaks I can make to improve it?
At 30 lines per second, you may run into streaming issues. It depends on how fast you are moving. Also make sure that step idle delay is set to 255. This will prevent the steppers from timing out, if the buffer starves.
Hi there New to GRBL, I'm currently integrating it in an application. It works great - except homing but that might be due to my test card - and I'd like to improve my application code. So have I several questions: 1- Is there a FAQ for developers? Not found, sorry if is exists. 2- When closing the communication and then reopening it, the Arduino has reset its position registers to (0,0,0). Is it not possible to keep the position at the next start? Is it my init procedure that is resetting the counters? 3- When sending a block of G-code lines, is it possible to disable the "ok<CR><LF>" or "{2/1}ok<CR><LF>" acknowledges returned by the Arduino? I'm not using it and my supervision is made only with '?' command, which is perfect for me. These acknowledges are then loading the transmission. 4- By the way, the RX data of the ?-status feedback contains "RX:N1,N2/N3". I understand that N1 is the number of bytes in the RX buffer and should never exceed 127. What are N2 and N3? 5- The Buffer data of the ?-status feedback is "Buf:N1". What is exactly N1? The number of commands remaining in the buffer? Does it include the current vector in progress? Thanks for any help.
yes there is Home · gnea/grbl Wiki · GitHub under 'interface' this is normal for the Arduino, any serial connection will reset the board. you can prevent it by putting a 10uF capacitor between RESET and GND. I am pretty sure the above is answered in the Wiki, read that first....
Hi Sonny et al, I'm back with some followup questions about timing. I'm still having sync issues (and still doing something GBRL wasn't originally designed for), trying to write some forensics tools. Quick recap is that I'm streaming thousands of gcode commands, each of which is supposed to take exactly 1/30th of a second to execute, but I'm getting inconsistent playback rates. I'd like to add a routine to log a timestamp every time GRBL executes a line of gcode, then stream it all back to my GUI once the gcode is finished. If I called this routine from inside plan_block_t *plan_get_current_block(); of planner.h, would that give me the most accurate data? I'm afraid that all of the clever optimization happening elsewhere in GRBL might make it impossible to know exactly when one gcode command ends and another begins. If not that function, where else might I trigger a timestamp? Thanks again for your help, --David
Hi David-the-Swarfer, thanks for your reply. Indeed I found some answers but not all, especially how to disable the "ok<CR><LF>" acknowledge. I guess this can be done only by changing the firmware, not from an interface command.
Hi all, nice to be here I have just finished building my first cnc router and about to start actually doing something with it, during my build I somehow managed to blow up 2 grbl boards and 6 drivers, hey note to myself, don't connect voltages when tired late at night also I have a problem, I think, thanks to YouTube I found how to set the voltage using the trimmer pots on the driver boards, I set all 4 drivers initially to 0.75 volt and it all works and tests fine, that is apart from one of the stepper drivers powers one motor (Y axis) and when it finishes working it goes absolutely solid locked and sounds like it is groaning, the other 3 are firm but not locked up I tried increasing the voltage on the 3 looser stepper motors to 1.0 volt and it didn't seem to make a lot of difference, but to get the solid stepper driver down to the same stiffness I have had to drop the voltage down to 0.4 volt and it did stop groaning and loosened a bit I swapped over the motors, same result, moved the driver to another spot on the grbl board exactly the same effect on a different motor, so it looks to me like it is the DRV8825 driver board is this a case of I have 1 bad board and 3 good boards? or 1 good board and 3 bad boards ? any help would be more than welcome info on my cnc build and components below basically the cnc has a bed of 900mm x 900mm and is pure self build made up of parts found laying around my workshop, rails bearings lead screws etc, and I added in a new Arduino uno (of which I am novice) and a new GRBL board and ended up using DRV8825 drivers, stepper motors are used (eBay) 4 x identical minebea 23LM-C343-14V wired from 6 wire down to 4 wire with pairs being red & yellow and pair 2 being blue & orange, which I believe is correct LINK TO STEPPER MOTOR SPEC SHEET please correct me if I have made a mistake I have used links to set all drivers to 1/32 micro stepping, also set the mm rate so it is exact at 500mm travel, and set max speed at a sensible 400mm per minute as I am not really expecting supersonic speed and all is nice and quiet, nothing straining I have paired 2 of the stepper motors via the grbl to drive the X axis and used the clone spare on the GRBL to make that work, which it does marvellous The CNC structure does need strengthening up as mostly built on ply at the moment, but everything works as expected, the spindle is a nice almost new RotaZip high speed tool that I bought new about 4 years ago and only used it on one job so keeping stuff does come in handy even if wifey says it doesn't Look forward to sharing info on here as I learn more
Sorry about the late reply. I don't check this thread as often as I should. The planner places motions into a queue and plans over those queued motions. It doesn't tell you when something is executed. That stuff is in the stepper.c file. However, you can enable the line number reports in config.h and this will include a gcode line number (Nxxx) that is currently executing in the status reports. For this to work, you have to send with your gcode by appending or prefixing the gcode line with a unique Nxxx value. This comes with consequences though. This increases the bandwidth usage, slows down the streaming, and makes the planner buffer smaller to get the extra memory for retaining the line number data. I wouldn't use this in every situation unless you need it, which is why it is disabled by default.
Hi, I have a problem with my steppers. When running at a low feed range (~100), then the steppers look to start stalling or "swapping" (stepping back and forth irregularly). I have no problem at higher speeds (e.g. 1000) - at least that's how it looks like. I reduced the max acceleration significantly, made a long move, and during this rather long acceleration period the problem occurs for a moment when in this low feed range. Could this be somehow related to the configuration settings of GRBL? I have DRV8825 drivers and use the default step pulse size, which should be OK (> 1.9us). Thanks in advance for any tips, Grt, Patrick
GRBL has a perfectly good PWM laser mode Grbl v1.1 Laser Mode · gnea/grbl Wiki · GitHub with options for instant on or acceleration related ramp up. the only limitation I can see is that cheap boards might have the spindle enable pin connected to the GRBL V0.8 pin which was on/off only. As of GRBL V0.9 it uses a different pin so it can do full 8bit PWM for spinde/laser control. There are also options for a separate enable pin, you need to read the Wiki!
all of that is very specific to the laser and is better handled by an external controller. generic PWM in and 'whatever you need out'. then it works with ANY controller. turn on/off delays should be handled in the Gcode which in turn is handled in the post processor that creates the Gcode.
Hello Sonny, I have some trouble with my machine. I use the GRBL controller3.1.6. When I connect my computer with the usb kabel to the gshield end click open it says ( no data from port after connect: expecting grbl version string. What can/must I do to solve this problem? Thanks in advance. Bert Klappe [email protected]
grbl-controller has not been updated to work with GRBL v1.1 try one of these GRBL-panel UGSplatform bCNC Candle
Hi Sonny, I’ve tried everything you mentioned but nothing works. Also there’s a blinking and constant red light on my Arduino board. What did I do wrong and can I fixes this. With regards Bert Klappe
follow the instructions at Compiling Grbl · gnea/grbl Wiki · GitHub for installing the latest GRBL on your controller. Use the 'via Arduino IDE' instructions so that you can use the Arduino IDE serial monitor (CTRL-SHIFT-M) to check that GRBL is happy. Set the serial speed to 115200 . after it connects you should see which means that GRBL has booted ok. type $$ and press enter and it should display all the setup variables, further confirming it is ok.
Is there something about the Z axis that requires special steps to make the end stops work on the grbl board. I have checked, double checked and rechecked the end stop connections, how they are plugged into the grbl, and the settings and they all seem ok (I have both min and max stops), but regardless, they don't want to work. min and max work on both the X and Y stops, but Z seems to ignore the stops. There is nothing different in how X, Y and Z are setup except the steps per mm. I wanted to test the homing, but if the Z stops are not recognized, I can't. Any suggestions?
what version of GRBL? what compile options? what 'GRLB board'? and yes, there is something about the Z axis... in the transition from GRBL 0.8 to 0.9/1.1 the pins for Z limit and spindle PWM changed.... Connecting Grbl · grbl/grbl Wiki · GitHub but compile options can change it back if you don't need spindle PWM. knowledge is power! read the wiki! (-:
