Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extrude Length Preprocessing #491

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

k1-801
Copy link
Contributor

@k1-801 k1-801 commented Oct 30, 2024

WORK IN PROGRESS

Currently has syntax errors. Working on it.

This change aims to provide a basis for Endless Spool functionality improvement.
It scans each block of GCode between toolchanges and records the total length of filament used within each block. This data is then attached to the MMU_CHANGE_TOOL macro (in the EXTRUDE_LENGTH=... parameter).

Additionally, this change removes buffering of GCode lines between the toolchange macro and the next G1 move. This potentially can reduce RAM consumption. This is achieved by recording the file position after the Tx macro and then rewinding the file stream to that point.

@k1-801 k1-801 force-pushed the extrude_length_preprocessing branch 15 times, most recently from 356b550 to 10fdba9 Compare October 31, 2024 08:20
@k1-801 k1-801 force-pushed the extrude_length_preprocessing branch from 10fdba9 to c20568b Compare October 31, 2024 08:51
@moggieuk
Copy link
Owner

This is an interesting idea. What kind of overhead does it add to the parsing? I persuaded the moonraker crew to accept my PR for specifying the timeout of the pre-processing step so at least we can bump that up.

Can you give me the use case of how and when you would use this or is this a precursor to something else?

@k1-801
Copy link
Contributor Author

k1-801 commented Oct 31, 2024

This is an interesting idea. What kind of overhead does it add to the parsing?

The parsing is currently pretty slow =
But I'm working on it, I know what is taking the longest and I have a few ideas that could help avoid it.

Can you give me the use case of how and when you would use this or is this a precursor to something else?

This is indeed a precursor to the Endless Spool feature upgrade. The idea was described in my comment in #340 (comment), but in short - the plan is to check whether it's reasonable to continue printing after a runout detection without unloading the remaining bit of plastic.
If we continue printing, it will no longer be possible to extract the bit through the MMU, and, thus, it will have to be either fully used up in the print, or it will have to be purged through the nozzle. So we need to know, how much we need before the toolchange, and we compare it to how much we have left (bowden_length). The way I see it, this parsing change is the only way to know how much more plastic we need.

@k1-801
Copy link
Contributor Author

k1-801 commented Nov 1, 2024

persuaded the moonraker crew to accept my PR for specifying the timeout of the pre-processing step so at least we can bump that up.

I don't think long preprocessing is a good idea in general. I'd look into optimizing it instead.
For example, the placeholders for "MMU_START_SETUP" (!referenced_tools! etc.) - those don't have to be substituted in every line, so substituting them everywhere may be a bad idea. I'd say, a good marker that we no longer need to look for those placeholders is extruding moves, as we definitely don't expect a setup macro AFTER the printer starts printing.
So, if at least one extruding move was found, I suggest we stop looking for those placeholders.
Additionally, I think checking the first letter of the line to be T or G before running REGEXes may save us a LOT of time.
Finally, I believe the parameters being passed to some functions waste a lot of time copying containers, so making a single class to hold some of the pre-processing-related stuff may save even more time. I can look into all these within this same PR.

@k1-801 k1-801 force-pushed the extrude_length_preprocessing branch from 88ad403 to 64926d4 Compare November 1, 2024 20:20
@k1-801 k1-801 force-pushed the extrude_length_preprocessing branch from 64926d4 to ac715c0 Compare November 1, 2024 20:21
@k1-801
Copy link
Contributor Author

k1-801 commented Nov 1, 2024

Made the MMU-related parsing into it's own class. Hid some of the parameters into object attributes. This should reduce some overhead.

@moggieuk
Copy link
Owner

moggieuk commented Nov 2, 2024

Any performance optimization of current parsing would definitely be appreciated but it is actually quite fast. Once a placeholder is found it won't look in subsequent lines, but the logic parses to the end of file to do the NEXT_POS insertions. I see you changing the approach slightly. It would be interesting to see the orig/new parsing performance numbers if you have any..

JFYI I'm not going to be able to spend time looking at this for some time (i know it is still in development). The reason is that I'm really busy getting type-B MMU support polished (in the v3alpha branch)

[if you do look at the v3alpha branch you will see a lot of code/class breakout - no changes on the moonraker side though]

@moggieuk
Copy link
Owner

moggieuk commented Nov 5, 2024

@k1-801 I've been thinking about this and have an idea for you...
The approach you are taking is certainly an option but what about thinking about it another way (this assumes a extruder entry sensor):

  • When a runout occurs, HH notes that it is a point of no return (cannot toolchange).
  • It then continues to print without worrying about the g-code ahead of time.

To things can happen:
A) No toolchanges occur...

  • When a runout occurs at the extruder sensor, HH pauses the print
  • Some gocde will still be in the print queue so the filament will end past the extruder sensor and that extruder movement would have to be measured.
  • Ok. Now we are paused. The filament is at a point beyond the extruder entry... Happy Hare initiates a endless spool toolchange and load right up to the old filament. We can home to the extruder sensor and move the extra amount.
  • Continue printing (must be synced) without break OR jump to a post load purge to get past the little "air gap"

B) A toolchange occurs.

  • At that point we have no choice but to conduct a huge purge to get the filament to the extruder sensor. Then load the new filament type/color and continue purging until extruder is flushed.

The manipulation of the tool change is not really any different to your approach but it saves having to pre-process the gcode ahead of time...

@k1-801
Copy link
Contributor Author

k1-801 commented Nov 9, 2024

The approach you are taking is certainly an option but what about thinking about it another way (this assumes a extruder entry sensor):

In the absence of preprocessing, be it disabled or just had it failed, AND with the presence of an extruder entry sensor, this is certainly how this would work. However, there are plenty of machines that don't have an extruder entry sensor, so without preprocessing there isn't much we could do.

Furthermore, there are instances where it woud be wasteful to go on with the print after a runout trigger on MMU, as it would lead to a purge of a whole meter of filament - it would be much better to eject it (if possible), change the spool and maybe use the ejected bit the next time this tool is requested.

I think we are going to need a flowchart :)

@moggieuk
Copy link
Owner

moggieuk commented Nov 11, 2024

Flowchart, ha ha. Yes it is a complex challenge. The statement above "it would be much better to eject it (if possible), change the spool and maybe use the ejected bit the next time this tool is requested." can't work though ... if you are past the point of no return you cannot eject (because the filament cannot be grabbed be the MMU gear stepper) thus you can either continue as far as possible and if the remaining filament is beyond a user defined threshold, say 300mm, then PAUSE and wait for user interaction. else do the very long purge. You can't eject a filament that is too short...

@k1-801
Copy link
Contributor Author

k1-801 commented Nov 11, 2024

because the filament cannot be grabbed be the MMU gear stepper

But there is some more filament between the extruder gears and the nozzle, I always assumed that unloading from the extruder makes the filament reach the MMU gears again. This assumption, however, also heavily relies on the MMU sensor to gears distance being significantly shorter than extruder gears to nozzle distance...

UPD: as well as on the runout response time being short enough

If these conditions are not met, then a runout is indeed a point of no return, and our only options are to continue printing, purge, or request manual intervention.

@k1-801
Copy link
Contributor Author

k1-801 commented Nov 13, 2024

if you are past the point of no return you cannot eject

This gave me another thought. What if we used the pre-gate sensor, when available? That would notify the system about a runout in advance, thus, allowing to run checks earlier

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

Successfully merging this pull request may close these issues.

2 participants