Mixing Hotend Custom G-Code -> ! Internal error on command:"G1"

General Discussion
1

Hello! I have what started as a Geeetech A30-T. This printer uses a 3-to-1 mixing hotend. As such, filament changes and mixtures can be made by modifying the feed rate for each of the 3 extruders. I converted my printer to Klipper and discovered that this feature was not supported.

Mixing is ordiarily achieved through a series of gcode commands that looks like this:

M163 S0 P99.8 ; GCMM ADDED LINE - Mod=2 Height=0.32
M163 S1 P0.2 ; GCMM ADDED LINE - Mod=2 Height=0.32
M163 S2 P0 ; GCMM ADDED LINE - Mod=2 Height=0.32
M164 S0 ; GCMM ADDED LINE - Mod=2 Height=0.32

However, my attempts to implement this have functioned inconsistenly. Whether it is a M163 replacement or a custom Klipper macro, I get a !! Internal error on command:"G1" and the printer shuts down. However, this problem does not occur consistently. Here is my macro:

[gcode_macro SET_MIX] # SET_MIX MIX_0= MIX_1= MIX_2=
gcode:
  {% set def_rotation = printer.configfile.config.extruder.rotation_distance|float %}
  {% set mix_sum = params.MIX_0|float + params.MIX_1|float + params.MIX_2|float + 0.000000001 %}
  {% set mix_ext0 = (params.MIX_0|float / mix_sum) + 0.000000001 %}
  {% set mix_ext1 = (params.MIX_1|float / mix_sum) + 0.000000001 %}
  {% set mix_ext2 = (params.MIX_2|float / mix_sum) + 0.000000001 %}
  SET_EXTRUDER_ROTATION_DISTANCE EXTRUDER=extruder DISTANCE={def_rotation / mix_ext0}
  SET_EXTRUDER_ROTATION_DISTANCE EXTRUDER=extruder1 DISTANCE={def_rotation / mix_ext1}
  SET_EXTRUDER_ROTATION_DISTANCE EXTRUDER=extruder2 DISTANCE={def_rotation / mix_ext2}

I have tested several ideas for why it fails:

  1. Divide by zero. I ruled this out because Klipper throws a distinct error for div by zero, and the code has lower limits for division.
  2. Too many commands between movements. I ruled this out by spamming the button dozens of times while the input was blocked, resulting in them executing all at once. The printer is not interrupted by this.
  3. Specific values cause the failure. I have tried numerous different variables for each extruder,
  4. Something about how the code is being sliced is affecting the macro. I ruled this out by manually issuing both macro commands, and raw SET_EXTRUDER_ROTATION_DISTANCE commands.

As I do not know how to interpret the log file, my best hypothesis is that the SET_EXTRUDER_ROTATION_DISTANCE command is not intended to be modified at runtime, and this is creating an error in the movement queue. If this is the case, I do not have a good workaround.

I would appreciate any insight on what is happening in the klippy log, or on other approaches to this problem. Thank you.
(I have uploaded the klippy log, and the mixed gcode is produced by https://gcodemixmaster.com/)
klippy(4).log (6.1 MB)

2

There is no log attached.
Never done this but I guess some sort of extruder sync is needed:

ACTIVATE_EXTRUDER EXTRUDER=extruder
SYNC_EXTRUDER_MOTION EXTRUDER=extruder1 MOTION_QUEUE=extruder

Not directly related but you may want to check:

3

Hi there. Apologies for no log. The post had to be approved and was locked up until this morning.

When I initially began thinking about this I found the links you posted. These were useful for understanding some of the starting parameters, but because they deal with non-mixing hotends, they don’t have to do any fractional mixing. They are binary and function by swapping which extruder is attached to the motion queue. To enable fractional mixing (like in Marlin), some method to divide the motion queue into fragments seems to be required.

4

I cannot test it but with these commands both extruder should be running in parallel. If you now go by and create a mixing ratio by using SET_EXTRUDER_ROTATION_DISTANCE it theoretically should work.

5

Yeah! That’s what I was thinking too, so I put all 3 extruders on the same motion queue at boot and it works great, until it randomly crashes when changing the mix during runtime.

6

Post a klippy.log from current version with no modifications, maybe a developer can take a look.

7

I have uploaded one log to the OP, and here’s another one where I issued the following commands:

set_mix MIX_0=1 MIX_1=2 MIX_2=1 # Sent this one 6 times before the print began
Note: No issue
set_mix MIX_0=0 MIX_1=2 MIX_2=0 # Sent once when printing skirt began
Note: No issue
set_mix MIX_0=2 MIX_1=2 MIX_2=2 # Sent after first layer
Note: Console shows rotation distance change back to starting values. Shutdown afterwards.
// Klipper state: Shutdown
!! Internal error on command:“G1”

klippy(1).log (1.7 MB)

Hopefully someone with more expertise can understand what is triggering the shutdown.

8

It looks like you’ve set an absurd rotation distance and that is probably confusing the code. For example, your log contains:

Extruder 'extruder2' rotation distance set to 7970000000.000000
Extruder 'extruder' rotation distance set to 7970000000.000000

I’m guessing you are doing this to avoid divide by zero errors, but I suspect it’s causing problems internally. If you need to disable an extruder stepper you should check for it explicitly and call SYNC_EXTRUDER_MOTION EXTRUDER=extruder2 MOTION_QUEUE=. You’ll also need to reassociate it with the motion queue when setting a non-zero value (eg, SYNC_EXTRUDER_MOTION EXTRUDER=extruder2 MOTION_QUEUE=extruder.

I’m not sure how many people have tried a mixing extruder with the latest Klipper code, so it’s possible you may run into issues. It’s also possible the Klipper support could be improved.

Cheers,
-Kevin

9

I considered that the high rotation distance might cause issues, but I thought since it let me set those distances and crashed inconsistently that something else was likely the issue. One of the easy crash scenarios is when I set all 3 of them extrude at the same rate at rotation distance 23 for each extruder.

It’s definitely something I could rule out with a quick test, just set the minimum to 1% instead of 0.00001%. Thanks for the suggestion. I’ll update the post with my results.

10

No dice! It still crashes in the same G1 move when setting rotation distances sub 1000, even when they’re all sub 100.

klippy(2).log (4.0 MB)

11

Can you post a test gcode file that causes this issue? I can try to see if I can reproduce the error locally.

-Kevin

12

Hi there. Sure, I couldn’t send it as .gcode so I just set it as .txt. This file will cause the mix macro to crash almost immediately. But, it also crashes when using the SET_MIX macro, and this crash is much less consistent.

mixcat - mixed.txt (460.3 KB)

13

Dear @MONSOONO
I’m looking for mixing function for Klipper too. Do you have any progress? Thanks.
Dat

14

I have the zonestar z9v5 pro mk4 with 4 to 1 mixing but trying to understand how to setup with klipper
While trying to keep the 16 color mixing options I get already

15

I’m also looking for mixing extruder support (along with a few others on separate platforms). After days of researching previous attempts/possible suggested solutions, I’m still at a loss. Are there any more updates on this issue?

16
1 Like
17

you’re welcome BTW. I’ve had zero crashes, just clogs because of the finicky M4V6 hotend, even Zonestar has trouble tuning them it seems.

In any case, @MONSOONO you should look at my code (what @kai linked). I do the floating point offset when setting the rotation distance and this works a lot better.

18

Hello nathan …

Would you say that klipper is the way to get a better Z9V5pro ?
I’m fully new to klipper , and do not have another (old) machine to test klipper

Note sure Zonestar provided a firmware for klipper , and not sure I saw it elsewhere

19

I haven’t definitively figured that out. The rotation distance on my bmgs are different on each one and I have yet to calabrate them