Supporting a mixing nozzle #875

Open
digiexchris opened this Issue Mar 15, 2016 · 45 comments

Projects

None yet

9 participants

@digiexchris

I'm about to venture into the world of color mixing using the diamond hot end. Here's a link on how repetier+slic3r does it. http://reprap.org/wiki/Repetier_Color_Mixing#Setting_up_colors_in_Repetier-Host

I heard rumors that someone was working on a branch for smoothie that supported this, but I've been unable to find any code. I'm willing to start implementing this, but just wondering if there is any WIP stuff I can help out with.

@dutchrazor

I am working on a mixing nozzle implementation, perhaps we could see about integrating it back into Smoothie. As far as I know, it's the only attempt to use it in Smoothie so far.

@triffid
Contributor
triffid commented Mar 15, 2016

I wonder how feasible it would be to simply instantiate multiple Extruder
modules.. Can that work? Config setup may be interesting but temperature
control provides an example of one way to do it.

You might have to add axis names or something for simultaneous extrusion
On 16 Mar 2016 00:36, "dutchrazor" notifications@github.com wrote:

I am working on a mixing nozzle implementation, perhaps we could see about
integrating it back into Smoothie. As far as I know, it's the only attempt
to use it in Smoothie so far.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:

#875 (comment)

@leonmf
Contributor
leonmf commented Mar 15, 2016

I setup an E3D cyclops this way. I just set the temperature feedback to
the same pin for both modules. I never quite figured out how to not set
the heater pin for the second module and it's just disconnected for the
cyclops. As long as the temperature is set the same for "both" hot ends,
it all works fine. You'd have to rely on the slicer to do the mixing
functions, though as the smoothie is just going to take the extruder
counts you give it and push those out of the nozzle.

Michael Moon mailto:notifications@github.com
Tuesday, March 15, 2016 11:39 AM
I wonder how feasible it would be to simply instantiate multiple Extruder
modules.. Can that work? Config setup may be interesting but temperature
control provides an example of one way to do it.

You might have to add axis names or something for simultaneous extrusion
On 16 Mar 2016 00:36, "dutchrazor" notifications@github.com wrote:

I am working on a mixing nozzle implementation, perhaps we could see
about
integrating it back into Smoothie. As far as I know, it's the only
attempt
to use it in Smoothie so far.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:

#875 (comment)


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#875 (comment)

digiexchris mailto:notifications@github.com
Tuesday, March 15, 2016 10:47 AM

I'm about to venture into the world of color mixing using the diamond
hot end. Here's a link on how repetier+slic3r does it.
http://reprap.org/wiki/Repetier_Color_Mixing#Setting_up_colors_in_Repetier-Host

I heard rumors that someone was working on a branch for smoothie that
supported this, but I've been unable to find any code. I'm willing to
start implementing this, but just wondering if there is any WIP stuff
I can help out with.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#875

@digiexchris

I think the main issue is that it can't move two extruders at the same time. Or can it now?

@digiexchris

@dutchrazor Is it up somewhere publicly available? I'd love to take a look at it, even just for interest's sake

@leonmf
Contributor
leonmf commented Mar 15, 2016

I can't confirm but based on smoothies let you do anything you tell it
to do structure, I can't see why it wouldn't work.

Michael Moon mailto:notifications@github.com
Tuesday, March 15, 2016 11:39 AM
I wonder how feasible it would be to simply instantiate multiple Extruder
modules.. Can that work? Config setup may be interesting but temperature
control provides an example of one way to do it.

You might have to add axis names or something for simultaneous extrusion
On 16 Mar 2016 00:36, "dutchrazor" notifications@github.com wrote:

I am working on a mixing nozzle implementation, perhaps we could see
about
integrating it back into Smoothie. As far as I know, it's the only
attempt
to use it in Smoothie so far.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:

#875 (comment)


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#875 (comment)

digiexchris mailto:notifications@github.com
Tuesday, March 15, 2016 10:47 AM

I'm about to venture into the world of color mixing using the diamond
hot end. Here's a link on how repetier+slic3r does it.
http://reprap.org/wiki/Repetier_Color_Mixing#Setting_up_colors_in_Repetier-Host

I heard rumors that someone was working on a branch for smoothie that
supported this, but I've been unable to find any code. I'm willing to
start implementing this, but just wondering if there is any WIP stuff
I can help out with.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#875

@digiexchris

Ok, I've got it working as 1 temp controller and 3 extruders. Now I'm working on the modifications required to make them truely mixing.I'd love to see the work of anyone that's been working on it. I've done a bit of thinking. We need to run 1, 2, or 3 steppers independently from one G0,G1 code while referencing a single axis (E) like we currently do, to maintain gcode compatibility.

Here's my thoughts on a possible config, using a new tool type called a Virtual Extruder, rather than a laser or a normal Extruder, or some other tool type we currently have. Right now, Extruder instantiates 1 Stepper, and we'll need to build a Stepper instance per configured stepper.

virtualextruder.first.enable true
virtualextruder.first.stepper1.steps_per_mm                        400             
virtualextruder.first.stepper1.default_feed_rate                   600
virtualextruder.first.stepper1.acceleration                        500 
virtualextruder.first.stepper1.max_speed                           3000
virtualextruder.first.stepper1.step_pin                            2.3
virtualextruder.first.stepper1.dir_pin                             0.22
virtualextruder.first.stepper1.en_pin                              0.21
delta_current                                        1.5

virtualextruder.first.stepper2.steps_per_mm                        400             
virtualextruder.first.stepper2.default_feed_rate                   600
virtualextruder.first.stepper2.acceleration                        500 
virtualextruder.first.stepper2.max_speed                           3000
virtualextruder.first.stepper2.step_pin                            2.3
virtualextruder.first.stepper2.dir_pin                             0.22
virtualextruder.first.stepper2.en_pin                              0.21
epsilon_current                                        1.5

#define a colour as an extruder, this one fully one extruder, the other off
virtualextruder.first.e1.stepper1.weight    256
virtualextruder.first.e1.stepper2.weight    0

#define a colour, this one fully one extruder, the other off
virtualextruder.first.e2.stepper1.weight    0
virtualextruder.first.e2.stepper2.weight    256

#define a mixed colour half one half the other
virtualextruder.first.e3.stepper1.weight    128
virtualextruder.first.e3.stepper2.weight    128

Then when asked to retract you can retract based on the weight as well, so you don't need a mile of retraction, and you can accurately restart on un-retract. Probably best to use firmware retraction rather than slicer controlled retraction so we can accurately un-retract based on weight.

Then similarly to the repetier code, you just setup your slicer to use one of the 3 setup colours as an extruder. Lets assume we've set a retraction length of 3mm per extruder

G10 ; 
T1 ; selects virtualextruder.first.e1
G11 ; unretract 3mm from stepper1, do nothing with stepper2 because it's weight is 0
G1 E5 extrudes 2.5mm out of stepper1 and 0mm out of stepper2
G10 ; retract 3mm from stepper 1, do nothing with stepper 2 because it's weight is 0
T2 ; select virtualextruder.first.e3
G11; unretracts 3mm from stepper1 and 3mm from stepper2 since both stepper1 and stepper2 weights are greater than zero
G1 E5; extrude 2.5mm from stepper1 and 2.5mm from stepper2
G11; retract 3mm from both stepper1 and stepper2

We also need a way to change weights after smoothie boots and has read the config, so the start gcode of the file we're printing can change colours. Again stealing from the repetier method:

M163 S0 100
M163 S1 155

We can always just do the math as percentages of all the weights added together, so as long as we pick the same amount of precision in the config, it's fine

;black only
M163 S0 P0 ;white
M163 S1 P4 ;black

;grey
M163 S0 P2
M163 S1 P2

I've taken a look at the Extruder, ToolManager, and Planner, and I think this could work without many changes outside of the virtual extruder module and the gcode planner. I need to look into stepper control vs feedrates a little more.

Thoughts?

@arthurwolf
Contributor

Hey.

On Thu, Mar 31, 2016 at 11:37 PM, digiexchris notifications@github.com
wrote:

Ok, I've got it working as 1 temp controller and 3 extruders. Now I'm
working on the modifications required to make them truely mixing.I'd love
to see the work of anyone that's been working on it. I've done a bit of
thinking. We need to run 1, 2, or 3 steppers independently from one G0,G1
code while referencing a single axis (E) like we currently do, to maintain
gcode compatibility.

I'm not sure that's what we need to do.
People using the diamond hotend must be using some kind of gcode
format/slicer. What do they use ? Likely that's what we want to follow.

Here's my thoughts on a possible config, using a new tool type called a
Virtual Extruder, rather than a laser or a normal Extruder, or some other
tool type we currently have. Right now, Extruder instantiates 1 Stepper,
and we'll need to build a Stepper instance per configured stepper.

Very much against making a new module if we can re-use the existing one.
If there is any possibility of extending the normal extruder, we definitely
should do that.
I don't think there is a need for a new extruder creating module.

Cheers !

virtualextruder.first.enable true

virtualextruder.first.stepper1.steps_per_mm 400
virtualextruder.first.stepper1.default_feed_rate 600
virtualextruder.first.stepper1.acceleration 500
virtualextruder.first.stepper1.max_speed 3000
virtualextruder.first.stepper1.step_pin 2.3
virtualextruder.first.stepper1.dir_pin 0.22
virtualextruder.first.stepper1.en_pin 0.21
delta_current 1.5

virtualextruder.first.stepper2.steps_per_mm 400
virtualextruder.first.stepper2.default_feed_rate 600
virtualextruder.first.stepper2.acceleration 500
virtualextruder.first.stepper2.max_speed 3000
virtualextruder.first.stepper2.step_pin 2.3
virtualextruder.first.stepper2.dir_pin 0.22
virtualextruder.first.stepper2.en_pin 0.21
epsilon_current 1.5

#define a colour as an extruder, this one fully one extruder, the other off
virtualextruder.first.e1.stepper1.weight 256
virtualextruder.first.e1.stepper2.weight 0

#define a colour, this one fully one extruder, the other off
virtualextruder.first.e2.stepper1.weight 0
virtualextruder.first.e2.stepper2.weight 256

#define a mixed colour half one half the other
virtualextruder.first.e3.stepper1.weight 128
virtualextruder.first.e3.stepper2.weight 128

Then when asked to retract you can retract based on the weight as well, so
you don't need a mile of retraction, and you can accurately restart on
un-retract. Probably best to use firmware retraction rather than slicer
controlled retraction so we can accurately un-retract based on weight.

Then similarly to the repetier code, you just setup your slicer to use one
of the 3 setup colours as an extruder. Lets assume we've set a retraction
length of 3mm per extruder

G10 ;
T1 ; selects virtualextruder.first.e1
G11 ; unretract 3mm from stepper1, do nothing with stepper2 because it's weight is 0
G1 E5 extrudes 2.5mm out of stepper1 and 0mm out of stepper2
G10 ; retract 3mm from stepper 1, do nothing with stepper 2 because it's weight is 0
T2 ; select virtualextruder.first.e3
G11; unretracts 3mm from stepper1 and 3mm from stepper2 since both stepper1 and stepper2 weights are greater than zero
G1 E5; extrude 2.5mm from stepper1 and 2.5mm from stepper2
G11; retract 3mm from both stepper1 and stepper2

We also need a way to change weights after smoothie boots and has read the
config, so the start gcode of the file we're printing can change colours.
Again stealing from the repetier method:

M163 S0 100
M163 S1 155

We can always just do the math as percentages of all the weights added
together, so as long as we pick the same amount of precision in the config,
it's fine

;black only
M163 S0 P0 ;white
M163 S1 P4 ;black

;grey
M163 S0 P2
M163 S1 P2

I've taken a look at the Extruder, ToolManager, and Planner, and I think
this could work without many changes outside of the virtual extruder module
and the gcode planner. I need to look into stepper control vs feedrates a
little more.

Thoughts?


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#875 (comment)

Courage et bonne humeur.

@digiexchris

@arthurwolf Thanks for the feedback! I'll think about how we can reuse the extruder module more.

For the gcode, I was basically working off of the only other mixing firmware available, repetier-firmware. That's how they do it, assigning colour weights to an extruder as start gcode, which moves multiple extruders to make it happen. the printing gcode is no different than a normal dual extrusion print. any slicer is capable of it. You break an object up into multiple STL's, one per colour that you want to print and assign an extruder to that object. It's no different with the Diamond. The difference with the diamond capable firmware is that it then takes the job of moving the appropriate steppers at the appropriate weight to make that defined extruder's colour happen. I've tried it, the gcode output still uses the G1 X Y E format that we're used to, which requires only one tool to be selected as far as I'm aware.

How else could it work? Wouldn't activating two tools at the same time be a violation of gcode spec? I really don't want to do something like T0 R128 G128 B0 as a tool activation gcode, because then it's incompatible with every slicer.

Here's the slic3r/repetier-host method using repetier-firmware to do mixed material prints. Repetiier-host is capable of defining the colour/extruder combination and generating start-gcode for us, but to use another slicer/host all you've gotta do is generate the start gcode yourself.

http://reprap.org/wiki/Repetier_Color_Mixing

@arthurwolf
Contributor

On Sun, Apr 3, 2016 at 7:16 PM, digiexchris notifications@github.com
wrote:

@arthurwolf https://github.com/arthurwolf Thanks for the feedback! I'll
think about how we can reuse the extruder module more.

For the gcode, I was basically working off of the only other mixing
firmware available, repetier-firmware. That's how they do it, assigning
colour weights to an extruder as start gcode, which moves multiple
extruders to make it happen. the printing gcode is no different than a
normal dual extrusion print. any slicer is capable of it. You break an
object up into multiple STL's, one per colour that you want to print and
assign an extruder to that object. It's no different with the Diamond. The
difference with the diamond capable firmware is that it then takes the job
of moving the appropriate steppers at the appropriate weight to make that
defined extruder's colour happen. I've tried it, the gcode output still
uses the G1 X Y E format that we're used to, which requires only one tool
to be selected as far as I'm aware.

How else could it work? Wouldn't activating two tools at the same time be
a violation of gcode spec?

The way multi-extrusion is implemented in the reprap world anyway, makes no
sense in the gcode spec, it's a complete bastardization of the spec, so no
worries about breaking anything here.

I really don't want to do something like T0 R128 G128 B0 as a tool
activation gcode, because then it's incompatible with every slicer.

Nah, that's not what we want.

M163 S0 100
M163 S1 155

Would work fine, if that's what repetier-host uses.

But I know some folks that use something like :

G1 X10 A1 B2 C3

( Where ABC are extruders ).
In experimental slicing software.

It'd be great if both syntaxes would be supported, because the great thing
about the first one is repetier uses it, but the great thing about the
second one, is it is useful for CNC mills.

Makes sense ?

Here's the slic3r/repetier-host method using repetier-firmware.
Repetiier-host is capable of defining the colour/extruder combination and
generating start-gcode for us, but to use another slicer/host all you've
gotta do is generate the start gcode yourself.

http://reprap.org/wiki/Repetier_Color_Mixing


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#875 (comment)

Courage et bonne humeur.

@digiexchris

G1 X10 A1 B2 C3 certainly makes more sense to me. I found one of those mixing extruder gcode processors you're talking about. https://github.com/Gyrobot/Gcode-Filament-Mixer

I agree, that's the better way to go. If we make Smoothie able to move multiple, already defined extruders at the same time, there's no other changes we have to make. Sounds a lot less daunting. then I can just ask the slicers to support it and use the processor in the meantime.

So, a config value for each defined extruder for axis letter? Or assume that the first extruder in the config is A?

@arthurwolf
Contributor

If repetier already has a syntax, it'd be nice if we also supported that,
I think.
But maybe in a second time ? I don't know.

About ABC; it should be a configuration option for each module, ideally.

On Mon, Apr 4, 2016 at 11:48 PM, digiexchris notifications@github.com
wrote:

G1 X10 A1 B2 C3 certainly makes more sense to me. I found one of those
mixing extruder gcode processors you're talking about.
https://github.com/Gyrobot/Gcode-Filament-Mixer

I agree, that's the better way to go. If we make Smoothie able to move
multiple extruders at the same time, there's no other changes we have to
make. Sounds a lot less daunting. then I can just ask the slicers to
support it and use the processor in the meantime.

So, a config value for each defined extruder for axis letter? Or assume
that the first extruder in the config is A?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#875 (comment)

Courage et bonne humeur.

@dutchrazor

Hey,

Apologies for my late reply. I have a working test version of Smoothie that supports simultaenous multi extrusion. You can define a letter in the config file, and each separate extruder will follow the Gcode defined by that letter. So. e.g. extruder A and extruder B can follow:

G0 X10 EA5 EB6.

You could also just type G0 X10 E A5 B6 I left the E in there since CNC machines support A and B axis, but it's a single line in code and could be removed if desired.

I defined new commands for simultaneously enabling multiple tools, this can be done by appending "S" to T. So TS0 and TS1 enable tools simultaneously.

Since pronterface does not support appending anything to the "T" command, I usually type GTS0 and GTS1.

I made lines in the config as follows:

extruder.hotend.dualsim_extrude_string A
extruder.hotend2.dualsim_extrude_string B

What isn't finished yet:
-When a dual extrude string is defined, enabling a single tool via T* does not yet override the dual extrude string. So you can enable only one tool, but it will still only listen to the string instead of E.

Best regards,

Fabien

Firmware: https://www.wetransfer.com/downloads/b6d3990fc08d814bfbb0d7abaf2d1a7120160408094610/b51eb837102975baa4791a636dcdf1ea20160408094610/320200

@arthurwolf
Contributor

Hey.

Really great you got it to actually work ! Great progress !

I think the syntax we want to support is :

G0 X1 A5 B86

E is not necessary here.

And multiple-letters Gcode are generally strongly disliked.

As for enabling the multi-extruder stuff, it should really be done in
config, not with a Gcode.
You can also have a Gcode ( though I'm not sure what for ), but it
shouldn't be a multiple-letter thing, just a new M-code.

Cheers :)

On Fri, Apr 8, 2016 at 11:47 AM, dutchrazor notifications@github.com
wrote:

Hey,

Apologies for my late reply. I have a working test version of Smoothie
that supports simultaenous multi extrusion. You can define a letter in the
config file, and each separate extruder will follow the Gcode defined by
that letter. So. e.g. extruder A and extruder B can follow:

G0 X10 EA5 EB6.

You could also just type G0 X10 E A5 B6 I left the E in there since CNC
machines support A and B axis, but it's a single line in code and could be
removed if desired.

I defined new commands for simultaneously enabling multiple tools, this
can be done by appending "S" to T. So TS0 and TS1 enable tools
simultaneously.

Since pronterface does not support appending anything to the "T" command,
I usually type GTS0 and GTS1.

I made lines in the config as follows:

extruder.hotend.dualsim_extrude_string A
extruder.hotend2.dualsim_extrude_string B

Best regards,

Fabien

Firmware:
https://www.wetransfer.com/downloads/b6d3990fc08d814bfbb0d7abaf2d1a7120160408094610/b51eb837102975baa4791a636dcdf1ea20160408094610/320200


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#875 (comment)

Courage et bonne humeur.

@digiexchris

Excellent! I'll give it a try. Are you using a particular gcode postprocessor with it?

I haven't looked closely at the toolchange code yet but I suspect pronterface doesn't let you append anything but a number after T, because that's normal gcode spec. Multiple letters in a row usually isn't supported on the machines it's normally talking to. Do you think it's possible to make the original T* codes work? If it's not easy we could easily use something else, U* or something, many slicers let you define the tool id and many let you specify tool change gcode if not. For example, in simplify3d I could use
M667 S<extruder #>
Since T* is ignored, it'll send a T0, which is ignored, and then M667 S0 which does the tool change instead.

I'll take a look at your changes and learn some more.

@wolfmanjm
Contributor

That is totally illegal GCode. EA5 is not legal.

@byteibit

Hi
dutchrazor, I would like to test the modified firmware but file is removed from provided link

@dutchrazor

Hey,

I put it on Dropbox now:

https://www.dropbox.com/s/i4jbsjywfex2b6a/Smoothieware.zip?dl=0

I think I should probably make a branch, I'm a bit of a Github noob.

Best regards,

Fabien

2016-04-21 10:32 GMT+02:00 byteibit notifications@github.com:

Hi
dutchrazor, I would like to test the modified firmware but file is removed
from provided link


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#875 (comment)

@byteibit
byteibit commented Apr 25, 2016 edited

thanks Fabien for quick response, i will test it this days. So to activate my both extruder to print simultaneously i nedd to use your modified firmware, add this lines in config.file
extruder.hotend.dualsim_extrude_string A
extruder.hotend2.dualsim_extrude_string B
and use g-code commands: GTS0 and GTS1. to activate both extruder is that correct?

@byteibit

Hi fabien ,
I have try to test but i need some more light here:

  1. is this only work on pronterface or can also work in repetier which i am using in the moment.
  2. if i use GTS0 nothing happen , GTS1 also nothing until i switch off second extruder heater in manual control, then is some kind of fast, forced extrusion on that extruder after violent move it start to extrude with normal speed. So in my case GTS1 change tools but only when switching off sec. extruder.
  3. should i alter whole g-code generated from slicing tool for certain object to print simultaneously with 2 extruder to meet G0 X10 EA5 EB6?
    Maybe it will be good to explain how exactly we can print simultaneously in one example
    thanks
@EliteEng
EliteEng commented Apr 26, 2016 edited

I am looking into multi colour extruding as well, and the way I had thought easiest to implement would be to have an M code to set the weights/ratios of the extruders then use the normal E values in the G code.
ie

M999 S1 A50 B50
T1
G1 X10 Y10 E5
*Note M999 is just an example

This would set Tool 1 to have to have extruder ratios of A to 50% & B to 50%, so when the G code is executed extruder A & B would both move 2.5

I see this as an easier implementation for slicers and hosts to adopt. At the start of the gcode file you would set the tool ratios then the slicer can handle the tool changes to extrude the mixed colours.

@wolfmanjm
Contributor

That is a much better way to do it yes I agree. and as extruder already deals with ratios it would be easier to implement. Although you cannot use M999 as that is already in use.

The Other one uses illegal gcode syntax and would not be acceptable.

@EliteEng

Would you have any objections to using M615 for this?

@byteibit

is there any solution for ditto printing for smoothie ?

@EliteEng

Can I get your thoughts on how you would implement this, ( my background is with GRBL and I am still getting my head around the Smoothieware format )

What would be the best way to activate more than one extruder?
Would you store the ratio's in Toolmanager, then on tool change set the extruder ratio's to suit the tool.

@wolfmanjm
Contributor

no toolmanager is not extruder specific. So the extruder module would load the ratio from the m code itself. picing up the relevant axis parameter to suit. or have a parameter that targets a specific extruder, that is also done in other places. like P1 for extruder 1 and P2 for extruder 2 etc.

@arthurwolf
Contributor

Made any progress on this ? Is the spec for what to be done fixed now ? Need any help ?

@wolfmanjm
Contributor

FYI any work done on this will be totally irrelevant with the upcoming changes in motion planning and stepping. As extruder is going to be completely rewritten.
However as we may have mutli axis planning it may actually be easier.

@arthurwolf
Contributor

Yep that's fine, progress on this is still good, even if it only ends up as
a "proof of concept" and the actual implementation needs to be different
for the new motion stuff.

On Sun, May 15, 2016 at 10:57 AM, Jim Morris notifications@github.com
wrote:

FYI any work done on this will be totally irrelevant with the upcoming
changes in motion planning and stepping. As extruder is going to be
completely rewritten.
However as we may have mutli axis planning it may actually be easier.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#875 (comment)

Courage et bonne humeur.

@EliteEng

I have made some progress with this, and yes I see this as a proof of concept at the moment.
I will put up what I have done so far on my repo tomorrow.
I think it should be functioning, but by no means complete, tested or optimized.

I am slowly getting my head around how the "Smoothieware" code functions and interacts, I am more than happy to get going with this and any help or advice would be greatly appreciated.

@EliteEng

Here is my initial code, I have tried to keep it all within the extruder module.
EliteEng@a23d809
I am still learning how the modules interact.
Any help or advice would be greatly appreciated.

@arthurwolf
Contributor

Nice. Code looks good, though I'm sure there are possible improvements/way
to make it integrate into Smoothie better. Good progress though, I'm glad
this is moving forward.

Did you test it ?

On Fri, May 20, 2016 at 1:50 PM, Rob Brown notifications@github.com wrote:

Here is my initial code, I have tried to keep it all within the extruder
module.
EliteEng@a23d809
EliteEng@a23d809
I am still learning how the modules interact.
Any help or advice would be greatly appreciated.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#875 (comment)

Courage et bonne humeur.

@EliteEng

There are a few things to fix up and yes it will need improvements.
I plan on testing on Monday, on the scope first.

@byteibit

Hi eliteeng did you test it?

@EliteEng

Just a quick update, I have tested with 3 extruders and they are working as expected. I will clean up the code then upload it ( over the weekend )

This has been a good learning experience for me and once the new motion and planning changes come out I will look at implementing these changes again.

@wolfmanjm
Contributor

I am sorry to say that nothing you have done will work in the new firmware that is about to be released. The Extruder module got completely rewritten. So a PR will have to be rejected.
You can get a heads up by looking at the PR #948

Sorry about that, but I am sure now you understand what needs to be done you will have a head start.
However even in the new code it is hard coded that only one extruder can run at any given time. So there is a lot of work to fix that.

@wolfmanjm
Contributor

FYI eventually I plan to do a real n-axis, which will make it a lot easier to do a mixing type extruder.

@byteibit
byteibit commented Jun 29, 2016 edited

Great news EliteEng , when you update clean code i would like to test it. I am only interesting to ditto printing (simultaneous or parallel print with 2 extruder with decent distance between them) . Is it possible wit your code? If Yes please write some example of g-code command to use, thanks

@digiexchris

@byteibit that seems simpler to do just by either wiring both extruders to the same driver or wire in an additional driver to the same driver input pins. There's holes in the board that lets you do that. See the documentation on running external drivers, it's the same concept.

@byteibit
byteibit commented Jun 29, 2016 edited

wiring both extruder to the same driver will not work (not enough power output for 2 extruder motor and eventually will skip steps) adding one more driver in parallel is one solution but then you have other driver on board to do nothing. So to me is more logic and elegant to use already present drivers it is just matter of adding possibilities to firmware. Also i would like to have possibilities to expand it to 4 extruder ( 2+2additional drivers) and then print 4 identical object at once

@wolfmanjm
Contributor

I have a pull request #989 that allows three independent axis A B C be specified in a G0 or G1. These could be enabled as extruders and would allow them to be controlled independently by using G1 Axxx Bxxx Cxxx to tell each one how much to move. You will need a slicer that can generate A B C for each extruder. This is standard CNC multi axis control.

@ElJefeDSecurIT

i am looking at the diamond hotend mixing extruder scenario on smoothie as well, my alligator board took a nosedive, so investigating smoothie as a replacement. it would be great to get consistent support in this firmware as this is supported in marlinkimbra for Due, the Duet, and repetier firmwares. from marlin kimbra:
https://github.com/MagoKimbra/MarlinKimbra4due/blob/V4_2_9/Documentation/GCodes.md
M163 - Set a single proportion for a mixing extruder. Requires COLOR_MIXING_EXTRUDER.
M164 - Save the mix as a virtual extruder. Requires COLOR_MIXING_EXTRUDER and MIXING_VIRTUAL_TOOLS.
M165 - Set the proportions for a mixing extruder. Use parameters ABCDHI to set the mixing factors. Requires COLOR_MIXING_EXTRUDER.

from repetier:
https://github.com/repetier/Repetier-Firmware/blob/master/src/ArduinoAVR/Repetier/Repetier.ino

  • M163 S P - Set weight for this mixing extruder drive
  • M164 S P<0 = dont store eeprom,1 = store to eeprom> - Store weights as virtual extruder S

The format of G1 Ax B x Cx is consistent with the GCODE format, however this is a blocker for multi-extruder printing becuase it runs counter to the current standards, if this is to remain consistent with AMF format and firmware trends. slic3r and msft 3d builder- which use amf- support multiple extruders, repetier host and mft 3d builder can output the gcodes for multiple extruders, physical and virtual, it seems. the slicers do not output different ratios for each extruder, they do not have a mixing concept in the slicing engines; they have extruders and material types for each extruder. Repetier (the host) seems to allow mapping ratios of ABC extruders to a virtual extruder using scripts, and the mapping of the output GCODE from both of those slicers honors multiple extruders in this way. one only has to define their 16 color extruder order in both their slicer, and their host, to get the right mappings sent to the controller.

following this approach for g1 Ax Bx Cx runs counter to the established 3d reprap approach for G1 En xx.xx for virtual extruders so the ask, would then be. is it possible to define these virtual extruders, and define ABC weights or ratio settings using the GCODEs already being established?

@arthurwolf
Contributor

Smoothie currently supports G1 ABC, so that's the shortest route to getting
it to work. If the issue here is that slicers use a different set of Gcode,
I expect the simplest route to getting this to work, is to write a very
simple/easy module that internally reads M163 and friends, and internally
outputs G1ABC into Smoothie accordingly, I think that would work fine and
be quite small/simple to write.

On Fri, Oct 14, 2016 at 6:28 AM, ElJefeDSecurIT notifications@github.com
wrote:

i am looking at the diamond hotend mixing extruder scenario on smoothie as
well, my alligator board took a nosedive, so investigating smoothie as a
replacement. it would be great to get consistent support in this firmware
as this is supported in marlinkimbra for Due, the Duet, and repetier
firmwares. from marlin kimbra:
https://github.com/MagoKimbra/MarlinKimbra4due/blob/V4_2_9/
Documentation/GCodes.md
M163 - Set a single proportion for a mixing extruder. Requires
COLOR_MIXING_EXTRUDER.
M164 - Save the mix as a virtual extruder. Requires COLOR_MIXING_EXTRUDER
and MIXING_VIRTUAL_TOOLS.
M165 - Set the proportions for a mixing extruder. Use parameters ABCDHI to
set the mixing factors. Requires COLOR_MIXING_EXTRUDER.

from repetier:
https://github.com/repetier/Repetier-Firmware/blob/master/
src/ArduinoAVR/Repetier/Repetier.ino

  • M163 S P - Set weight for this mixing extruder drive
  • M164 S P<0 = dont store eeprom,1 = store to eeprom> - Store weights
    as virtual extruder S

The format of G1 Ax B x Cx is consistent with the GCODE format, however
this is a blocker for multi-extruder printing becuase it runs counter to
the current standards, if this is to remain consistent with AMF format and
firmware trends. slic3r and msft 3d builder- which use amf- support
multiple extruders, repetier host and mft 3d builder can output the gcodes
for multiple extruders, physical and virtual, it seems. the slicers do not
output different ratios for each extruder, they do not have a mixing
concept in the slicing engines; they have extruders and material types for
each extruder. Repetier (the host) seems to allow mapping ratios of ABC
extruders to a virtual extruder using scripts, and the mapping of the
output GCODE from both of those slicers honors multiple extruders in this
way. one only has to define their 16 color extruder order in both their
slicer, and their host, to get the right mappings sent to the controller.

following this approach for g1 Ax Bx Cx runs counter to the established 3d
reprap approach for G1 En xx.xx for virtual extruders so the ask, would
then be. is it possible to define these virtual extruders, and define ABC
weights or ratio settings using the GCODEs already being established?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#875 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGpFcbIQo8QQ70X3hewqxGcje5QU5ohks5qzwUJgaJpZM4HxJ8o
.

Courage et bonne humeur.

@ElJefeDSecurIT

i am reading this as, thinking out loud for what would it take to implement this as a shim in the smoothieware, ok, i think I get that, :) what would that look like?

if on the other hand, and i hope i am misunderstanding this, if what you are saying is that we would need to add a module into the slicers... if so, this is unfortunate. the reason is because of the 4 major firmwares, marlin, repraprpo, repetier, and smoothieware, that are currently supported by things like slic3r, cura, the msft 3d builder, makerbot, et al, smoothieware would be the only one without this capability. :( please correct me if i'm wrong, internet forums are hard to interpret context and intent sometimes.

@ElJefeDSecurIT

...on the "what would that look like?" what pages in the code are you thinking? for me to get up to speed quickly... (context: i sorta kinda do a lot of code reviews, for some big company...and have hacked a bunch of codes, for some personal projects... :) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment