New Continuous Filament Mixer by AnHardt · Pull Request #12098 · MarlinFirmware/Marlin

AnHardt · 2018-10-15T15:47:56Z

This implements a replacement for the old filament mixer.

The old mixer has several problems. Especially when the segments are short or better only contain a few e-steps, like they are often seen on printers with move subdivision (Delta). Neither the amount of produced e-steps, nor the mix is correct.

The old mixer sets up Bresenham-'directions' for each of the mixing steppers. In this rounding errors occur. In short segments this errors are relative big - up to a amount the result is unusable. Because the 'errors' are the same for all sub segments of a move a line is drawn consistently wrong. Even without rounding errors the 'pressure' in the nozzle is not well distribute in time, when the fractions of the mix are equal. If the relation is 1/1 ether both of the mixing steppers step at the same time, or both don't step.

The new mixer uses the 'normal' e-steps, but selects one of the mixing steppers for each of the e-steps. The mixer does not know about lines or segments, it just selects the next stepper to be as close as possible to the selected mix.

I made some tests with old and new mixer.
I used this config to test with just a Mega and a logic-analyser.
The used g-code, the RH-logs, the produced logic-files and a benchmark program to test the algorithm can be found together with some screen shots in the archive. The .logicdata files can be opened with http://downloads.saleae.com/logic/1.2.18/Logic+Setup+1.2.18.exe.

Implementation

Found some already patched problems with the mixer.
Renamed active_extruder to active_extruder_b and active_extruder_s to make the variable distinguishable in 'block' and 'stepper'. (Many other different active_extruders remain at other places.)
Draw a clean line between parsing the related g-codes (in the parser) and their implementations in 'mixer'.
Made an object from the mixer.
Moved all mixer related code into the mixer-object. Including the definition and use of data stored in 'block' and 'stepper' (Macros). Mixer does not have any 'global' data now.
Most of the methods are just to make data available to the rest of the world. They are tiny and can be inlined.
The central method is get_next_stepper(void) either called from the stepper-interrupt or from the LA-interrupt (if that exists). The mixer should work now together with LA.

Usage

M163 uses an float array to collect the fractions for each of the mixing extruders. This means the user can specify the relation in whatever 'system' he likes. It could add to 1 [0.25, 0.75], in % [25, 75], in whole numbers [1, 3] or any other convenient system.
This collector is normalized and committed to a virtual extruder by M164. The normalization does not affect the contents of the collector. This enables the user to use sequences like M163 S0 P1 \n M163 S1 P0 \n M164 S0 \n M163 S1 P1 \n M164 S1 \n M163 S1 P2 \n M164 S2, where the value for the first mixing extruder not has to be repeated.
M164 commits to the specified, or if omitted to the active, virtual extruder.
M165 collects the channel information in the M163-collector and normalizes and commits always to the active virtual tool.
Mixing information inline with G1 is intermediately stored in the collector, then normalized and committed to the active virtual tool.
That means, M165 and inline mixing information do alter the M163-collector. This should not be a problem as long the user consistently uses one of the systems, or does not trust in setting only one of the factors with M163.
Normalizing is done so that the biggest fraction is scaled to 0x80 for 8bit processors, or 0x8000 on the other ones. The different scaling is just and only done for speed reasons. A possible relation of 128/1 seems to be sufficient. The molten material inside the nozzle acts as a lowpass-filter. But when the sequence to represent a color becomes to long [0x8000, 0x8000, 1] it becomes likely the filter is not strong enough and we see the low fraction component pulsing (varying its visibility).

Further ideas

Tested whether adding some more randomness in the algorithm could avoid visible patterns in the output. It could, but the additional cost for computation is too high. If the lowpass does its work well it's useless.
Tested how to integrate a different steps/mm for the mixing steppers could be integrated. Its possible, but the amount of needed changes is huge. Maybe another day.
Running the algorithm backwards to avoid missing rarely-stepping components in retracts, is also much slower than I'd like to implement.

ejtagle · 2018-10-16T02:00:54Z

This is great work @AnHardt !!

Roxy-3D · 2018-10-16T02:06:19Z

Agreed! I need to get a mixing extruder!

thinkyhead · 2018-10-16T07:46:03Z

Marlin/src/module/planner.h

Is there any chance this could be something other than mixer_color_t b_color[MIXING_STEPPERS] ?

I had variantes where only the tool index was stored. But then the mix could be altered while the block is already cued or running.

I wanted to have all mixer internals inside mixer. What information is stored in the block for the mixer is quite uninteresting to other parts of the code.

thinkyhead · 2018-10-16T07:53:16Z

Overall this looks really good. I've made my usual tweaks to spacing and fixed a couple of things.

I'm going to do a rebase and see if this is up to date with the current branch. I think I noticed one or two things that might conflict, and I will follow up if I have any questions.

After the rebase, please grab the latest version of the branch with:

git fetch origin
git checkout NewColor_Mixer_V04
git reset --hard origin/NewColor_Mixer_V04

thinkyhead · 2018-10-16T08:10:59Z

The rebase produced no conflicts. Everything looks good.

One change I made was to rename active_extruder_b to just extruder for planner blocks, as this is always prefaced by some_block->, and shouldn't be conflated with the global active_extruder. And then active_extruder_s can just be called stepper_extruder for the same reason. (And who knows, maybe active_extruder will be called active_tool_index in the future.)

I see there were some questions in the comments. Do these still need clarification?

