grbl / grbl Goto Github PK

I have found a small issue where the steps per mm variables do not get entered correctly if the first number after a dot (".") is a zero. For example if you set the variable $2 to 603.061 then it really sets it to 603.61. This can be easily tested by setting the variable and then checking the variable.

Hi, a small issue when running for instance:
G2 X58.28426395939086 Y21.850253807106597 I0.40609137055837563 J-4.482233502538071
This is code that comes from the Partkam online program. Way too precise and it creates a arduino reset. This is happening only with I and J.

I resolved it myself by running a validation script before sending it to grbl, just to be sure. But perhaps grbl should limit / roundoff these kind of numbers by default?

Sorry if I'm being a dummy somehow, but it seems like whenever I set my step pulse to 1 or 2 microseconds, I instead get a step pulse of around 125 microseconds. Settings of 3+ work as expected. I'm using one of Adafruit's Boarduinos with an atmega328 in it.

A pulse of 5 microseconds works just fine for my purposes, so it's not really an "issue" for me, but I thought I'd report it anyways.

My settings follow:

$0 = 377.951 (steps/mm x)
$1 = 377.951 (steps/mm y)
$2 = 377.951 (steps/mm z)
$3 = 1 (microseconds step pulse)
$4 = 600.000 (mm/min default feed rate)
$5 = 600.000 (mm/min default seek rate)
$6 = 0.100 (mm/arc segment)
$7 = 0 (step port invert mask. binary = 0)
$8 = 4.800 (acceleration in mm/sec^2)
$9 = 50.000 (max instant cornering speed change in delta mm/min)

Hi Simen,

I'm new to your development. I was originally gathering information on writing a motion control myself. Came across your development, which I find the level of sophistication is amazing. Pissing off my plan to write my own.

I have recently bought a stepper driver that has a two separate clock input for CW and CCW direction. Not the standard CLK and DIR mode. Is there a way for your code to support it?

I wrote mainly VB.net for my living. Not too fluent in C.

Cheers
Victor

Here I'd like to start a discussion whether or not software xon/xoff flow control should be integrated into grbl's serial interface. There are both benefits and drawbacks in terms of use, and it is easy to implement.

The primary and greatest benefit is that any standard serial terminal program supports xon/xoff software flow control. This really simplifies streaming g-code to grbl, as a user can just send/upload the file and grbl should execute it to the end of file. A second important benefit is that grbl can access the next g-code block command immediately from the serial read buffer without having to perform the 'ok' handshake and wait for a response. This really speeds things up and prevents planner starvation.

The primary drawback is that it limits the streaming interface and can limit control, since the serial port is the only software connection to grbl. In the status report discussion, the question was raised: how do would you send run-time commands, like feed holds and abort, while streaming the g-code program at the same time? If the XOFF flag is sent from grbl when its receive buffer is full, this effectively blocks transmit communication to grbl, unless a special streaming interface is designed to force transmit run-time command characters. At this point, a specialized streaming interface negates the simplicity benefit.

Right now, the stream.py script does a pseudo-XON/XOFF flow control by counting and tracking the sent characters to grbl's buffer. Not exactly clean and simple, but effective.

So I guess my question is: where do you all see the primary interface of grbl going? Does it make sense to keep the 'ok' and 'error:' response interface or should we begin to look into efficient alternatives for replacement or enhancement? This should all come with a consideration of not dropping current user support and messing with their interfaces without good reason.

just wanted to make everybody aware that the use of _delay_ms in the mc_dwell means that there can be no longer delay than 6.5 seconds... it's a _delay_ms issue... if we want longer delays we have to program a timer or an interrupt.

I am running 12.5mm pulleys on my system (with the belt, the actual diameter could be slightly larger) with steppers that are 200 steps/rev set to 16x microstepping through the driver. This means that the circumferance is about 39.2mm and there are 3200 steps per rev. This means that my steps per mm should be very close to 81.5. However when I went to calibrate the axis, the actual distance traveled with a g1x100 command is 51.66mm. This means that my equivalent diameter is 6.457mm and that there are actually 157.737 steps/mm. I am curious as to why this would be so far off (infact almost a factor of 2). I mean, it doesn't really matter because with the right constant in there, it gives 100mm movement for a g1x100 command, but it is still a bit confusing.

Hi Simen,

I am attempting to use GRBL with a Makerbot DC Servo Controller, It uses GND, Step, Direction, Enable and Reset pins.
The controller has stepper to servo emulation, so I can use servo motors.

I read the post from dirktheeng about creating a new branch that more then likely would include modifications to stepper.c to include the changes I need for enabling the stepper.

I have looked for new branches and cannot locate the branch that contains dirktheeng's code with enablement.

Any suggestions about how I can setup stepper enablement? I would need active low to enable the stepper emulation.

Thanks

Joe Pitz

Hi,
I am currently using grbl with 2 ULN2003 transistor arrays(per stepper).
The steppers are connected like this http://ssecganesh.blogspot.com/2008/05/driving-stepper-motor-using-uln2003.html
I tested my code also with a L293D H bridge and it works well. This could lower the price for a grbl stepper driver board.

Is this feature welcome in grbl? It would need a config option which decides whether to compile the stepper driver or the H bridge code.
Thank you

