[grbl Issue#37] Additional features? About GRBL HAL

Issue #37 | 状态: 已关闭 | 作者: chamnit | 创建时间: 2011-07-30

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.

#1 – simen 于 2011-07-30

Thank you for your kind words! I want to keep Grbl as simple as possible and will generally resist changes that do not make Grbl simpler.

When it comes to adjusting feed rates there is an experimental branch where we added a real time control panel with a pause button and a potentiometer. In this version the potentiometer scales all feedrates live. It was fun and easy to implement, but not so useful. Now that Grbl has gotten a look ahead acceleration-planner I think implementing it as a live feture could get pretty hairy. I think this feature is better implemented in client software as a form of G-code preprocessor.

Single block mode: A good idea, but also better implemented on the PC side

Distance to go on current block + current location is a feature that definitely will be added. See issue #16 https://github.com/simen/grbl/issues/16

#2 – chamnit 于 2011-08-03

Agreed that the first two can be easily implemented into a preprocessor, although they would be relatively simple to integrate into grbl as well. I understand that you want to keep grbl as efficient and simple as possible, mainly to keep it from become a bloated mess. This answers my question of what you would be willing to add in the future, if I or someone else were to do some work on it.

I have some follow up questions:
– Do you have list of the critical features you will be or plan to be adding? So that someone could pick it up and generate some solution ideas on it?
– What’s your thoughts on how to implement the distance to go on current block and current location? Are you envisioning a user to build an external interface with a grbl arduino? Or through the serial port? Or as an LCD addon? Given how much cpu time the pulse trains use up and the limited memory space, I would imagine it would need to be very simple and with very low overhead.

#3 – simen 于 2011-08-03

I am not adding radical new features to Grbl at all, but some things are under consideration:
– A rotation axis
– A PCM output proportional to feed rate for use with laser cutters
– Status requests and progress feedback

Regarding status and distance to go on current block I plan to implement a character (?) that will spit out current block, current position, % complete and estimated time for the complete current block in seconds. This will be useful for humans, but even more so for client software. Personally I won’t add another arduino, because I prefer the pure text interface, but I hope someone will implement a nice client for Mac/Windows soon and I think there are several promising projects in progress.

#4 – jes1510 于 2012-02-09

Do you plan on adding backlash compensation in the future?

#5 – chamnit 于 2012-02-09

At some point, but not in the very near term. There are many ways to backlash compensation, and there doesn’t seem to be one right way to do it. The main problem with it comes from how do you ensure that the feedrate stays as high as possible without having to slow down nearly to a stop to perform a backlash move. In the grbl edge code, there is a place holder comment in motioncontrol.c/mcline() for backlash moves. If you need it immediately, you can try installing your own there. There’s plenty to do until v0.9, which it’s slated for.

原始Issue: https://github.com/grbl/grbl/issues/37

评论 (5)