// If Linear Advance is disabled, then the loop also handles them
#if DISABLED(LIN_ADVANCE) && ENABLED(MIXING_EXTRUDER) // ToDo: ???
  // HELP ME: What is what?
  // Directions are set up for MIXING_STEPPERS - like before.
  // Finding the right stepper may last up to MIXING_STEPPERS loops in get_next_stepper().
  //   These loops are a bit faster than advancing a bresenham counter.
  // Always only one e-stepper is stepped.
  #define ISR_START_MIXING_STEPPER_CYCLES ((MIXING_STEPPERS) * (ISR_START_STEPPER_CYCLES))
  #define ISR_MIXING_STEPPER_CYCLES ((MIXING_STEPPERS) * (ISR_STEPPER_CYCLES))
#else
  #define ISR_START_MIXING_STEPPER_CYCLES 0UL
  #define ISR_MIXING_STEPPER_CYCLES  0UL
#endif

Apologies to my UK friends.

thinkyhead · 2018-10-16T08:33:29Z

I need to get a mixing extruder!

I'm looking forward to installing this on my new Geeeeeeeetech A10M. (Sadly it only has 2 extruders.)

AnHardt · 2018-10-16T13:18:39Z

I see there were some questions in the comments. Do these still need clarification?

Indeed i'm still not entirely sure if a modification is required.
But because ISR_STEPPER_CYCLES and ISR_START_STEPPER_CYCLES describe worst case scenarios and i'm quite sure to be not slower than the original mixer, it's likely this can stay as it is.
Are ISR_STEPPER_CYCLES and ISR_START_STEPPER_CYCLES counted, guessed, measured? From where to where? I have no clue about that.

If there is no e-step in a iteration of the ISR no time for searing the next stepper is used now. So in average the new mixer is much faster than the old one, when 'E' isn't the leading axis.

ejtagle · 2018-10-16T17:57:24Z

@AnHardt : The ISR_STEPPER_CYCLES and ISR_START_STEPPER_CYCLES were deduced after disassembly of the ISR, but don´t worry, as your approach should be as fast as the original code.

Besides, this is -again- in my todo list: Ensure proper timing on the ISR, as we already had some issues with DRV8xxx drivers... I will probably simplify the logic to ensure proper timing...

tcm0116 · 2018-10-17T01:56:13Z

Marlin/src/module/planner.cpp

  float current_speed[NUM_AXIS], speed_factor = 1.0f; // factor <1 decreases speed
  LOOP_XYZE(i) {
-    #if ENABLED(MIXING_EXTRUDER)
+    #if ENABLED(MIXING_EXTRUDER) && ENABLED(RETRACT_SYNC_MIXING)


The purpose of this section was to limit the maximum velocity of a single stepper to the maximum as specified by the configuration, instead of limiting the velocity as a function of the total delta if the E movement. This was applied for all movements, not just retract movements.

I'm also concerned that delta_mm_i = delta_mm[i] / MIXING_STEPPERS will have unintended side effects since the planner now thinks that the speed of the extruder movement is now lower than it actually is.

I think this should be reverted to a more generic algorithm as it was prior to this change.

How is the max velocity of a e-stepper determined?
Usually you try to extrude faster and faster until the stepper skips. How fast it can go is determined by the moment of the stepper at a speed and its 'resistance' at that speed. The 'resistance' is mainly the 'pressure' in the nozzle. Pressure is determined by the nozzles inner shape (diameter) and the viscosity of the material, what mainly depends on its temperature (nonlinear). Temperature depends mainly on the amount of material per time and the total power of the heater.
If you have more than one e-stepper feeding a nozzle they have to share the heater. It's impossible to extrude a MIXINGSTEPPERS times bigger amount of material.
Except when first retracting and then unretracting the same amount of material.

Limiting velocity to the amount that one stepper can push alone seems to be, at least, safe.

I'm also concerned that delta_mm_i = delta_mm[i] / MIXING_STEPPERS will have unintended side effects since the planner now thinks that the speed of the extruder movement is now lower than it actually is.

Isn't that exactly what you wanted? The virtual tool for the autoretraction moves exactly the same amount of filament on all mixing steppers. So each of the mixing steppers has to move 1/MIXING_STEPPERS - and speed calculation is based on that. Isn't that the same as limiting to the fastest extruder?

However.
Calculating a speed factor for every block is uneconomic. We could now do it once, when a new mix is stored in a virtual tool (normalizing) and stor it in a new float variable. That could be applied here.

Could look like AnHardt@3280a60
UNTESTED !!!

It's impossible to extrude a MIXINGSTEPPERS times bigger amount of material.
Except when first retracting and then unretracting the same amount of material.

Good point and great explanation.

Isn't that exactly what you wanted?

Yes. I just wasn't following the change correctly.

Could look like AnHardt/Marlin@3280a60

Based on your explanation above, I don't think this is necessary.

We could do it. But it would require an other method for finding the maximum possible speed. We'd have to run all mixing-steppers at once and at the same speed to find the maximum speed. Due to more power because of the multiple steppers we could get more pressure/flow - not MIXING_STEPPERS times more, but a bit. Then the sum of steps/time should be limited to that && no stepper should exceed it's individual max speed. (Not nice to calculate)

tcm0116 · 2018-10-17T01:57:55Z

Marlin/src/module/stepper.h


 // If linear advance is disabled, then the loop also handles them
-#if DISABLED(LIN_ADVANCE) && ENABLED(MIXING_EXTRUDER)
+#if DISABLED(LIN_ADVANCE) && ENABLED(MIXING_EXTRUDER) // ToDo: ???


Should we resolve these TODOs?

Seems like the comments here can be removed now.

tcm0116 · 2018-10-17T02:00:36Z

Marlin/src/module/tool_change.cpp

 void tool_change(const uint8_t tmp_extruder, const float fr_mm_s/*=0.0*/, bool no_move/*=false*/) {
-  planner.synchronize();
+  #if DISABLED(MIXING_EXTRUDER)
+    planner.synchronize();


Wouldn't we still want the synchronize to occur for mixing extruders? By removing the synchronize, the new mix might be applied to segments that have been queued, but not yet executed.

No. The used mix for the blocks are copied into the block when it's populated. Not just the index - but the complete information.

Sounds fair

e-Mole · 2018-11-02T23:09:55Z

Great work! Will be "New Continuous Filament Mixer" in version 1.1.9?

thinkyhead · 2018-11-03T06:23:25Z

Version 1.1.9 is fixed and immutable. There will be no more 1.1.x releases. All future development will be to version 2.0.x only.

e-Mole · 2018-11-03T10:28:43Z

In 1.1.9 is still problem with mixing. For example mixing in decimal numbers like M165 A0.25 B0.75 not working - extruders practicaly stop moving after this gcode (this decimal values are widely used in tools for using mixing extruder - gradient mixers etc.), in my delta printer works only integer like M165 A3 B5. It seems the problem is in normaliser... (I use the latest bugfix version.)

tcm0116 · 2018-11-03T11:06:56Z

@e-Mole - we'd suggest moving to 2.0 to have access to the latest features and fixes.

e-Mole · 2018-11-03T17:11:41Z

@tcm0116 - Good advice, but it would be nice to have a functional version 1.1.x :-).

tcm0116 · 2018-11-03T20:52:15Z

At some point, we have to draw a line in the sand and stop doing active development on both versions. 1.1.9 was that line. 2.0 supports all that 1.1.9 does, plus support for 32-bit systems, and is also receiving bug fixes. If 1.1.9 doesn't work for your application, try 2.0. If 2.0 doesn't work, submit an issue and hopefully someone will fix it.

e-Mole · 2018-11-03T21:35:12Z

@tcm0116 - Of course, but it's work with reconfiguration and other code modifications ... and testing, testing, testing ... and I'm ... lazy :-)). But Marlin 2.x is a "challenge" :-) Thanks for comments!