How well can others run the following lines without missing any lines and usb keeping up? The following is a bunch of ~0.1 mm lines for part of a small wooden gear. When I run it with my modified version of Grbl doing some extra handshaking I get delays. Arduino runs the lines as fast as it gets them and is waiting for usb to feed each line. Maybe ~0.1mm moves are too small? Maybe I need to do bigger buffers/possible SD card.

N20 G00 Z 20.000
N30 G00 X 0.000 Y 0.000
N40 G00 X 17.402 Y 17.425 Z 5.999
N50 G01 Z -1.000 F30.0
N60 G01 X 17.399 Y 17.551 F180.0
N70 X 17.390 Y 17.678
N80 X 17.374 Y 17.807
N90 X 17.350 Y 17.938
N100 X 17.320 Y 18.069
N110 X 17.282 Y 18.200
N120 X 17.236 Y 18.331
N130 X 17.183 Y 18.461
N140 X 17.122 Y 18.588
N150 X 17.053 Y 18.713
N160 X 16.977 Y 18.835
N170 X 16.894 Y 18.954
N180 X 16.803 Y 19.067
N190 X 16.706 Y 19.176
N200 X 16.603 Y 19.279
N210 X 16.495 Y 19.376
N220 X 16.381 Y 19.466
N230 X 16.263 Y 19.549
N240 X 16.141 Y 19.625
N250 X 16.016 Y 19.694
N260 X 15.888 Y 19.755
N270 X 15.759 Y 19.809
N280 X 15.628 Y 19.854
N290 X 15.497 Y 19.892
N300 X 15.366 Y 19.923
N310 X 15.235 Y 19.946
N320 X 15.106 Y 19.962
N330 X 14.978 Y 19.972
N340 X 14.852 Y 19.975
N350 X 14.727 Y 19.972
N360 X 14.599 Y 19.962
N370 X 14.470 Y 19.946
N380 X 14.339 Y 19.923
N390 X 14.208 Y 19.892
N400 X 14.077 Y 19.854
N410 X 13.946 Y 19.809
N420 X 13.817 Y 19.755
N430 X 13.689 Y 19.694
N440 X 13.564 Y 19.625
N450 X 13.442 Y 19.549
N460 X 13.324 Y 19.466
N470 X 13.210 Y 19.376
N480 X 13.102 Y 19.279
N490 X 12.999 Y 19.176
N500 X 12.902 Y 19.067
N510 X 12.811 Y 18.954
N520 X 12.728 Y 18.835
N530 X 12.652 Y 18.713
N540 X 12.583 Y 18.588
N550 X 12.522 Y 18.461
N560 X 12.469 Y 18.331
N570 X 12.423 Y 18.200
N580 X 12.385 Y 18.069
N590 X 12.355 Y 17.938
N600 X 12.331 Y 17.807
N610 X 12.315 Y 17.678
N620 X 12.306 Y 17.551
N630 X 12.302 Y 17.425
N640 X 12.306 Y 17.299
N650 X 12.315 Y 17.172
N660 X 12.331 Y 17.042
N670 X 12.355 Y 16.912
N680 X 12.385 Y 16.781
N690 X 12.423 Y 16.650
N700 X 12.469 Y 16.519
N710 X 12.522 Y 16.389
N720 X 12.583 Y 16.262
N730 X 12.652 Y 16.137
N740 X 12.728 Y 16.015
N750 X 12.811 Y 15.896
N760 X 12.902 Y 15.783
N770 X 12.999 Y 15.674
N780 X 13.102 Y 15.571
N790 X 13.210 Y 15.474
N800 X 13.324 Y 15.384
N810 X 13.442 Y 15.301
N820 X 13.564 Y 15.224
N830 X 13.689 Y 15.156
N840 X 13.817 Y 15.095
N850 X 13.946 Y 15.041
N860 X 14.077 Y 14.996
N870 X 14.208 Y 14.958
N880 X 14.339 Y 14.927
N890 X 14.470 Y 14.904
N900 X 14.599 Y 14.888
N910 X 14.727 Y 14.878
N920 X 14.852 Y 14.875
N930 X 14.978 Y 14.878
N940 X 15.106 Y 14.888
N950 X 15.235 Y 14.904
N960 X 15.366 Y 14.927
N970 X 15.497 Y 14.958
N980 X 15.628 Y 14.996
N990 X 15.759 Y 15.041
N1000 X 15.888 Y 15.095
N1010 X 16.016 Y 15.156
N1020 X 16.141 Y 15.224
N1030 X 16.263 Y 15.301
N1040 X 16.381 Y 15.384
N1050 X 16.495 Y 15.474
N1060 X 16.603 Y 15.571
N1070 X 16.706 Y 15.674
N1080 X 16.803 Y 15.783
N1090 X 16.894 Y 15.896
N1100 X 16.977 Y 16.015
N1110 X 17.053 Y 16.137
N1120 X 17.122 Y 16.262
N1130 X 17.183 Y 16.389
N1140 X 17.236 Y 16.519
N1150 X 17.282 Y 16.650
N1160 X 17.320 Y 16.781
N1170 X 17.350 Y 16.912
N1180 X 17.374 Y 17.042
N1190 X 17.390 Y 17.172
N1200 X 17.399 Y 17.299
N1210 X 17.402 Y 17.425
N1220 G01 Z -2.000 F30.0
N1230 G01 X 17.399 Y 17.551 F180.0
N1240 X 17.390 Y 17.678
N1250 X 17.374 Y 17.807
N1260 X 17.350 Y 17.938
N1270 X 17.320 Y 18.069
N1280 X 17.282 Y 18.200
N1290 X 17.236 Y 18.331
N1300 X 17.183 Y 18.461
N1310 X 17.122 Y 18.588
N1320 X 17.053 Y 18.713
N1330 X 16.977 Y 18.835
N1340 X 16.894 Y 18.954
N1350 X 16.803 Y 19.067
N1360 X 16.706 Y 19.176
N1370 X 16.603 Y 19.279
N1380 X 16.495 Y 19.376
N1390 X 16.381 Y 19.466
N1400 X 16.263 Y 19.549
N1410 X 16.141 Y 19.625
N1420 X 16.016 Y 19.694
N1430 X 15.888 Y 19.755
N1440 X 15.759 Y 19.809
N1450 X 15.628 Y 19.854
N1460 X 15.497 Y 19.892
N1470 X 15.366 Y 19.923
N1480 X 15.235 Y 19.946
N1490 X 15.106 Y 19.962
N1500 X 14.978 Y 19.972
N1510 X 14.852 Y 19.975
N1520 X 14.727 Y 19.972
N1530 X 14.599 Y 19.962
N1540 X 14.470 Y 19.946
N1550 X 14.339 Y 19.923
N1560 X 14.208 Y 19.892
N1570 X 14.077 Y 19.854
N1580 X 13.946 Y 19.809
N1590 X 13.817 Y 19.755
N1600 X 13.689 Y 19.694
N1610 X 13.564 Y 19.625
N1620 X 13.442 Y 19.549
N1630 X 13.324 Y 19.466
N1640 X 13.210 Y 19.376
N1650 X 13.102 Y 19.279
N1660 X 12.999 Y 19.176
N1670 X 12.902 Y 19.067
N1680 X 12.811 Y 18.954
N1690 X 12.728 Y 18.835
N1700 X 12.652 Y 18.713
N1710 X 12.583 Y 18.588
N1720 X 12.522 Y 18.461
N1730 X 12.469 Y 18.331
N1740 X 12.423 Y 18.200
N1750 X 12.385 Y 18.069
N1760 X 12.355 Y 17.938
N1770 X 12.331 Y 17.807
N1780 X 12.315 Y 17.678
N1790 X 12.306 Y 17.551
N1800 X 12.302 Y 17.425
N1810 X 12.306 Y 17.299
N1820 X 12.315 Y 17.172
N1830 X 12.331 Y 17.042
N1840 X 12.355 Y 16.912
N1850 X 12.385 Y 16.781
N1860 X 12.423 Y 16.650
N1870 X 12.469 Y 16.519
N1880 X 12.522 Y 16.389
N1890 X 12.583 Y 16.262
N1900 X 12.652 Y 16.137
N1910 X 12.728 Y 16.015
N1920 X 12.811 Y 15.896
N1930 X 12.902 Y 15.783
N1940 X 12.999 Y 15.674
N1950 X 13.102 Y 15.571
N1960 X 13.210 Y 15.474
N1970 X 13.324 Y 15.384
N1980 X 13.442 Y 15.301
N1990 X 13.564 Y 15.224
N2000 X 13.689 Y 15.156

