[grbl PR#39] Edge

#1 – simen 于 2011-08-16

Ah, nice! Code looks solid and I like that superflous characters are discarded earlier in the pipeline. I’ll have a go as soon as possible. Can you provide some examples from the test files you have used? I’m especially interested in the support for ‘)’. I always thought comments had to trail the command. Do we actually need to support in-line comments followed by command words? I would never have expected that – but then again have I never seen a lot of real world G-code files.

#2 – chamnit 于 2011-08-17

I just sent you a test gcode file I’ve been using. It has a few things that are not supported by grbl, but are mostly machine specific (Haas 5-axis, ‘O’ commands). You may have to trim some things here and there to get it work for you, but I gave you the complete version. It follows the inner and outer perimeter of a circle, followed by a square, going clock-wise and counter-clockwise for each perimeter. My friend is pretty interested in this project and is willing to feed you some other proofing g-code programs, if you’d like.

Also, he uses the Nxx line numbers as a searchable location for the beginning of separate operations in a program, which are followed by comments describing what it is. He states that this come in very handy if you have very long programs and need to locate and edit a block quickly for things that a CAM system may have problems with or is quicker to do by hand. He apparently doesn’t line number everything anymore, since it takes up storage space on the controllers.

As for ‘)’, all comments should be closed by ‘)’ and you should be able to write g-code commands immediately afterwards. According to my machinist friend, this is not used very often in practice, but everyone has a different style in making their programs readable.

#3 – chamnit 于 2011-09-03

Simen: Not sure if you had been following the conversation in your ‘forums’ with Alden, Jens, and I. I believe we have come up with a robust solution for handling jerk in the planner. Jens stated he found that the maxjerk parameter gave pretty good results but would run into problems if running an arc too big or too small. This is due to the way the maxjerk parameter is a linear approximation of the centripetal acceleration about a junction. I had come up with an efficient method without any sine/cosine computations to robustly compute this. Please try out the code and let me know how it goes.

If you run into any ‘jerkiness’ when running, just increase the settings.junction_deviation parameter. It works well for me at 0.1mm with a 25mm/sec^2 acceleration.

#4 – chamnit 于 2011-09-07

Planner has been optimized and running significantly better. (It would run your implementation of arcs just fine in most cases. It would just stall when entering a junction between two arcs because it would data-starve when calculating all the initial arc computations of the next arc motion.) So, I had re-written the arc motion function to be significantly faster as well. It uses a transformation matrix approach and corrects for numerical drift exactly. It runs without any problems on my machine. Let me know if you have a chance to look at it.

#5 – chamnit 于 2011-09-27

Simen. Fixed the long slope at the end of deceleration, along with many other issues. I machined the diamond-circle-square test block to proof my CNC. Tolerances were below 0.001″ and the surface finish was excellent, meaning grbl is running without any hitches and smoothly. Alden Hart has been testing the code on his machines and has reported that the code is also working very well at high speeds, especially with the braid gcode. Not sure where you are in grbl’s development or how much time you have these days, but please let me know. I’m planning on continuing where you have left off and help develop grbl to a v1.0 status.