e-Mole · 2018-11-04T19:27:25Z

The transition to 2.x is not yet very successful. A few observations on delta printer (Arduino MEGA + RAMPS 1.4, CYCLOPS mixing extruder - 2 steppers, 2 runout mechanical sensors):

"New Continuous Filament Mixer" is a big step forward, mixing is much better than in version 1.1.9
the filament sensors now behaves in reverse as in 1.1.9 (trigger vs open state, it looks like a error, but I did not find it, maybe around FIL_RUNOUT_INVERT_MASK)
on prints are strangely shifted layers, it does not matter at the print speed (perhaps the problem of A. MEGA in combination with delta printer, but in version 1.1.9 it works, my setting: DELTA_SEGMENTS_PER_SECOND 100, SW endstops disabled, S_CURVE_ACCELERATION disabled, JUNCTION_DEVIATION disabled)
It looks like a shift occurs in non-print fast moves (independent if mixing or single color print).

thinkyhead · 2018-11-05T02:38:22Z

That's interesting. Check your configuration and make sure that ENDSTOPS_ALWAYS_ON_DEFAULT is disabled.

thinkyhead · 2018-11-05T08:25:03Z

I've patched Marlin to make sure the endstops are turned off after probing, so you should now be able to do G29 or Z homing with a probe immediately before printing without issue.

e-Mole · 2018-11-05T08:38:20Z

@thinkyhead - Thanks! ENDSTOPS_ALWAYS_ON_DEFAULT is disabled (my config is attached in message above)

thinkyhead · 2018-11-05T08:38:52Z

☝️

e-Mole · 2018-11-05T19:18:51Z

It works! No problem 150 mm/s; higher speeds are already "crounching", 200 mm/s get completely stucking. This is very similar to version 1.1.9. In earlier versions (1.1.6 and earlier), we could print even faster, but we did not actually use them. With the same settings (FW + slicer), the print time is about 20% longer in 2.x (1.1.9), print quality is subjectively the same. Perhaps the impact of different acceleration and jitter processing?
New mixing is realy great - no problem with short segments, no problem with a ratio like A0.11 and B0.89!
I have encountered problems with the G33. There is no problem with G29 (deploy and stow - z probe allen key). G33 is ok in deploy but not stow. (yes, this and next is a separate topic).
After G29 z-probe stow, final position is 0,0,150 (Z_PROBE_ALLEN_KEY_STOW_4_xx in my setup), then is running strange movement that leads to the same position as the probe deploy second coordinate (Z_PROBE_ALLEN_KEY_DEPLOY_2_xx)... I could not find in code why.
After calling printing pause (from printer menu), the filament change is started. Maybe I configured pause wrong, but I did not find solution.
and last - some test objects from mixing

:-)

tcm0116 · 2018-11-05T19:21:40Z

@e-Mole what mixing hotend are you using?

e-Mole · 2018-11-05T19:23:21Z

@tcm0116 E3D Cyclops "clone" and Diamond "clone". This picture is from Cyclops prints (PLA, heatbreaks with PTFE inserts, bowden lenght 630 mm, retraction 10 mm, retraction speed 60-90 mm/s, slicer Kisslicer 1.6).

e-Mole · 2018-11-05T22:19:18Z

@thinkyhead - Does the disable/enable software enstops in configuration significant impact on performance on delta printer? I am a teacher and with delta-robot we also draws with pen (or engraving with Proxxon) and there sometimes happens that the gcode generated from Inkscape is not correctly positioned (pupils make a mistakes :-)). SW endstops are then suited. My idea is: enable SW endstops in configuration.h and then on 3D printing disable SW endstops using M211 S0 in gcode prefix. But what about performace - theoretically?