Hi, At this moment the feedback you get from grbl is about the command-buffer.
For user feedback the current command that is being executed is helpful as well. I don't think that this is possible in the current setup. I've tried something with counting the number of 'ok' responses, but that is not really working.
What's your take on that? Is that something I could implement in the current setup, would you consider it or is it out of the core of grbl?

Hi,

I'm having a strange issue with Grbl, sending a GCODE file generated from Eagle with the pcb2gcode plugin causes the Arduino to stop sending signals to the drivers at a random point, while returning ok on the serial connection. I have removed comments from the files, tried without spaces but it still happens.

The things I have changed in order to get my setup working are:

• setup the cpu to atmega168 instead of atmega368p in the Makefile
• setup the steps per mm to 320 and feed rates to 400
• inversed the Step signals
• inversed the X direction
• set serial speed to 115200 then lowered to 19200

Not sure if anything of the above or a bug would cause this, or I have a really bad electronics issue with the drivers/Arduino.

Can I send you the file I'm trying with somehow?

Is it possible to send a 'reset' command to grbl so that it stops the current action and removes the commands in the buffer? Similar to an ardiono reset button?

If yes, how, and if no, would that be something you would consider?

I am making an interface and a big red 'abort' button would be a good addition.

I am curious how stepping in limits can work without enabling/disabling steppers .... i guess this feature never worked in this state

I tested on my mill and it just respond with an ok to G28/30, without doing anything

I seem to get a problem when running a larger file. The code will only execute to the very same line every time. It would seem to be 100 lines of Gcode.

Hi there,
i startet to code a small GUI for windows using c#. What is the right way to Stream Gcode to the Arduino? When i send all the lines together, the Arduino freezes after approx 35 lines of gcode. Is there any way to receive the actual queue status from gbrl so ensure that only the next few lines are in the buffer? What would be the best/easiest way to stream larger files to the firmware?

