Exclude speed ranges (beta release)

[TheSlashEffect]

Hello, fellow 3D printing people

I have implemented the first version of the feature requested in #4105. This version allows the slicer to detect speeds for external perimeters and overhang perimeters which fall into user specified excluded speed ranges, and adjust them according to one of the following options in the dropdown menu:

• Lowest: drop the speed to the lowest value of the range.
• Highest: raise the speed to the highest value of the range.
• Nearest: change the speed to whichever value of the above is closest to the speed set.

Since this is the first version, the only speeds checked are the ones entered by the user in the "speed" section. Those are

• Speeds that are set explicitly in the form of mm/s
• Speeds that are set implicitly, as a percentage of another speed.

The minimum layer time feature is applied after this feature takes place, and still works as it should. The next version of this feature will work alongside the minimum layer time. I am working on another project in parallel and have really under-powered equipment at the moment, so I would need about a week to start working on the next version.
Now that the GUI and backend frameworks are in place, the changes would be minimal for the next version. I mostly know what needs to be done already. I hope the code is clean enough, I also made the initialization only run once per slice to avoid parsing the input all the time.

An open question for the readers since I cannot print at the moment:

• If we have "bad" speeds for the internal perimeters but "good" ones for the outer ones, do the artifacts come to the surface? Changing where this feature takes place is a matter of one line so do let me know and I can change it.

The user can enter as many ranges as they wish, and the order of said ranges matters not. The ranges' format is checked, as well as their correctness. The second bound must be higher than the first bound, and the ranges must not overlap. An error is displayed on each case, with an example shown below.

My apologies in advance if anything is out of place, my current equipment is too dodgy to allow me to get any more work done at the moment.

[RURon]

Great work! One thing that comes to my mind after looking at this: Could other print moves be included as well? Maybe for an advanced version this might be user configurable or a drop down like "only adjust external perimeters / all perimeters / only infill / all print moves"?

[TheSlashEffect]

Thanks a lot. Yes we can apply this to other moves as well. It’s up to us users to decide where this would be beneficial.

[TheSlashEffect]

Just for reference, the full version of this, with minimum layer time taking into account this filter, is being worked on. Not much left but it took some time because I had to rewrite some existing stuff due to technical reasons.

[RURon]

Great work, thank you for the effort, looking forward to test it!

[supermerill]

cosmetic change:
change the exclude_print_speed_ranges to coFloats (ConfigOptionFloats) with a default with two values.
then on the gui, you should be able to modify by :

		setting:label$Min:id$0:exclude_print_speed_ranges
        setting:label$Max:id$1:exclude_print_speed_ranges

now you don't need the split_user_input_ranges_to_individual_strings, just get the first and second value (after verifying they exists)

[supermerill]

Yes, I think also it should be applied to all moves.

What is your strategy for the minimum layer time? As it's a post-processing, i guess if it slow something down into the forbidden band, it slow it down to the min?

[TheSlashEffect]

Hey Meril.
I just happened to have finished the minimum layer time integration today. I’ll send you the branch with a short explanation when I get back home shortly.

[TheSlashEffect]

Alright. Here is the diff, branch is this one.

I rewrote the cooling algorithm. Modifying the existing one does not make sense as it hardly extendable and not easy to maintain at all.

The new algorithm (NewCoolingBuffer) treats all lines as a collection. It sums their length and calculates the speed they ALL should have in order to reach the minimum layer time. That's what the existing one does as well.
The main difference in mine is that we then check if this speed falls in an illegal range, adjusts it according to the "adjustment direction", and corrects all non-external perimeter lines' speeds to get as close as possible to the minimum layer time (thus decreasing print times). It does not go above their existing speed, obviously.

If we want to apply the filter in more extrusion types we have to rewrite the algorithm, but that's not too difficult due to my code structure. We have to touch but one function. With a day of thinking I can go through some ideas I had on this. But my idea for now was to do shorter releases to get feedback from users and developers. External perimeters only could be one such release.

Alternatively, we can apply a stupid easy filter after the original algorithm. This would work for all extrusion types with ~10 lines of effort. Check revision b449e6e which does just that.

Working examples.

• Minimum layer time: 15 seconds
• Original external perimeter speed: 20mm/s
• Exclude range: 4-20mm/s
  Adjustment option is "Highest" for 1st pic, "Lowest" for 2nd
  Notice the external perimeter speed following the adjustment direction, and all other extrusions being adjusted separately.
  

Ignore the 14seconds, that's a rounding issue.

Notes:

• The algorithm is not computationally perfect; A more complex algorithm can be written but is complex, ugly, and doesn't give too many benefits. In my opinion, we shouldn't have too many layers where slowdown is enabled. Instead we should as always fill the buildplate with more parts.

[supermerill]

I'll look this week-end.

Alright. Here is the diff, branch is this one.

note: if you move/update your branchchka.master.exclude-velocity, the new commit will be showed here.

[TheSlashEffect]

cosmetic change:
change the exclude_print_speed_ranges to coFloats (ConfigOptionFloats) with a default with two values.
then on the gui, you should be able to modify by :

From what I see by implementing this, it assumes a single exclusion range, no? Except if I'm missing something. I made this support multiple excluded ranges on purpose, because our vibration graphs can look like this:

There's more than one regions to exclude, my printer's graphs also had more than one regions I want to exclude.

[TheSlashEffect]

note: if you move/update your branchchka.master.exclude-velocity, the new commit will be showed here.

I'm not doing that yet because we might decide to not include those changes, so I'm keeping this branch clean. I will squash those commits anyways, that was my original plan. Let me know what you think about the new algorithm.