Add look-ahead similar to grbl

[jbnimble]

Grbl has a "look-ahead planning buffer" feature that may be useful in planning the smooth acceleration/deceleration needed in cornering.

[BarbourSmith]

I agree with this. I think look ahead would also help with improving the execution time of lines of gcode. If the path is already planned from line to line then there is no processing delay between lines.

[CptanPanic]

So I was looking at grbl code, specifically planner.c which is related to what this issue describes. I wonder if this projects build environment is the same as grbl, so which planner.c would be able to be mostly used as-is, with only needing to add in the Maslow specific kinematics. Also the less we need to modify the grbl code, then we can easier utilize any updates that come upstream.

[davidelang]

with the grbl code as a base, we need to make two major changes

1. add the maslow kinematics

2. add support for DC motors/encoders instead of steppers.

These are both major changes, but they are in different parts of the code and can be tackled separately.

There is already intrest in the grbl community in supporting motors/encoders, so I would suggest that working in that area would be a good start as it's adding a feature that is useful for non-maslow systems

[CptanPanic]

So I floated the idea of adding support for motor/encoders to base grbl, and was shot down. So I guess that means that Maslow would need to have its own fork of grbl, or just incorporate the features of planning queue into current Firmware. If we do fork grbl, then we should take care and keep the Maslow stuff separate in order to still be able to being able to get updates from upstream. Any ideas?

[davidelang]

On Wed, 25 Apr 2018, CptanPanic wrote:

So I floated the idea of adding support for motor/encoders to base grbl, and was shot down.

I missed that discussion there, could you point me at it?

So I guess that means that Maslow would need to have its own fork of grbl, or just incorporate the features of planning queue into current Firmware. If we do fork grbl, then we should take care and keep the Maslow stuff separate in order to still be able to being able to get updates from upstream. Any ideas?

I think writing the code to add support for motor/encoders to grbl, even if we have to do so as a fork, is the right way to go. That way we can keep getting updates from upstream.

grbl is a very tight fit on an arduino now, so adding support for motor/encoders will not fit well. But they are working to get grbl to work on better/faster chips, and when they finally make a release with that support, I think they will be far more receptive to accepting a well written chunk of code to add motor/encoder support.

I'll contribute to a 'feature bounty' to pay someone for producing a good patch/fork that supports motor/encoders.

[CptanPanic]

https://github.com/gnea/grbl/issues/420

[CptanPanic]

Here is a cool bounty site: https://www.bountysource.com/

[c0depr1sm]

To get the Maslow firmware closer to GRBL, I think we need to clean it up to help trace the boundaries of the Maslow's specific functions. Anyway, cleaning-up increases readability and might help more contributors jump in. So I forked, started reviewing the code, changing labels and adding the improvements I see in the MaslowCNC master. We'll see where that goes...

[BarbourSmith]

Clean up is ALWAYS welcome 😍