Best regards, Ben

I started using grbl with an Arduino diecimila which worked OK for simple shapes (squares, stars) but when I fed it anything complex it would exhibit this behavior. Thinking it was due to the limits of the diecimila I replaced this with an Arduino Uno, and I'm seeing similar results.

The problem manifests as the system stopping mid-job, typically around 20 steps, after a few seconds, the stepper motors "lurch" and then nothing else happens.

I next thought it might be the gcode streaming setup I was using (a windows program running inside a windows VM on my mac) so I switched to using stream.rb but I'm seeing the same results. Here's what the verbose output looks like:

Jason-Gullicksons-MacBook-2:script jasongullickson$ ruby stream.rb -p -v sat_0003.nc
Processing file sat_0003.nc
G90
G21
G0 X24.0755 Y19.7266
M03
G1 F30.000000
G1 X21.1376 Y13.253
G1 X14.1191 Y14.1956
G1 X16.1185 Y17.1478
G1 X24.0755 Y19.7266
M05
G0 X18.1316 Y23.9059
M03
G1 F30.000000
G1 X15.5065 Y19.6021
G1 X12.8133 Y18.9263
G1 X14.4047 Y22.5187
G1 X18.1316 Y23.9059
M05
G0 X14.9624 Y17.8414
M03
G1F30.000000
Grbl >>
Grbl >> Gr
Grbl >> Grbl 0.6b
Grbl >> '$' to dump current settings
Grbl >> error: Expected command letter
G02 X14.8158 Y17.1606 I-1.6543 J0.0001
Grbl >> ok
G02 X14.1191 Y15.9741 I-5.8858 J2.658
Grbl >> ok
G02 X13.2008 Y14.9285 I-7.3696 J5.5469
Grbl >> ok
G02 X11.9564 Y13.8577 I-8.9782 J9.1746
Grbl >> ok
G02 X9.7392 Y12.5417 I-7.032 J9.322
Grbl >> ok
G02 X8.42 Y12.2571 I-1.3192 J2.9147
Grbl >> ok
G02 X7.755 Y12.5034 I-0. J1.0207
Grbl >> ok
G02 X7.5087 Y13.0396 I0.4604 J0.5362
Grbl >> ok
G02 X7.9513 Y14.4099 I2.3424 J0.
Grbl >> ok
G02 X10.2154 Y16.7921 I9.8949 J-7.1373
Grbl >> ok
G1 X10.8139 Y15.4405
Grbl >> ok
G01 X10.9566 Y15.3499
Grbl >> ok
G03 X11.2219 Y15.4405 I0. J0.434
Grbl >> ok
G03 X11.4472 Y15.7168 I-0.4639 J0.6082
Grbl >> ok
G01 X11.4532 Y15.9207
Grbl >> ok
G1 X10.8547 Y17.2723
Grbl >> ok
G02 X12.9356 Y18.4741 I5.875 J-7.7708
Grbl >> ok
G02 X14.0511 Y18.6239 I0.8323 J-1.9682
Grbl >> ok
G02 X14.7161 Y18.3776 I-0. J-1.0208
Grbl >> ok
G02 X14.9624 Y17.8414 I-0.4604 J-0.5362
Grbl >> ok
M05
Grbl >> rror: Bad number format
Grbl >> ok
G0 X13.9287 Y18.375
Grbl >> ok
M03
Grbl >> ok
G1F30.000000
Grbl >> ok
G03 X13.2109 Y18.259 I0.0001 J-2.2796
Grbl >> ??C?????0.6b
Grbl >> '$' to dump current settings

...at this point the "lurch" occurs and I pulled the USB cord from the Arduino.

I can include the gcode file if that is helpful (it was generated using Inkscape), or any other information you can think of.

I'm looking forward to using grbl, thank you for your hard work!

Conversation... Not an issue. I am building a 2nd cnc machine with Tandem/Dual/2 screws/motors on my Y axis. I want to prevent damage that could occur from one motor moving and one not moving.

Not sure what exists in Grbl. I am thinking about implementing a simple encoder on each axis...... using 2 proxs on each screw I will be able to sense direction and 1/4 rev positions. I plan to modify grbl to keep track of positons of screws and if they are ever off by more then 1/2 a rev I know I have a problem and should stop. I believe I can do even better then 1/2 rev though. With some dead bands at 1/4 rev transition points I should know if I am having issues if there is a mismatch......... This could be interesting for single motor axis too. It would be interesting to see how accurately transition points match grbl position.

Good idea? Is there better ways to implement simple low cost encoder? What is typical practice for screw position monitoring on a dual tandem 2 screw/motor axis?

(I also plan to implement a 4th axis in order to be able to move motors independently for slight position corrections etc. Further down the road I plan to add 5th for lathe type sort of axis)

I'm trying to set up some more complex testing for my laser and I am trying to figure out how to use the ruby scripy. I installed the ruby stuff and tried 'ruby stream.rb file.gcode' but I get an error:

'gem_original_require': no such file to load -- serial poart (LoadError)' with some other path information.

