Skip to content
This repository has been archived by the owner on Feb 8, 2024. It is now read-only.

Clean up GCode synchronization #186

Open
ThatWileyGuy opened this issue Mar 23, 2019 · 1 comment
Open

Clean up GCode synchronization #186

ThatWileyGuy opened this issue Mar 23, 2019 · 1 comment

Comments

@ThatWileyGuy
Copy link
Member

The buffered/unbuffered/async approach to gcode synchronization seems to work well enough in practice, but there's a lot of cruft left over from before it was implemented. I think a few things need to happen as cleanup:

  • make buffered/unbuffered/async into an enum instead of boolean flags
  • come up with a sane default for the GCode base class (probably buffered?)
  • clean up calls from gcodes directly to the path planner to wait for all paths to complete - most of these are unnecessary
  • decide whether we also need a notion of "blocking" and what that should look like

Blocking is interesting - enabling a fan is expected to wait for the path queue to reach a certain point but not stop the path planner while we turn on fan, whereas setting steps per mm needs to wait and block further movement until it completes.

@Wackerbarth
Copy link
Contributor

In general, I agree with the intent. However, I recommend that we reconsider the naming of these properties. What does "buffered" mean? (Buffered with respect to what?) Or, "async"? Surely there is a more descriptive terminology.

We can have separate classes for each behavior mode and rather than repeatedly providing definitions about the classification, use inheritance to provide the details to each specific gcode.

As such, there would be no "default" gcode base. Each gcode would be based on the class which has the appropriate behavior.

Additionally, by doing it by subclassing, the implementation details become significantly less important because they are now delegated to the behavior classes.

A good place to start would be to develop a list of behaviors with example commands (gcodes) that would belong to each behavior class.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants