Posts made by nanoplane

@deckingman
For me, I just split the task into two parts. no problem... The task I'm working on is a color cube that can act as a reference when selecting colors and mix ratios. It actually has 125 colors but I can easily change colors vertically within a single tool.

I've built a special version of SuperSlicer (based on PrusaSlicer) for this called SuperSlicerMx. it added built in support for mixing hot-ends while still maintaining the model of a "color" per extruder... but in this case a color can be a single color, a gradient or a set of layers.. so far it's been pretty effective. I'm also adding special purging / wiping functionality for mixing hot-ends to deal with back flow and "bubbles". Great fun..

I do wish that ReprapFirmware didn't have a fixed limit on the number of tools though.

They have responded to my issue in GitHub.. we'll see how it goes.

@deckingman

The whole thing works fine if I limit the number of tools I'm creating to < 19 :-).. but I was printing a color cube, which required 25 tools to be defined. If I split that up into two jobs, it all works fine...

If you create the tools one at a time using the console, the same failure happens, so it's not a print file thing...

@deckingman
Yes, I know about the retraction...
What I did miss was that setting retraction without a tool number applied to all of the tools...

In my case, it will always retract all filaments equally, but it might do it differently based on the current mix... not that that would be that useful :-)...

It would be much easier though if I had a single retraction update after all the tools have been created... I'll implement that..

Thanks.

Note that the problem I'm having doesn't seem to be related to the retraction updates... If I remove all of those commands, it still blows up..

Also, There appears to be corruption in the actual data when printing.. I'm not sure this would be a DWC issue since I think once it's transported the file, RRF takes over the actual printing, doesn't it? or could DWC be corrupting the RRF code base?

@phaedrux

A few more notes..
This is on an M3D Crane Quad. with a four port mixing hot end

@deckingman

So most of the tools I'm creating via GCode in my print file. I can send you a short version of that as well...

config.g tooltest.gcode

@phaedrux

Firmware version 3.2.2
DWC version 3.2.2

So, I've posted an issue on GitHub. When this happens, there appears to be some data corruption going on since I get weird effects. In particular, some of the filament drivers are running backwards... On a mixing hot end, this is just bad....

@o_lampe Yes, that was my expectation.. hence the surprise when things blow up. :-).

@owend
I get 50 as the limit

18 tools total seems to be the limit.

A note, everything works fine with at least 10 tools..

I am running a Duet Maestro and creating 25 "virtual" tools, all tied to the same heater/sensor. this is a mixing extruder and each tool supports a color.

When I load the project, DWC goes a bit nuts.. it keeps disconnecting and the Tools table just says everything is Tool 0.

What's going on?

It's a feature

Yep, that's it....

Recreating or adding a new tool sets the retraction to a default value of 2mm..

So I need to add an M207 S0.5 F1000 Z0.2 command to my custom gCode after creating all the tools...

cool.

@Phaedrux said in firmware retraction doubling:

If you send M98 Pprint_start.g on it's own do you get any errors?
If you send M567 during the print does it respond with the expected mixing ratio?

Have you enclosed the macro name in quotes as OwenD suggested? ""

I get no errors
Hmm sending M567 returns nothing... But it does mess up the mix ratio for the current print.. until the next tool changes.
sending M567 P0 (P1 P2 P3) returns the correct mix ration for each of the "tools"

The print_start.g on it's own doesn't work unless I've preheated the bed and the nozzle... but once that's done, print_startg works fine.

Could it be because I'm redefining Tool 0 in my custom gCode forcing it to default the retraction settings??

@Phaedrux

print_start.g

@Phaedrux

Also at the end of a print, custom gCode is:

; remove the extra tools so we restore back to standard
M563 P3 D-1 H-1
M563 P2 D-1 H-1
M563 P1 D-1 H-1

M104 S0 ; turn off temperature
G28 X0 ; home X axis

M140 S0

M84 ; disable motors

@Phaedrux
config.g

Starting gCode from Prusa Slicer:

M190 S[first_layer_bed_temperature] ; wait for first layer bed temperature
G28 ; home all axes
;G29 ; Auto Bed Leveling...
M104 S[first_layer_temperature] ; Heatup and Purge Nozzle
G92 E0 ; reset extruder
G1 X0 Y0 Z10.0 F5000 ; move to purge position

T0
; bring it up to temperature
G10 P0 R0 S[first_layer_temperature] ; Wait For Nozzle Heat
M116

; machine standard purge - purges all nozzles on the left side of the platter.
M98 P"Print_Start.g"

; set up the tools for selected colors.. You can define as many as you want,
; just make sure you update their temperatures in the Before layer change G-Code and remove them in the End G-Code

M563 P0 D0:1:2:3 H1 F1
M563 P1 D0:1:2:3 H1 F1
M563 P2 D0:1:2:3 H1 F1
M563 P3 D0:1:2:3 H1 F1

;=============== Quad Fustion color support ===============
;Set the color for each of the defined "tools"
M567 P0 E1.0:0.0:0.0:0.00 S"Cyan"
M567 P1 E0.0:1.0:0.0:0.00 ; Magenta
M567 P2 E0.0:0.00:1.0:0.00 ; yellow
M567 P3 E0.0:0.0:0.0:1.0 ; White
;==========================================================

;Init the tool temperatures for the first layer and wait.
G10 P0 R0 S[first_layer_temperature]
G10 P1 R0 S[first_layer_temperature]
G10 P2 R0 S[first_layer_temperature]
G10 P3 R0 S[first_layer_temperature]
M116

T0 ; Ensure Post Processing Gcode Generator Has something to convert if only one tool is used.

Thank you.

One more question. does the M207 command need to be sent after the tools are all created?..

I'm still getting the issue that the retract gets reset to 2mm whenever I start a new print from the "initial" state.

my custom gCode for PrusaSlicer at start creates the per color tools and after they start being used M207 command returns 2mm for retract amount even though I'm setting it in the config file to 0.5mm

So, it all seems to be working now... not quite sure what happened, but...

Thanks everyone who looked at this and scratched their heads...

--marcel