I am using windows 7 and I am willing to bet that this is the problem when I look at the SerialPort.open in the rb file

Is there a way to make this work with windows somehow? file.gcode is a small file that contains simple gcode commands. I've never used ruby before.

Status reporting is a new feature just being built into the grbl/edge v0.8a branch. I'd like to start a discussion on how the status reporting should look like, what should be included, how it works, and answer some other questions like its flexibility in the future or for users that want to hack it. Here are a few things I've been thinking about:

1. For portability and hackability, I'm considering re-organizing and placing the status reporting feature into its own report.c source file, instead of its current location as a function in protocol.c. Here it should be clear what this source file is, what it's function is, and a place for user to freely hack at it for their own nefarious needs. The required data for reporting would likely need to be re-organized a bit as well, so a user will have direct access to everything they will need.
2. Perhaps the biggest question is what will users need in the status report? Here's a list of things that are minimally required/needed on CNC mill and lathes, but some of these features are not necessarily needed for other machines/robots. To keep with the spirit of grbl, what needs to be there and what doesn't to maintain simplicity? Everything listed here are items that cannot be done off-board by an interface.

• Current XYZ position - This is the real-time position in the work coordinate system (G92) or aka part zero. This is the most important information a user would need and could be supplied in terms of mm, inches, or steps.
• Machine XYZ position/coordinate offset - This differs from the work position as being the absolute real-time position/offset from the machine home position. This needs to be retained so grbl knows where home is and may be used to establish the absolute travel limits of a machine without using physical limit switches. There are not many cases that this information would be needed in real-time, but can be very useful.
• Buffer state/size - The planner buffer state or how many blocks are stored and ready to go in the buffer. This is a great indicator of how grbl is doing when under heavy load or showing if grbl is having buffer starvation problems. Again, not needed for all users, but extremely handy and relatively easy to implement.
• Feed rate (& spindle speed) - The realtime feedrate may used to monitor feed rates through complex curves and acceleration profiles. This would be based on the trapezoid_adjusted_rate value in the stepper module.
• Line number in-process - The problem is what defines the line number. Is it the g-code 'N' line command (not required or consistent) or simply based on an internal count of incoming lines? The latter would be simpler and more accurate. The line number being processed would help a user to directly correlate where a problem is in a g-code program and compute distance to go off-board. Could be fairly easy to implement, but require some memory to track these.
• States - Reports the stepper module state, i.e. cycle start, feed hold, and possibly feed rate override (when integrated).

3. The next question is what should a status report look like? In general, the status report should be kept at a relative minimum to reduce the amount of cycles for each status report, especially for setups that need reporting 10-20 times a second. It should be straight forward and human readable. There is also the consideration that a non-human readable binary format could be included to keep the cycle budget to an absolute minimum, but would need to be used with an external interface to interpret the binary data. The need for a binary format may be debated, but here is an idea for a human readable format.
   • Grbl:Running,Ln:203,Buf:15,Rate:300.0,MPos:[0.00,10.02,4.34],WPos:[-10.00,2.22,5.00]
   • Grbl: Lists the current [Running, Hold, Idle] states
   • Ln: Line number in-process. Reset to zero when buffer empties.
   • Buf: Number of blocks left in planner buffer
   • Rate: Real-time feedrate
   • MPos:[x,y,z] Real-time machine position in mm/inch/steps (or maybe in terms of coordinate offsets?)
   • WPos:[x,y,z] Real-time work position in mm/inch/steps
   • Also, if needed, the reports could be tailored, where certain items in the report can be toggled on or off via some EEPROM settings or bitmask. For example, if the line number, buffer state, and machine position aren't needed, a user can set the EEPROM settings to show instead: Grbl:Running,Rate:300.0,WPos:[-10.00,2.22,5.00]
4. The last critical question is how should it work? First, the current implementation allows for some flexibility in how to do this. All that needs to be done is to set a bitmask in a system byte to print the report. This could be done in a number of ways, via the current '?' character, an internal timer, or even some external signal on an I/O pin.
   • Right now, when a '?' character is sent to the serial receive buffer, the run-time execution routine will reply nearly instantanously with the status report, regardless of what grbl is doing. For an interface, this would mean that it would need to send '?' characters at some periodic rate. ('?' may be changed to whatever special character, like control characters or extended ascii.) So is this good enough?
   • The main problem I can see with the current implementation is how it complicates the grbl streaming interface. If a user is streaming a file, their interface would need to send the '?' command whenever they need a report and then read and process the report in their serial buffer. At some point, I'd like to install XON/XOFF flow control into the serial module to make streaming g-code less of a hassle. Improving/changing the way grbl streams is a whole other conversation, and the way status reporting works should be a consideration with this.

Anyhow, I think most of these functionalities should be integrated into grbl by design, but they do not necessarily have to be implemented. In other words, it should be very simple for a user to 'turn on' these features or whatever they may need without much fuss. Most of the stated report data is already stored in a global struct 'sys', and the others could simply be moved into this.

Simen, Alden, Jens, or anyone else.. What do you think about this?

Grbl 0.7d

(1/16) step settings * 200 steps per turn * .8mm per turn = 2560

anyway i type

$2=2560
Stored new setting
ok

says stored - I've used 2560.00 and other variations. Still doesn't work. and in the dump I still get

$2 = 2565.000 (steps/mm z)

Not sure if serial is right , ascii is understood wrong or, eerom is read/ written correctly.

I just use 2555.

also after decimal point values are n+1.

ex

$9=5.011

i get

$9 = 10.010 (cornering junction deviation in mm)

Grbl seems to grind to a halt with F commands >= 150. I can re-create this issue as of right now 100% of the time. I am not sure if this is an issue with max stepping frequency or what. My lack of exactly how this works is limited.

Does this sound like another issue that you are aware of or should I try to narrow down the issue more and report back? What kind of problems will I run into if I just change all my F commands >= 150 to something smaller?

I should add that I am using an arduino uno 328p and grbl 0.6b.

Hi, not really an issue but a tip to make it easier for new users:
It could be nice to add some very simple test g-code. e.g. a square, circle, grbl letters etc.
So that when stuff is not working immediately you know it is not because of the gcode.

Hi all,
I have a weird problem.

Preliminaries:

1. I'm using Arduino Uno R3
2. I'm using grblshield V2
3. I'm using 3 ROB-10846 stepper motors from Sparkfun (400 steps/rev).
   (http://www.sparkfun.com/products/10846)
   4)I have been able to flash grbl to the arduino and I'm able to communicate with it through as serial port monitor. (I've been able to modify grbl settings such e.g $2)
   5)All three motors move well when I send them a G00 command. (e.g. g00 x10). I've adjusted the motor current on all three motors.

The problem I'm having is:
I can only move each motor once in a particular direction. After that command I can not ask it to go again in the same direction. But it can move in the opposite direction.

WORKS: "g00 x10" then "g00 x-10"
DOES NOT WORK: "g00 x10" then "g00 x10"

What works also is. moving the motor. Resetting the board. Then moving the motor again.
WORKS: "g00 x10" then "reset board" then "g00 x10".

Given that the motors can move twice in the same direction if I restart in between I don't think the problem is mechanical.

I think it might be some weird software issue, but I cannot figure it out.

Help!

P.S.

The movement in forward and reverse direction does not have to be equal
E.g. "g00 x5" then "g00 x-5"

I have been using the arduino serial monitor for communications for the most part.

I've also tried the simplestreaming.py file with the following gcode file

G00
Z2
Y2
X2
Z2
X2
Y2

