Replicator 2x Kisslicer Dual Extruder

[Spk64]

Has anyone had luck getting the dual extruders to work properly with Kisslicer?

Been trying to get a raft with one extruder and the part with the other.

The problem I seem to be having is getting the offset to apply.  So the raft prints in the correct location with the left extruder.  Then the part starts printing with the right extruder but using the left extruder offset.

What is strange is my start Gcode which purges both extruders works properly.

Start Gcode

(*** start.gcode for The Replicator 2X, dual head ****)

M103 (disable RPM)

M73 P0 (enable build progress)

G21 (set units to mm)

G90 (set positioning to absolute)

;chgd from M109 to M140 to allow GPX to work

M140 S<BED> T0 (set HBP temperature)

M104 S<TEMP> T0

M104 S<TEMP> T1

(**** begin homing ****)

G162 X Y F2500 (home XY axes maximum)

G161 Z F1100 (home Z axis minimum)

G92 Z-5 (set Z to -5)

G1 Z0.0 (move Z to "0")

G161 Z F100 (home Z axis minimum)

M132 X Y Z A B (Recall stored home offsets for XYZAB axis)

(**** end homing ****)

G1 X-130 Y-75 Z30 F3300 (move to waiting position off build plate)

M70 P1 (Please wait...)

G130 X20 Y20 Z20 A20 B20 (lower stepper Vrefs while heating)

M6 T0 (wait for extruder to reach temperature)

G130 X127 Y127 Z40 A127 B127 (set stepper motor Vref to defaults)

G0 X-100 Y-75 Z0.5 (position nozzle)

G92 E0 (Set E to 0)

G1 E6 F300 (Extrude 8mm of filament)

G92 E0 (Reset E to 0 again)

G1 X-110 Y-70 Z0.2 E1 F300 (do a slow wipe...)

G1 X-130 Y-70 Z0.5 F300 (...and lift)

G92 E0 (Reset E to 0 again)

; Purge second head

M6 T1 (wait for extruder to reach temperature)

G130 X127 Y127 Z40 A127 B127 (set stepper motor Vref to defaults)

G0 X-100 Y-60 Z0.5 F3300 (position nozzle)

G92 E0 (Set E to 0)

G1 E6 F300 (Extrude 8mm of filament)

G92 E0 (Reset E to 0 again)

G1 X-110 Y-55 Z0.2 E1 F300 (do a slow wipe...)

G1 X-130 Y-55 Z0.5 F300 (...and lift)

G92 E0 (Reset E to 0 again)

(*** end of start.gcode ***)

And my change extruder gcode

As you can see I have tried several itterations.   Also tried adding a G54 or G55 as I had seen some luck with this on a replicator Dual

; Replicator 2x

;M108 T<EXT+0>

M104 S<TEMP> T<EXT+0>

;M6 T<EXT+0>

;G1 E.001 F30

;G92 E0

Thanks,

[RoboSysop]

I gave up on it myself.  When I bought Kisslicer I thought it had the printing code for Makerbots Dual printing.  I never would have bought it if I had known I had to do it myself.  It almost set my Makerbot on fire.  The extruder temp doubled after it started to print.  I shut it down before it could do any damage.

[RoboSysop]

Someone needs to build a MAX temp feature into the Makerbots to prevent damage.

[Joseph Chiu]

An extruder temp safety used to exist on the ToM. Then it was gone with the Replicator...

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[RoboSysop]

If there was a program that could scan the Gcode looking for errors in the temperature settings, the problem would be solved.  Just scan you gcode to check before printing.

[Spk64]

Anyone having success with Sailfish, Dual Extruders and Kisslicer or Repg?

What is the correct Tool change?

M6 does not work

M135 seems to be outputting from Makerware in the Gcode export but this does not work.

Tried M54 and M55

Thanks,

On Friday, May 17, 2013 11:42:28 AM UTC-4, Spk64 wrote:

[Jetguy]

Well, I can easily yes, I have a Rep1 dual, Sailfish 7.4 and use
Sailfish Rep-G 40R18 and it works great in dual.

It's not clear though, I though you wanted to use Kisslicer- thus I'm
not sure why you asked about rep-g?
I mean to say are you thinking Sailfish is the issue?
Have you reset the eeprom per the Sailfish directions via Rep-G?
What is the value in your toolhead offset?
Using the old system or the new system?

Sorry, it's just that there are tons of options and it's been
discussed at length before the variations of the toolhead offset
system.
Sailfish is compatible with either, provided you set the right
settings.
You have the old/new system setting
That then in turn affects the number calculated in the offset value
(some people have seen it go from 30something to 330 something)