AnHardt · 2018-11-05T23:30:30Z

Actually the soft endstops for DELTAs aren't that bad.
We clip against a circle. Normally the calculation would use a square root, what would cause a lot of sweat on the AVRs forehead - sqrt(x^2 + y^2) < r. But we calculate - x^2 + y^2 < r^2 , where r^2 is a precalculated constant.
Also clipping is done per (G0/G1/...) move, not per DELTA-segment.

Try it!

e-Mole · 2018-11-05T23:48:56Z

@AnHardt - Does this mean that after using M211 S0 the calculation is not performed?

AnHardt · 2018-11-05T23:59:04Z

Yes.

e-Mole · 2018-11-06T00:03:17Z

@AnHardt - Thanks! I'm going to test it... :-)

thinkyhead · 2018-11-06T02:34:47Z

I'm glad to hear it's back to normal, mostly.

There aren't too many differences between the planner in 1.1.9 and 2.0.x so I'm surprised that you would see a 20% difference in print time. It might just come down to changes in the way some settings are applied. If you see big discrepancies between expected and actual print speeds then we might want to follow that up. One thing that did get major improvement is filament-mixing, so maybe that is having some effect on speeds.

I'm not sure what's going on with the probe stow in G33, as we haven't touched the delta calibration code in a long while. File a separate issue if it keeps being a problem.

We haven't touched Allen Key probe code in a while either, so I'm not sure what's up with the strange movement. I suggest filing a separate issue about that too, so more contributors will see it.

The pause print stuff is all pretty new, and there have been a lot of hands in it, so the fact that it's acting up and going to filament change instead of just doing a pause-and-resume is not entirely surprising. Again, it would be best to file a separate issue about that too so we have it as a task. I'll take a quick look through that now to see if it's something obvious.

thinkyhead · 2018-11-06T02:53:32Z

I just checked the pause code, and I see there's a change I made recently to have it do the common wait routine if there was a pause from host printing. Even though it gives the impression that it's waiting for filament reload, it's actually just waiting for a click and keeping the heaters from being left on too long. But it doesn't print appropriate messages, so it gives the impression that filament change is happening. I believe all I have to do to fix it is change the messages it's putting up.

e-Mole · 2018-11-06T10:15:03Z

@thinkyhead
Perhaps I wrote it wrong:

There aren't too many differences between the planner in 1.1.9 and 2.0.x so I'm surprised that you would see a 20% difference in print time.

Yes, between 1.1.9 and 2.0.x is no difference, but 1.1.6 and earlier are in total printing time faster (20-25 %).

e-Mole · 2018-11-06T12:12:20Z

@thinkyhead - my strange printing pause (from LCD menu) behavior:

1. head is going to park position - o.k.
1. on LCD is now message about changing filament - wrong (but message only)
1. after enter (click) - screen with continue or purge option - o.k.
1. after continue (click) - head is going to last print position and will stand - wrong (why not continue printing now?)
1. on LCD is Info screen now - o.k.
1. it is necessary to enter menu (click) and select Resume - wrong (why confirm second time?)
1. after confirmation then print continue...

thinkyhead · 2018-11-07T02:34:46Z

Ok, yeah. That's all quite odd! Let me review the process and I'll make a patch to skip all those extra steps.

thinkyhead · 2018-11-07T02:59:09Z

@e-Mole — Ok, give the latest bugfix-2.0.x a run. It should be better!

In reference to #12098 (comment)

e-Mole · 2018-11-11T18:04:57Z

@thinkyhead - I have tried the last bugfix-2.0.x and the pause is still the same.

thinkyhead · 2018-11-11T18:19:44Z

Printing from host or from SD?

e-Mole · 2018-11-11T18:21:01Z

From SD

e-Mole · 2018-11-11T19:30:52Z

Has the mixer code changed in the last 7 days? I think mixing is no longer so smooth.

thinkyhead · 2018-11-12T08:20:32Z

No, mixing code itself has not been touched for a while. You can use the BLAME option when viewing stepper.cpp on the GitHub web interface to follow the history of any set of lines, to see who modified that section of the code last and what they did. I am using it now to review changes, and I see nothing unusual so far.

https://github.com/MarlinFirmware/Marlin/blame/bugfix-2.0.x/Marlin/src/module/stepper.cpp

e-Mole · 2018-11-12T22:26:09Z

Thank you! I will look at it....

e-Mole · 2018-11-14T16:10:44Z

My "strange printing pause" - possible same as issue #12411

* Synchronize on M204, M205 (MarlinFirmware#12302) * Add parser.seen for multiple parameters * Fix M666, use !seen for report * Synchronize on M204, M205 * Ignore ARM-based Teensy library on ATUSB90-based Teensy (MarlinFirmware#12311) Works around PIO src_filter behavior (see platformio/platformio-core#1905) * Tweak / reduce menu items * IS_DELTA => ENABLED(DELTA) * Clear up HAS_WORKSPACE_OFFSET meaning * Revive SCARA's home offset (unimplemented) * Use first_page flag in place of page.page == 0 * Apply #pragma once, misc cleanup (MarlinFirmware#12322) * Apply #pragma once in headers * Adjust some thermistors formatting * Misc cleanup and formatting * Fix broken LPC176x build (MarlinFirmware#12317) * Fix broken LPC176x build * Add UBL+HD44780 test for LPC1768 * Return to status to show manual deploy/stow messages (MarlinFirmware#12324) * Add servos to pins_FYSTEC_F6_13.h * Remove dead comment * Fix VMAX editing Fix MarlinFirmware#12326 * Use board-specific or platform SPI pins in HAL_STM32 (MarlinFirmware#12323) * Suppress some compile warnings * Fix EEPROM servo angles init, section grouping * Drop 'register' storage specifier * Provide DOGLCD SPI pins for MKS SBASE + VIKI * Update Italian language (MarlinFirmware#12327) * Allow disable of LCD_TIMEOUT_TO_STATUS (when 0) * Clean up some U8G files * Clean up file endings * Turn PlatformIO LDF off for LPC176x builds (MarlinFirmware#12334) * Update, correct sanity-checks for up to 6 extruders (MarlinFirmware#12333) * Extend error messages for E factors sanity-checks * ENABLED(NEWPANEL) => HAS_LCD_MENU * MSG_UBL_EDIT_MESH_MENU => MSG_EDIT_MESH * Add a mesh edit menu for MBL / ABL-Bilinear * Add MESH_EDIT_MENU to example configs * Cleanups for leveling-related code * M420 support in MARLIN_DEV_MODE * Fix endstops enable behavior during probing Fix a bug introduced in MarlinFirmware#9582 * Recommend keeping endstops off * Fix 'M43 T' to use 'L' as last pin - The documentation is correct. The code was wrong. * Provide a default for Z_PROBE_LOW_POINT * Use multiplier edit item for mesh point editing * Update and fix CHDK * Clean up ENCODER_RATE_MULTIPLIER config * G28 O respects HOME_AFTER_DEACTIVATE Addressing MarlinFirmware#11271 * Prevent current step-down going negative Addressing MarlinFirmware#11348 * Fix "circle" * Fix MBL XY parameter error messages Fix MarlinFirmware#11522 * Updated slovak translation (MarlinFirmware#12338) * Update German language (MarlinFirmware#12336) * Hide mesh editing until a valid mesh exists * Restore LPC1768_PIN_INTERRUPT_M, apply to Z3 - In reference to MarlinFirmware#12166 * Clean up bq Zum Mega 3D pins * Remove trailing whitespace * Add Geeetech Rostock 301 config, update GTM32 Pro VB pins (MarlinFirmware#12345) * Update Italian language (MarlinFirmware#12344) * Change Marlin debug flag names to fix conflicts (MarlinFirmware#12340) In reference to MarlinFirmware#11000 * LCD menu code refactoring and cleanup (MarlinFirmware#12308) * Show the appropriate pause message (MarlinFirmware#12348) * Fixed advanced pause messages (MarlinFirmware#12353) * Apply some tool-change cleanup * More advanced pause tweaks (MarlinFirmware#12356) * Followup to LCD_TIMEOUT_TO_STATUS=0 * Make continuous purge screen fit 20x4 * Unify purge message modes * Preserve last-set pause header mode * Update German translation (MarlinFirmware#12355) * Update Slovak translation (MarlinFirmware#12354) * Update Italian language (MarlinFirmware#12352) * Fix const pointer assignment compile error (MarlinFirmware#12350) * Use IS_SD_PRINTING() more * Use card.stopSDPrint() for completeness * Fix Resume from SD Pause In reference to MarlinFirmware#12098 (comment) * Restore GTM32_PRO_VB temp and heater pins Undo MarlinFirmware#12345 * Set CUSTOM_MACHINE_NAME for some configs * Combine more tool-change variables (MarlinFirmware#12137) * Fix up xdiff, ydiff, zdiff in tool change Followup to MarlinFirmware#12137 * Clean trailing whitespace * Apply HAS_LCD_MENU in EEPROM code * Remove obsolete comments * Extend pins errors to include the processor * More comprehensive NO_LCD_MENUS (MarlinFirmware#12367) * No error on T0 with single-extruder and fix MIXING_EXTRUDER virtual tools (MarlinFirmware#12375) * Update Slovak translation (MarlinFirmware#12376) * Update Italian language (MarlinFirmware#12368) * [2.0.x] Macro G-codes (MarlinFirmware#9365) * Fix M91x sanity-check to permit TMC2660 Fix MarlinFirmware#12362 * Solve endstops issues (MarlinFirmware#12382) - Partially reverts MarlinFirmware#11900 and tries to solve MarlinFirmware#12336 * Update German language (MarlinFirmware#12379) * Have 'mfdoc' open the local site when it's ready * Add reference comments to MeshLevelingState * Break out of 'mfpub' if 'gh-pages' checkout fails * Use 'serial_spaces' in 'print_2d_array' * Tweak 'echo_not_entered' used by MBL's G29 * Tevo Little Monster example configuration (MarlinFirmware#12370) * Allow G26 to use the active extruder (MarlinFirmware#12387) * Make lcd_quick_feedback argument optional * Add click_to_cancel option to wait_for_hotend/bed * Have G26 use the active nozzle and wait_for_hotend/bed * Use wait_for_release in UBL G29 * Add 'T' parameter to G26 for an initial tool-change * Update Raptor config * Update HAL and libs formatting * Reduce code size with plain inlines * Apply extra condition to LCD_PROGRESS_BAR * Adjust some comment spacing * Encapsulate common display code in a singleton (MarlinFirmware#12395) * Encapsulate common LCD code in a singleton * Depend more UBL code on UBL_DEVEL_DEBUGGING - Since most users don't need the debugging on at all times, this helps reduce the default build size for UBL by over 2K, a little closer to fitting on 128K boards. * Clean up LCD width/height determination * For now (!) don't synchronize in M204 and M205 See if this has any deleterious effect on motion planning by slicers that inser their own jerk and acceleration controls. The problem I see is that these settings can take effect on blocks already in the planner, and the only way around this would be to shadow these settings in planner blocks and use the shadowed settings in the planner. * Update UBL comments for debug change * Differentiate translated On/Off from Serial ON/OFF * Fix BABYSTEP_ZPROBE_OFFSET (MarlinFirmware#12408) Fix MarlinFirmware#12399 Did not compile without `WATCH_HOTENDS || WATCH_THE_BED`. Add condition to include "../../module/temperature.h". * Clear old _site contents on regeneration * Followup to 50af1d1 * Add M412 to enable/disable filament runout detection (MarlinFirmware#12406) * Clean TLM trailing whitespace * Group status methods, share reset_status with Extensible UI (MarlinFirmware#12414) * Group status methods, share reset_status with Extensible UI * Move common DOGM code to headers * Refine endstops fixes (MarlinFirmware#12413) When endstops/probe are enabled `ENDSTOP_NOISE_THRESHOLD` calls to `update` are required to properly re-sync endstops/probe status. * Fix tool-change for MIXING_EXTRUDER with < 2 virtual tools (MarlinFirmware#12417) Fix MarlinFirmware#12416 Better handling of `ENABLED(MIXING_EXTRUDER) && !MIXING_VIRTUAL_TOOLS > 1` - to not fall through to the general case. Fix compiler warnings for `#elif EXTRUDERS < 2`. * Debug of G2-G3 for UBL (MarlinFirmware#12386) Changes only affect UBL. Everything else is left alone. * Updates to Formbot T-Rex 2+ configuration files (MarlinFirmware#12422) Updates to Formbot T-Rex 2+ configuration files * Endstops fix followup (MarlinFirmware#12423) Followup to MarlinFirmware#12413 * Add required "cardreader.h" include (MarlinFirmware#12419) * Update Portuguese-Brazilian translation (MarlinFirmware#12402) * Fix Formbot Trex-2+ configs Followup to MarlinFirmware#12422 * Clean up pins files * UltiMachine Archim 1 support (MarlinFirmware#12404) * Fix an old sanity check * hasstatus => has_status * Move RRW keypad code to a common method (MarlinFirmware#12429) * Rejigger Filament Runout class (MarlinFirmware#12428) * Miscellaneous LCD code renaming, reordering (MarlinFirmware#12430) * Move special characters to language.h * Apply some naming standards * Clean up menu item draw functions * Rename some Temperature methods * UI => ExtUI * Fix to runout sensor code. (MarlinFirmware#12431) - "old_state" is no longer a class static variable. * Optimize target_extruder, ignore T with mixing (MarlinFirmware#12432) * Optimize target_extruder, ignore T with mixing * Give G-code Tn parity with tool_change * Fix GcodeSuite::T active_extruder reference * Tweak extruder errors * No need for Cap:PAREN_COMMENTS * Support two MAX6675 thermocouples (MarlinFirmware#8686) * Optimize Power-Loss Recovery (MarlinFirmware#12440) * Consolidate, optimize some LCD menu code (MarlinFirmware#12450) * Make CardReader class static (MarlinFirmware#12451) * Make CardReader a static class * Make CardReader flags into bitfields * Use 'target_extruder' in M104 as with M109 (MarlinFirmware#12448) * Enable SD Card on RepRap Display and RADDS (MarlinFirmware#12446) * Enable SD Card on RepRap Display and RADDS Define the necessary pins in `pins_RADDS.h` (copied from the `RADDS_DISPLAY` section) for the use of the SD card slot on RRD. * Fix a compile warning (MarlinFirmware#12452) * Allow float XY probe offsets Responding to MarlinFirmware#12383 XY probe offsets should be integers because adding decimal points makes the code larger. But if decimals are very much wanted, this commit removes the old restriction. * Followup to static CardReader * Change temperature pin order for RemRam V1 (MarlinFirmware#12458) Beta testers suggested to adopt the RAMPS order of temperature probe connectors. This commit fixes the order to the RAMPS order. * Fix compile error with SD_FIRMWARE_UPDATE (MarlinFirmware#12462) * Fix compile error with ZONESTAR_LCD+NO_LCD_MENUS (MarlinFirmware#12466) * Don't start watching heaters when target is 0 (MarlinFirmware#12453) * Various fixes for MarlinUI and ExtUI (MarlinFirmware#12439) * Remove extra include * Fix MAX_MESSAGE_LENGTH * Fix access to the DWT peripheral for STM32 HAL (MarlinFirmware#12434) Access to the DWT peripheral for the `CYCCNT` register needs to happen before `main()`. The code needs to be called after the setup of the system clocks, so the right place is between the `premain()` and `main()` function of the STM32 Arduino core. This patch moves the DWT access code to a new function, which is then placed between `premain()` and `main()`. * Fix "no effect" and "unused variable" compile warnings (MarlinFirmware#12473) * Update M303.cpp (MarlinFirmware#12471) * Fixed displaying of kill MSG_OUTAGE_RECOVERY string. (MarlinFirmware#12470) * GTM32 Pro VB changes from Markku Sinisalo * Combine Travis CI option-setting commands (MarlinFirmware#12474) * Fix LCD compile error, etc. (MarlinFirmware#12472) * Clean up some u8g code (MarlinFirmware#12476) * Get u8g reference for lcdprint * Modify MBL to use IJ instead of XY (MarlinFirmware#12478) * Corrected unused var, default switch, Travis tests (MarlinFirmware#12477) * Fix compilation errors. Followup to MarlinFirmware#12439 (MarlinFirmware#12481) * Fix for MarlinFirmware#12482 (MarlinFirmware#12483) Fix Z-move to uninitialized position in SWITCHING_EXTRUDERS tool_change (no_move=true) * Revert MarlinFirmware#12311 PIO LDF work-around (MarlinFirmware#12484) * Followup to MarlinFirmware#12451 * Apply/unapply const here and there * Shift YZ on graphical display to fit Z+123.45 * Don't show updir with no card present * Expanded options for _Statusscreen.h (MarlinFirmware#12455) See the PR for full details. The updated system will be documented on the website in the near future. * Revert some const changes (for now) * Fix ADC_KEYPAD middle button (MarlinFirmware#12493) * Invert hotend bitmaps, by default * General cleanup of Re-ARM pins * Fix problems with LPC1768 EEPROM flash emulation (MarlinFirmware#12503) * Remove duplicate calls to PrepareSector Some flash memory API calls require that a call to `PrepareSector` is done before use. However this call is already made by the LPC1768 framework so the calls in this code are not required. * Ensure correct alignment of RAM buffer The LPC176X flash API requires that the RAM buffer used for write operations must be word-aligned. This change ensures that this is the case. * Additional pin definitions for Archim 2 (MarlinFirmware#12500) - Added GPIO pins to Archim 2 - Added new 108 pin to `fastio_Due.h` * Use superscript 3 in language_en.h (MarlinFirmware#12504) * Fix a minor compile warning * Revert ADC_KEYPAD direction behavior (MarlinFirmware#12508) * Remove extra declarations in cardreader.cpp (MarlinFirmware#12520) * Fast PWM for controller fan (MarlinFirmware#12485) * Bring superscripts slightly lower in BDF fonts * Clean up font data generation script * Don't show superscript ³ with NOT_EXTENDED_ISO10646_1_5X7 (MarlinFirmware#12513) * Fix backslash in language_test.h * Use wait_for_bed with WAIT_FOR_BED_HEATER Addressing MarlinFirmware#12517 * Allow Serial Overrun Protection to be disabled * Hide some compile warnings * Put status screen options in Configuration_adv.h * Update Italian language (MarlinFirmware#12512) * NUM_ARRAY => COUNT * Update Turkish language (MarlinFirmware#12524) * Correct FANMUX2_PIN (MarlinFirmware#12538) * Update Slovak translation (MarlinFirmware#12523) * Fix wait_for_bed compile error * Add support for FYSETC F6 V1.3 board (MarlinFirmware#12527) * Fix English special symbols (MarlinFirmware#12529) * Adjust Formbot Raptor pins * Add missing boards to Makefile * Add Formbot Raptor2 and Raise3D pins (MarlinFirmware#12532) * Add Formbot Raptor2 board * Add Raise3D Rumba board * Add sample config for Delta with MKS SBASE (MarlinFirmware#10819) * Hide M217 compile warning * Improve runout sensor, fix LIGHTWEIGHT_UI screen size (MarlinFirmware#12544) * Save recovery info on SD pause * Space out multiple edit lines a bit * Fix runout debug output Followup to MarlinFirmware#12544 * Add poll_runout_states, which returns 1 for runouts (MarlinFirmware#12547) * Add heating progress bars (MarlinFirmware#12543) * Followup to heating progress * Fans loop macro * Fix "paused" message and M125 called by M25 (MarlinFirmware#12551) * Fix Skew factors (MarlinFirmware#12555) - Ensure Skew factors are calculated from test square measurements * Fix "No SD Card" indicator * Tweak FR icon. Update font data. * A single SERIAL_ECHO macro type (MarlinFirmware#12557) * Fix angles for disabled EDITABLE_SERVO_ANGLES (MarlinFirmware#12559) * Move stepper enable/disable to stepper_indirection.h (MarlinFirmware#12562) * Tweaks to endstops code * Remove AVR-only MARLIN_DEV_MODE code * Fix pause/resume SD print Followup to MarlinFirmware#12551, addressing MarlinFirmware#12566 * Alternative fan image option (MarlinFirmware#12579) * Alternative fan bitmap * Move bed over by 3px * Print a space after scrolling status * Don't include STM32 Core code when compiling STM32 Generic (MarlinFirmware#12575) * Build and CI fixes and optimizations (MarlinFirmware#12584) -Disable LDF "deep+" mode on AT90USB platforms. Appears not needed any longer (likely due to fix platformio/platformio-core@7322df2). Results in identical binary output and cuts compile time in half -Disable Cartesio config from CircleCI (compile failure) -Disable Geetech I3 Pro X GT2560 from CircleCI (compile failure) -Enable EEPROM on Micromake example config (fix compile failure) -Move FolgerTech/i3-2020 to AVR platform in CircleCI (fix CirculeCI build failure) -Disable various examples failing to build in CircleCI -Enable various examples no longer failing to build in CircleCI * Fix up some delta settings * Update mfpub * Trinamic: Split stealthChop, improve driver monitoring, etc. (MarlinFirmware#12582) * Signal an invalid mesh for M420 enable / load * Tweak config formatting * Link to font docs in ultralcd_DOGM.cpp * Sanity-check for negative steps, feedrate, accel * M425 Backlash Correction (MarlinFirmware#11061) * Add Z_MIN_PROBE_PIN to MKS SBASE pins * Refresh screen on SD Init * Followup to servo angles patch Fix MarlinFirmware#12594 * Simpler AVR + Trinamic + Soft Serial sanity-check (MarlinFirmware#12606) * Fix some serial echos of pin states * Center ABL grid on bed with H parameter. (MarlinFirmware#12610) * Align classic bed icon consistently * Improve some config comments readability (MarlinFirmware#12615) * Fix broken pins file include (MarlinFirmware#12617) * TMC connection test, spreadCycle parameters, improved debugging (MarlinFirmware#12616) * Sanity-check LIGHTWEIGHT_UI, move comment up (MarlinFirmware#12630) * Allow ExtUI to use LCD_SET_PROGRESS_MANUALLY (MarlinFirmware#12628) * Add spreadCycle parameter sets (MarlinFirmware#12645) * [2.0.x] G33 clean up (MarlinFirmware#12648) Remove obsolete workarounds in G33 for the now fixed zprobe_zoffset bug * [2.0.x] Enable PIDTEMPBED in Anet A8 example config (MarlinFirmware#12655) * [2.0.x] Set DEFAULT_NOMINAL_FILAMENT_DIA to 1.75 in Anet A6 config (MarlinFirmware#12664) * [2.0.x] Update Czech translation (MarlinFirmware#12683) * Squelch warning mentioned in MarlinFirmware#11061 (MarlinFirmware#12676) * [2.0.x] Limit PID autotune target to maxtemp-15 (MarlinFirmware#12691) * Limit set hotend temperature to maxtemp. (MarlinFirmware#12690) * Added MKS MINI 12864 support to FYSETC F6 V1.3 (MarlinFirmware#12656) * FYSETC F6 13 - E2_SERIAL_TX_PIN correction (MarlinFirmware#12667) * Followup to MarlinFirmware#12691 (typo) * GTM32 Pro VB FAN-PIN correction (MarlinFirmware#12666) * Add Formbot 350c Thermistor (MarlinFirmware#12661) * Add support for MKS Robin board (MarlinFirmware#12650) Implement initial support for MKS Robin (STM32F103ZET6) board. Custom build script is used to generate encrypted firmware compatible with original MSK Robin bootloader (i.e. safe firmware update from SD card and possibility to go back to original close-source firmware). * Wanhao Duplicator i3 Plus pins create (MarlinFirmware#12701) * Update Formbot T-Rex 3 pins (MarlinFirmware#12662)

thinkyhead changed the title ~~New Continuos Filament Mixer~~ New Continuous Filament Mixer Oct 16, 2018

thinkyhead added the PR: Improvement label Oct 16, 2018

thinkyhead reviewed Oct 16, 2018

View reviewed changes

AnHardt and others added 4 commits October 16, 2018 02:53

New Continuous Filament Mixer

80c73dc

Misc. tweaks and fixes

c915716

Derive color mask from data size

ae18e84

active_extruder_b => extruder

ba29ed5

thinkyhead force-pushed the NewColor_Mixer_V04 branch from b0f887a to ba29ed5 Compare October 16, 2018 08:05

active_extruder_s => stepper_extruder

cebb8d4

American spelling of "normalize"

8f31a8d

Apologies to my UK friends.

thinkyhead merged commit f56968b into MarlinFirmware:bugfix-2.0.x Oct 16, 2018

AnHardt deleted the NewColor_Mixer_V04 branch October 16, 2018 09:37

p3p mentioned this pull request Oct 16, 2018

E0 no longer works #12116

Closed

tcm0116 reviewed Oct 17, 2018

View reviewed changes

AnHardt mentioned this pull request Oct 31, 2018

[bugfix-2.0.x] MKS SBASE halt on E movement after M164 #12278

Closed

thinkyhead added a commit that referenced this pull request Nov 7, 2018

Fix Resume from SD Pause

812f6a7

In reference to #12098 (comment)

thinkyhead mentioned this pull request Nov 15, 2018

Various fixes for MarlinUI and ExtUI #12439

Merged

AnHardt mentioned this pull request Aug 28, 2019

[FR] Mixing Extruder with differing steppers #8145

Open

Uh oh!

Conversation

AnHardt commented Oct 15, 2018 • edited by thinkyhead Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Implementation

Usage

Further ideas

Uh oh!

ejtagle commented Oct 16, 2018

Uh oh!

Roxy-3D commented Oct 16, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thinkyhead commented Oct 16, 2018

Uh oh!

thinkyhead commented Oct 16, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thinkyhead commented Oct 16, 2018

Uh oh!

AnHardt commented Oct 16, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ejtagle commented Oct 16, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnHardt Oct 17, 2018 • edited by thinkyhead Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnHardt Oct 17, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnHardt Oct 17, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnHardt Oct 17, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

e-Mole commented Nov 2, 2018

Uh oh!

thinkyhead commented Nov 3, 2018

Uh oh!

e-Mole commented Nov 3, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tcm0116 commented Nov 3, 2018

Uh oh!

e-Mole commented Nov 3, 2018

Uh oh!

tcm0116 commented Nov 3, 2018 • edited by thinkyhead Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

e-Mole commented Nov 3, 2018

Uh oh!

e-Mole commented Nov 4, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

AnHardt commented Oct 15, 2018 •

edited by thinkyhead

Loading

thinkyhead commented Oct 16, 2018 •

edited

Loading

AnHardt commented Oct 16, 2018 •

edited

Loading

AnHardt Oct 17, 2018 •

edited by thinkyhead

Loading

AnHardt Oct 17, 2018 •

edited

Loading

AnHardt Oct 17, 2018 •

edited

Loading

AnHardt Oct 17, 2018 •

edited

Loading

e-Mole commented Nov 3, 2018 •

edited

Loading

tcm0116 commented Nov 3, 2018 •

edited by thinkyhead

Loading

e-Mole commented Nov 4, 2018 •

edited

Loading

e-Mole commented Nov 5, 2018 •

edited

Loading

e-Mole commented Nov 5, 2018 •

edited

Loading

e-Mole commented Nov 5, 2018 •

edited

Loading

AnHardt commented Nov 5, 2018 •

edited

Loading

e-Mole commented Nov 6, 2018 •

edited

Loading

e-Mole commented Nov 6, 2018 •

edited

Loading

thinkyhead commented Nov 12, 2018 •

edited

Loading