I think the big red button that shuts down all movement immediately is a must for the next release. (Have you ever watched a faulty program break your cutter and you couldn't react because the mains switch was out of reach?). The button could be wired in series with the limit switches so that the limit switches would also trigger an immediate halt. Not sure, but I think some DIY machines can break when the lead screw is over twisted. The limit switch/e-stop input pin should be configured as an interrupt. Its already in my jgeisler0303 fork. I'll try to port it to v0.8 soon, if everybody agrees.

Hello,

I thought I would test this issue feature.

In SIGNAL(SIG_OUTPUT_COMPARE1A) interrupt routine some port D bits get turned on and off. What is this about? Is this used with LEDs hooked up during testing to provide status?

Notes: I am looking and learning from your code. I now have a fairly good general idea of how it works. I am learning some as I go too. ex. brushing up on C, it has been a while, learning some new things ex. Bresenham's algorith, timer interrupt features, etc.. Taking my time... I did buy an Arduino Mega board and plan to get around to using it some day. Still a bit of learning to do though.

Highlander01

Hi Simen,

Thank you for Grbl, it is realy greate!
I want to build a CNC Router where the stepper axis does not correspond to the x,y,z. So I have to make a coordinate transformation. My plan was to use Grbl and add a "tranformation" function from xyz to the stepper coordinates. But where would be the best place in the code to make this transformation? Do you have an advice how I can implent it in your code?

Thanks in advance!
Luke

Hi,

I am using grbl for a CNC laser project. I just got the arduino hooked up and started playing around with the motion. I noticed a slight problem when I set my feed rate high. It seems to have an audible hitch in the motion as it accelerates to speed. It does not seem to do it on deceleration. I calculated the the pulse rate where the problem starts and it comes out to be really close to 15khz. I'm not sure if I have a setting wrong somewhere, but it does it every time. Have other people noticed this? It doesn't seem to loose pulses as best as I can tell, so I am thinking that something is causing an interruption in the pulse train. I am using pololu A4988's and the pulse width is set to 20 micro seconds in grbl. There are about 81.7 pulses/mm and the acceleration is set to about 800 mm/s/s. It doesn't do it below 15khz. I am using an UNO with a 328 chip.

I've spotted a possible bug in planner.c. In the 'planner_forward_pass_kernel' function, there is a line

double max_entry_speed = max_allowable_speed(-settings.acceleration,
        current->nominal_speed*previous->entry_factor, previous->millimeters);

As far as I can tell, this should be:

double max_entry_speed = max_allowable_speed(-settings.acceleration,
        previous->nominal_speed*previous->entry_factor, previous->millimeters);

I guess this issue has already been fixed in edge, because it doesn't use the entry/exit factors.

I successfully flashed grbl_0.51_9600_328p.hex to my Uno in Windows XP SP2 with the following:

"C:\Program Files\arduino-0022\hardware\tools\avr\bin\avrdude" "-CC:\Program
Files\arduino-0022\hardware/tools/avr/etc/avrdude.conf" -patmega328p -cstk500v1
-P.\COM12 -b115200 -D -Uflash:w:grbl_0.51_9600_328p.hex

However, I can't seem to talk to the firmware with the Arduino serial monitor nor Putty with {xon/xoff,rts/cts,no} flow control. I received one or two garbage (non-printable) bytes from the firmware but that's it.

I managed to flash GRBL on to my Uno yesterday but ran into a problem when I was attempting to test it against my stepper drivers.

GRBL seems to freeze partway through the the init prompt, it goes as far as "Type '$' to dump c" and then stops and won't accept any commands. Occasionally if I reset the Uno it or unplug and re-plug the USB enough times I can get it to give me the full prompt at which point it will accept commands seemingly indefinitely but this is in the minority of cases.

I thought perhaps it was maybe a limitation of the Arduino IDE serial monitor so I decided to try it using Minicom instead but I got the exact same results.

I've read through Issue #8 which seems to be a similar issue but I believe the baud rate issue was corrected after that occured. I maye give it a try anyway when I get home. I also haven't tried 0.8a yet but I might give that a try as well.

I'm currently running Linux Mint 9 x64 (Ubuntu 10.04), an Arduino Uno DIP and the 1.0 IDE with grbl_0_7d_atmega328p_16mhz_9600.hex flashed to it.

like the previous versions will there be compiled versions available for download? I am not too handy with a compiler yet, but I was able to get version .6 loaded previously due to the easy upload. Is this going to be a possibility?

Grbl v0.8 and v0.7d both have G92 coordinate offset support to help define a part zero that can be difficult to locate when grbl always just resets to [0,0,0]. I have been looking into and pondering whether or not to add the standard G54 coordinate systems.

We can do just about everything we need to with G92, but my friend Machinist Mike did not agree. After debating with him, he was absolutely adamant that G54 work coordinate system should be used instead of the current G92 implementation. His argument was based on that G92 is not a complete industry standard and may vary slightly from machine to machine. G54 is a defacto standard and used on all CAM systems. He stated that G92 is used very infrequently in industry because it can complicate programs and isn't 100% portable to different machines.

So, the question is: Should we drop G92 in favor of G54? Or should we add G54 or possibly more work coordinate systems and keep G92 as legacy support? Does anyone use G92? (I know I have several times.)

G54 shouldn't too difficult to add, since I have already written in the needed functions last week. I could likely finish it this weekend.

This is not really an issue but a question: did you ever try to run the floating point calculations in float instead of double? 7 significant decimals may be precise enough. I though I ask you before trying it myself.
Cheers, Jens

Looking for some advice,

Should I be using a different compiler, uploader. What are you using? Does it require some other sort of base firmware on the hardware that is different then what comes with Arduino Mega.

I have programmers notepad [WinAVR] to look at code but that does not seem to do compiling and loading to hardware.

So, I am currently copying Grbl code into Arduino software and then loading it into my Arduino Mega hardware and running it. I am having to disable certain lines of code though in order to get it running. It seems Arduino comes with the wiring.h file. It seems to conflict with: #include "wiring_serial.h" , beginSerial etc... functions. I am hacking around to see if I can disable it.

I think I may also have some other adjustments to make since I am running on the the ATMega1280. I think your code is geared to the ATMega168. This I think I can figure out though. Just some different tags related to serial.

Recently we have been playing with the grblShield and have noticed that G21 has unpredictable results. For instance if I am drawing a circle and use G20 (mm). Everything works as expected. When I change this to inches grbl goes a bit nuts and does not just draw a larger circle (which is what I expect it should do).

Try it out.

Riley

I seem to be struggling with and/or finding a few issues as I walk through this. every now and again, I issue a $x=YYY command and it it says that it stored the information, but then I give it a g command and it does something strange... I go back and check the constants by giving a $ command and it spits back numbers that are junk, usually negative. If I set everything back to normal again it seems to be fine, but it's somewhat annoying. It seems to be inconsistant and I haven't figured out what causes it.

Hi,
I was just testing the code but had troubles using homing function. I think there is a typo error in: https://github.com/simen/grbl/blob/edge/limits.c.
In line 59,63 and 67 "LIMIT_PIN" should be replaced with "limit_bits". Or it will never execute the switch release code.
i.e.
if (x_axis && !(LIMIT_PIN & (1<<X_LIMIT_BIT))) {
should be changed to:
if (x_axis && !(limit_bits & (1<<X_LIMIT_BIT))) {
.

Anyway thanks for the great project, take care.

Bekir

Not a big issue saw this while looking through the code. When sending a "G4 P10" grbl does not schedule a pause in the stepper interrupt but blocks the serial/gcode processing it seems. Not sure this is intended behavior.

I ran into a problem with the acceleration code. All the acceleration phases work fine but on deceleration I get unnaturally long ends. Basically the motion decelerates and right before it should stop or transition into the next motion it just keeps on moving very slowly.

It's rather setting dependent but generally seems to occur when the motion settings are pretty smooth. With jerky settings everything seems to be fine.

• using the grbl 0.7 code base
• running at pretty high feed rates, like 2500-20000
• only happens when I lower the acceleration setting to under 1500

There are som many mails I don't get to answer these days. Issues I don't have time to deal with. Please bear with me. We recently bought our first house, and between getting ready to move into the new home and selling our flat there is no spare time. Grbl development is on hiatus until some time in june.

I'm trying to compile grbl (using avr-gcc 4.5.3 and avr-libc 1.7.1) but when I try to make the files from the repositories, I always get this error. It happens on every version of grbl.

avr-gcc -Wall -Os -DF_CPU=16000000 -mmcu=atmega328p -I. -ffunction-sections -c motion_control.c -o motion_control.o
In file included from motion_control.c:26:0:
/usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h: In function ‘mc_dwell’:
/usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h:153:28: error: __builtin_avr_delay_cycles expects an integer constant.
make: *** [motion_control.o] Error 1

Any suggestions?

Unlike all the other settings, it seems like I have to reset my arduino before new feed rate or seek rate settings are applied. This is using the current edge branch on an Adafruit Boardiuno with an atmega328.

Hi,
Do you have some advice on this?
With an Arduino Duamilenove 328 with grbl_0_6b_atmega328p_16mhz_9600.hex uploaded manual g-code entry works very well (using arduino serial monitor).
When I run "stream.rb g-codefiel" it stops after some lines (using terminal on osx 10.5). It's pretty difficult to find the problem. Any ideas?

Thanks a million for creating and maintaining grbl in your freetime. It's some fantastically written code.

I'd like to know if you will be adding any new features in the near future and have some feature requests.

I have had the luxury of working at a research lab with a professional machine shop with excellent machinists. I had asked the head machinist, what he expects in terms of a basic interface at our 5-axis Haas, or what he regularly uses. Here's a list of the key items that grbl doesn't seem to directly feature and all have to do with proofing the g-code at the machine.

• Adjust all feedrates to 5%, 25%, 50%, or 100%. Or slow-motion mode. Would be fairly simple to implement with low-overhead by multiplying a scalar to any feedrate command internally.
• Single block mode. Runs one block of g-code until a next command is received, i.e. a using an Arduino I/O pin with a switch.
• Distance to go on current block and current location. He stated that this is probably the most important feature he uses most frequently. This is mainly to keep an eye on where the tool is traveling to, real-time. For example, to make sure that the tool is not going to crash into a vice or table, damaging something. I am not sure how to implement this into grbl easily and efficiently. grbl would have to either receive a query of the state and transmit, which is not optimal, or periodically broadcast its state with a code of some kind via pins with shift register, analog pin voltage levels for percent finished, or something else.

Thanks again and I wish you all in Norway the best with recent tragedy.

Is there anyone who achieves more than 40KHz step frequency of GRBL Atmega328p ?
I have executed several tests changing microstep level and seekrate of each axis.

The fastest one I have succeeded in is 38.4Hkz for each axis.
If I adjust parameters to get faster speed, then interrupt handler routines went wrong.
So the pulses in my osciloscope shows broken steps.
Also the EEPROM data area is broken to show incorrect values. But it shows correctly after reseting Atmega328p board.

This isn't an issue, but I don't know how else to post on this site. I am using the edge branch code to develop an open source controller specifically meant for CNC laser users. I built a buildlog 2.X laser (www.buildlog.net) and am using this for control as it has almost everything I need. That said, I am adding features and configuration options that are needed for lasers and that would generally make the code easier to use with a variety of stepper driver configurations. The first thing I did was add a configuration option that sets the steper enable pin to Enable=high, sleep; Enable=high, no sleep; Enable=low, sleep; Enable=low, no sleep. I also wrote two small functions that set the enable on/off state as well as the motor trigger interrupt based on those options. This was necessary because certain drivers need a high or low to enable the steppers (case in point: the GRBL sheild needs a low while the buildlog laser needs a high). It is also not always advantageous to put the motors to sleep inbetween gcode sets as somebody can move them and the controller wouldn't know about it.

My next task is to add an M-code to put the motors to sleep or wake them up. Laser users will want that as there are times when we want to roughly position the laser by hand and then lock the motors, set zero, and start.

I want to move the code from a 328p system to the Mega as I don't have enough IO for everythign I want to do. I also want to develop this into a 4 and 5 axis system eventually.

My ultimate goal is to feed this with another arduino reading code from a SD card and interfacing with my computer

Basically, I want to put this code out there for others to get and use as they see fit, but I don't know how.

I am going to add G92 to my version of grbl. I do not think grbl currently has another way to zero positions. Currently I am cycling power to my Arduino to get things to zero current position. In my python app I have a zero button that I will use to send G92 code. Ex. G92 X0
http://github.com/Highlander01/Highlander01HMI

M3 and M5 commands are executed immediately when received. This turns off the spindle even if there are moves left.

I am doing a different python interface then your ruby interface. Should I be doing some handshaking with code on the Arduino. How many lines can I send at a time? Should I wait for code on the Arduino to write back "ok" before I send a next line. I am going to play with it some but if you can give me a head start that would be great. Should code on arduino store up a bunch of gcode lines before starting execution.

(My python interface is a little further along. I made it so that it can draw G02 arc gcode in python/opengl. Not the heart of the system but nice shiny surface stuff.)