So yes, not following the reset rule is the first place to get in
trouble, then understanding and using the correct old or new offset
system is required, then ensuring the correct value is stored in the
offset.

[Jetguy]

Also, if I were trying to figure out the problem with the unknow tool
(Kisslicer), I would follow the directions as I have stated with the
reset of onboard preferences to factory defaults from within rep-g
40R18 Sailfish.
That then sets it to the new sytem and ensure correct baseline values
are there.
Warning, the only value not correct it the X homing offset which needs
reduced since the default is for a single head. We have no good way of
detecting single VS dual, the mainboard is the the same, the firmware
is the same. Assumption is, most people have the single and hence why
they got the correct default. http://www.makerbot.com/sailfish/troubleshooting/#3
"You will likely want to reduce the X home offset by about 16.5 mm;
e.g., reduce it from about 152 mm to about 135.5 mm"

Then attempt a dual print from Rep-G
That should work with no issue.
Then try the Kisslicer
If it works- you're done.
If not, then change to the old system in the settings

[Dan Newman]

On 17 May 2013 , at 1:03 PM, Spk64 wrote:

> Anyone having success with Sailfish, Dual Extruders and Kisslicer or Repg?
> What is the correct Tool change?
> M6 does not work

M6 means to wait for the tool to come to temperature.

> M135 seems to be outputting from Makerware in the Gcode export but this
> does not work.

MakerWare has it's own set of mcodes unique to it. Lovely, eh? If you
want to use MakerWare specific mcodes, then you need to use MakerWare to
convert your gcode to x3g.

> Tried M54 and M55

M54 and M55 are for recalling coordinate offsets.

M108, believe it or not, is the tool change code. It's what RepG has
used for quite some time for dualstrusion. Here's it lifted from some
RepG -generated dualstrusion code,

M108 T1(Set tool)
…
M108 T0(Set tool)

Dan

[Spk64]

Thanks Dan that is the type of info I was looking for.
I will do some further testing with M108.

I had done the reset on the board and my offsets were near 0. The extruder offset was set to new.
If it is set near zero should the setting read old?

I was able to print close to correct by slicing in repg and printing.
Now just need to get KS to work.
Bad thing is It will be Monday before I can test further.

Steve

[Dan Newman]

On 17 May 2013 , at 2:56 PM, Spk64 wrote:

> Thanks Dan that is the type of info I was looking for.
> I will do some further testing with M108.
>
> I had done the reset on the board and my offsets were near 0.

Correct. If the X toolhead offset is near 0 mm OR near 33.0 mm
(35.0 mm for Rep 2X), then the firmware auto-adjusts it to suit
the choice of Toolhead Offset System.

> The extruder offset was set to new.
> If it is set near zero should the setting read old?

No. OLD vs. NEW only depends upon whether your gcode has offsets
built in via G10/G54/G55. If it has the offsets built in, then use
OLD. If it does not, then use NEW. There's some info which may
prove helpful at

http://jettyfirmware.yolasite.com/v71-v42.php#a7

Dan

[Spk64]

Now it all makes sense. The link had some great info.

Thanks,

[Dan Newman]

On 17 May 2013 , at 2:56 PM, Spk64 wrote:

> Thanks Dan that is the type of info I was looking for.
> I will do some further testing with M108.

So, an M6 will implicitly change the tool.

If you look in RepG sources, the gcode parser and the "machine model" treat M6 as
a tool change: it's called that in the sources and comments. In response to an
M6 in the gcode, RepG calls in the machine driver a routine
named requestToolChange. Bit, if you look in the machine drivers for makerbots
at the requestToolChange routines, you will see that what happens is that an
s3g command to wait for the tool to come to temp is sent. There is an s3g
"change tool" command. That is NOT sent: a "wait for tool" is sent.

In the machine drivers, there's an entirely different routine called selectTool()
which issues an explicit s3g "change tool" command.

BUT then, if you look in the firmwares, you will see that the processing
of a "wait for tool" command does an implicit tool change!

So, in theory you can use an M6 to do a tool change. However, I recommend
against it. It'll suddenly put the bot into a pause & wait state which,
while quickly satisfied, isn't what you want. Also, it isn't recognized
correctly by a different part of the firmware which watches for commands
which occur during active printing and require the planner queue to be
emptied. So, if you use an M6 to change tools during active printing,
things may not behave correctly.

Dan

[Spk64]

I was browsing through the gcode parser for repg and it appears M108 is no longer supported and it was setting the rpm.
The only mcode I noticed that was calling for a tool change was M6.
So now I am back to confused again.

[Dan Newman]

On 17 May 2013 , at 4:24 PM, Spk64 wrote:

> I was browsing through the gcode parser for repg and it appears M108 is no longer supported and it was setting the rpm.

M108 "R" and "S" is commented out by replace.csv. M108 T is not and is still supported
and still works. I just checked with RepG 40r17 - Sailfish producing an x3g and then
dumping it: the M108 Tn commands result in s3g/x3g tool change commands.

Dan

[Zack]

FYI, I convert the gcode using makerware. I found it does the best job in recognizing the M135 code and making the tool change work. I found with RepG the M135 code was not reconized. I kind of figured that makerware would be more tailored to the 7.2 firmware on the Rep 2X.


On Tuesday, May 21, 2013 10:37:28 AM UTC-7, Zack wrote:

Hello Everyone,
Ive got a Replicator 2X and I've finally got my tool change to work. Took me awhile. The hardest part is getting it to print consistently with two heads but I think most of that has to do with the extruders. I plan on upgrading to aluminum ones soon.

All I do under the "select extruder" gcode is add:
; Select new extruder
M135 T<EXT+n>

That is it. Nothing under deselect or anything.

This is my prefix.

M136 (enable build)
M73 P0
G162 X Y F2000(home XY axes maximum)
G161 Z F900(home Z axis minimum)
G92 X0 Y0 Z-5 A0 B0 (set Z to -5)
G1 Z0.0 F900(move Z to '0')
G161 Z F100(home Z axis minimum)

M132 X Y Z A B (Recall stored home offsets for XYZAB axis)

G92 X152 Y72 Z0 A0 B0
G1 X-112 Y-73 Z150 F3300.0 (move to waiting position)
G130 X20 Y20 A20 B20 (Lower stepper Vrefs while heating)
M109 S110 T0
M134 T0
M104 S230 T0
;M104 S230 T1
M133 T0
;M133 T1
G130 X127 Y127 A127 B127 (Set Stepper motor Vref to defaults)
M135 T0
G1 X-105.400 Y-74.000 Z0.270 F1800.000 (Right Prime Start)
G1 X105.400 Y-74.000 Z0.270 F1800.000 A25.000 (Right Prime)
;M135 T1
;G1 X105.400 Y-73.500 Z0.270 F1800.000 (Left Prime Start)
;G1 X-105.400 Y-73.500 Z0.270 F1800.000 B25.000 (Left Prime)
G92 A0 B0 (Reset after prime)


;M135 T1
;G1 B-12 F300
;G92 B0
(**** end of start.gcode ****)

I have to mod it here and there when using dual extruders but all and all its been working.

Glad to finally have contributed something after reading these forums for months.

Zack

[Dan Newman]

On 21 May 2013 , at 11:34 AM, Zack wrote:

> FYI, I convert the gcode using makerware. I found it does the best job in
> recognizing the M135 code and making the tool change work. I found with
> RepG the M135 code was not reconized.

That's because MBI added M135 recently. For whatever reason, they chose
to not use the mcode they had used for over a year with RepG and picked
a new one. If you want to use RepG, then use M108 like RepG has used
ever since MBI started doing dualstrusion.

Dan

[Dan Newman]

Or, put differently, if you want to use RepG then you gotta use the g & mcode
usage RepG supports. If you want to use MW, you use the g & mcode usage it
supports. Also, you should consider using GPX (which I believe maps more
closely to RepG since RepG was open source).

Of course, you'd have much less difficulty if the DIY 3d printing world
actually read and followed the gcode standards.

Dan

[Zack]

"Of course, you'd have much less difficulty if the DIY 3d printing world
actually read and followed the gcode standards. "

AGREED!

[Spk64]

I still have not been able to slice a file is Kisslicer using any of these M108, M6, M135 (M135 will not convert and error is thrown in Repg) in the select extruder gcode section process with GPXconverter or repg and have the printer apply the offset. It does start printing out of the selected extruder, just in the wrong place by approximate 35mm.
My test in Kisslicer is just a 20mm cube with raft and setting a seperate extruder for the raft. Raft prints fine with extruder 1 in the correct location. When the part starts printing with extruder 0 it is printing with extruder 1 over the raft and extruder 0 in air.

I have had success slicing a file in Repg and combining 2 Stl files. It prints with the offsets applied.

Also just to provide further background running sailfish 7.4 and repg 40-r16.
I have done the reset to factory several times. Went back and reviewed the offsets per the links provided.

[Dan Newman]

On 21 May 2013 , at 5:44 PM, Spk64 wrote:

> I still have not been able to slice a file is Kisslicer using any of these M108, M6, M135 (M135 will not convert and error is thrown in Repg)

Of course M135 won't work with RepG: it's an ad hoc mcode supported only by MakerWare.
In DIY 3D printing, gcodes and mcodes are not standardized. If you intend to use
a gcode processor then you need to stick to the codes it supports. It's a drag that
you have to do that, but that's the way it is. MBI introducing new mcodes this way
doesn't really help matters much, but that's their business.

> in the select extruder gcode section process with GPXconverter or repg and have the printer apply the offset.

Offset? Are you trying to use the no longer supported G10 / G54 / G55 codes? Those were abandoned
by MBI and RepG back in 2012.

Dan

[Dan Newman]

On 21 May 2013 , at 6:38 PM, Dan Newman wrote:

>
> On 21 May 2013 , at 5:44 PM, Spk64 wrote:
>
>> I still have not been able to slice a file is Kisslicer using any of these M108, M6, M135 (M135 will not convert and error is thrown in Repg)
>
> Of course M135 won't work with RepG: it's an ad hoc mcode supported only by MakerWare.
> In DIY 3D printing, gcodes and mcodes are not standardized. If you intend to use
> a gcode processor then you need to stick to the codes it supports. It's a drag that
> you have to do that, but that's the way it is. MBI introducing new mcodes this way
> doesn't really help matters much, but that's their business.

I'll also add that MBI added some of these new mcodes because they felt they
simplified things. My guess is that someone working on MakerWare simply didn't
like the way things were done, had an idea for how to do it better, and implemented
it. In the process they dismissed the fact that doing so causes confusion and
frustration for the larger world including their customers and third-parties
they'd like to have support their stuff (e.g., slic3r, KISSlicer). My comment
to MBI when I learned of this last year was that if they truly wanted to
simplify things and were willing to introduce some pain as they were doing,
then they should bite the bullet and cut over to NIST standard gcode and be
done with it.

Anyway, people making changes like this is clearly one of my hot buttons. I can
assure you that engineers have no problem coming up with better ideas. It's knowing
when to walk away from them which is the hard part.

Dan

[Spk64]

No, I am not using the G54,G55,G10 offsets. The printer is not moving the active nozzle to the correct location to print. I will run the test again tomorrow with the preferred M108 and see what happens. Will then post the gcode to examine.

[Dan Newman]

On 21 May 2013 , at 7:15 PM, Spk64 wrote:

> No, I am not using the G54,G55,G10 offsets. The printer is not moving the active nozzle to the correct location to print. I will run the test again tomorrow with the preferred M108 and see what happens. Will then post the gcode to examine.

See

http://jettyfirmware.yolasite.com/v71-v42.php#a7

for a description of how toolhead offsets work with Makerbot printers.

The "modern" expectation is that
the gcode has NO offsets. Were you to see it in a gcode viewer, then the motions of
the two extruders would be properly aligned with no offset between them. Only the
bot is aware that an offset exists and it automatically handles it. This is the
only style handled by the MBI firmware since 6.x. In Sailfish, this is the default
and is explicitly requested by setting Utilities > General Settings > Toolhead Offset System
to the value "NEW".

The "old" expectation was that the offset was actually handled in the gcode itself
via G10, G54, and G55 commands. The bot then only new of the deviation from the
ideal offset. MBI firmwares do not support this system. Sailfish does if you
set Toolhead Offset System to "OLD".

Dan

[Dan Newman]

And, of course, the STL's are NOT supposed to be offset from one
another.

Dan

On 21 May 2013 , at 7:15 PM, Spk64 wrote:

> No, I am not using the G54,G55,G10 offsets. The printer is not moving the active nozzle to the correct location to print. I will run the test again tomorrow with the preferred M108 and see what happens. Will then post the gcode to examine.
>

[Spk64]

ok,  more details on the problem I am having.

Attached Gcode is from Kisslicer using the M108 T<EXT+0>  token to insert the proper T1 or T0 in the "Select Extruder" gcode section.

Sailfish Firmware 7.4  Tool Offset Sys set to "New" (See image)

Offsets in firmware currently set to 0 on both x and y. (See Image)

Gcode start script seems to print fine and place my anchors and purge exactly where expected.  Raft prints where it is expected.  But when the extruder is changed it starts printing the part it is in the wrong location. (See image)

Gcode converted with RepG

I have attached a view of the Gcode to show the raft and part properly placed. (See Image)

This morning I also ran the Nozzle Calibration Script within RepG and it printed with lines where they were expected to be.

[Dan Newman]

Check the toolhead count. If it's not set to "2" you will see
exactly this behavior. You can set that via RepG's machine >
onboard preferences or via the LCD display. You should power
cycle the bot after effecting that setting.

Dan

> --
> You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

> <20mm_Calibration_Box.gcode><Gcode.jpg><LCD.JPG><Prefs.jpg><Print.JPG>

[Dan Newman]

Also, if you use a known good dualstrusion model with RepG 40rX - Sailfish,
slice it, and print it, do things then work? That is, have you eliminated
bot configuration from the equation and reduced it to just a gcode issue?
I.e., figuring out what KISSlicer's gcode needs to look like? Or are there
still other unknown variables such as whether dualstrusion is working at
all with this bot and its configuration?

Dan

On 22 May 2013 , at 7:41 AM, Spk64 wrote:

[Spk64]

I have finally solved this problem.

Switching back to the Makerbot No G92 E0 firmware version which eliminates all the G92 E0 resets has allowed the M108 to work correctly.

With the G92 E0 placement and where the tool change takes place,  it caused all kinds of problems with adjusting the extruder head.

This works.  Standard Gcode with Kisslicer and no G92 E0 reset

M108 T1

M104 S230

G1 X13.37 Y3.47 Z0.75 E54.5279 F9000

G1 X13.37 Y3.47 Z0.5 E54.5279 F210

M101

This version with the G92 E0 will not work.  Correct Extruder spits out plastic but in the wrong location.

M108 T1

G92 E0

G1 X13.37 Y3.47 Z0.75 E0 F9000

G1 X13.37 Y3.47 Z0.5 E0 F210

M101

Manually moving M108 T1 after the G92 E0 also will work but would take some scripting to change this automaticly in the Gcode files.

G92 E0

M108 T1

G1 X13.37 Y3.47 Z0.75 E0 F9000

G1 X13.37 Y3.47 Z0.5 E0 F210

M101

[Dan Newman]

Some comments

1. G92 doesn't work correctly with MBI's firmware

2. G92 won't work well over USB from RepG and likely not MakerWare either.
When done over USB, RepG queries the bot for its current position. And
querying for the position is no longer supported. MBI killed that in the
5.x firmware days. (I don't know if they realized that, but they did.)

3. G92 from an s3g/x3g file has had several bugs in RepG's translation from
gcode to s3g/x3g. I've fixed a couple of them. There may be more.

But, the underlying problem here is that s3g/x3g does not have a command equivalent
to G92. It has a command to set the absolute postion in (x,y,z,a,b) space. So,
when the switch tool happens, the bot switches tools and then sets its absolute
position from (x,y,z,a,b) to (x+35,y,z,a,b) or (x-35,y,z,a,b). Then comes along
a G92 command. But there's no s3g equivalent. So RepG, which tries to track
what it believes is the current coordinate and generates a command telling the bot
to set its absolute position to (x,y,z,0,b). Whoops -- the +/- 35 got lost.
(or +/- 33 for a Rep 1 dual). So, while G92 mixes well with dualstrusion,
the mapping of G92 to s3g does not owing to a mismatch. I'm become very
tempted to implement a new x3g command which DOES map to G92 and implement
it and pass it on to Wingcommander for GPX. All that needs doing is to
add one additional byte which is a bit mask indicating which of the
X,Y,Z,A,B fields to actually honor in the "set position" command. The
old set position command would then just be the new command with 0x1F
for the byte of bits.

Dan

[Spk64]

Without a G92 and RPM now gone and using Absolute E.
What should we use for a purge or prime in the start Gcode?

[Dan Newman]

On 22 May 2013 , at 6:15 PM, Spk64 wrote:

> Without a G92 and RPM now gone and using Absolute E.
> What should we use for a purge or prime in the start Gcode?

Extrude some filament. E starts at zero when you recall
the home position. You have to extrude 21.4 km of filament before
there's a problem and you need to reset the E steps (assuming 100
steps/mm). That said, you can still use RPM for the anchor --
Wingcommander does, for example.

Some random comments:

0. I believe that funbart worked out the ins and outs of using
KISSlicer with dualstrusion earlier this year or late last
year.

1. G92 is only an issue with dualstrusion and even then it
appears to be only an issue with the order in which you
use it in relation to the M108.

2. There were actually bugs in RepG associated with using
RPM. Wingcommander spotted them. So, only a tiny violin
is needed as regards RPM being gone ;)

Dan

[David wundel]

I use this code for kisslicer

(**** Select Gcode extruder change***)

G55

M108 T<EXT+n> (Set tool)

M18 A B

G1 F9000,0

And GPX to export the gcode and it´s works