Using Temperature set points to combat ABS warp & corner lifting.

[Steve Johnstone]

Yesterday I tried printing clear ABS for the first time. My first try failed at about 20 minutes into the print. The cause was typical heat creep and air printing symptoms in the extruder.

It was lovely to hear the extruder motor skipping for a change thanks to Dave’s 3 in 1 extruder upgrade (one more variable I can take out of the equation when identifying problems).

I printed a couple of calibration cubes with the new filament prior and had probably some of the worst build plate corner lift and distortion to date. This also showed on the failed print.

At first I thought they must have sent me clear PLA. As there was no label on the spool I deducted that it was ABS by putting a piece in acetone and it did eventually get sticky.

To stop the corner lift / distortion issue I tried something I had been thinking about for a while. In Simplify 3D I added build plate temperature setpoints to help control the overall temperature, especially at the base, during the print. For a while I have thought that the corner lift problem may be due to the temperature of mid portion of the print dropping below that of the base. Remember that the base of an ABS print is normally held at constant 110c.

The effect of the cooler shrinking mid-section then pulls the hotter, softer base corner sections up. As Jetguy said in another post “you are fighting against nature”.

In an ideal world you would want to have the part all cool at the same rate. We are unable to do this on the 2X but I thought that if I could bring the differential temperatures in the part closer together it should help.

The first successful print started with the build plate at 115c. This decreased every 5 layers to 90c and remained at this temperature until the end of the print.

30 minutes into the print I was concerned that the aluminium extruder block was getting to hot so thought “too hell with it” remove the lid, opened the door and setup the office fan to blow into. It worked a treat :)

Other things that to add to the mix is that I have upgraded the extruder fans and I’m using thermal past on the heat sink to aluminium block contact areas. I also used it on where the thermal tubes clamp / contact the block (thanks for the recommendations and links TaErog).

These’s a video with some other detail and time-lapse on YouTube.

You can download the Goblet STL on Thingiverse

[Kobus du Toit]

When I print ABS on the 2X

I switch on the aircon in the room and set it to 24 C and open the door and the top of the printer

I heat the build plate to 130 C

I have a big jar of ABS/Acetone mix, nice and thick.  I poor that onto my glass build plate when the temp reaches 130 C and then roll the mix over the glass with a mini paint roller

I then use a 120 grit sanding block to sand it down so that I have a nice flat surface and I leave the dust on the glass build plate

I reduce the build plate down to 110 C when building.  This reduced heat helps it seems, I don't have both extruder fans coming on anymore while printing.

When the print is done

I remove the glass plate and place it on the kitchen sink for a bit so that most of the heat can be taken up by the sink

I switch on the warm tap water and then poor it over the glass plate after a couple minutes.  I reduce the temperature bit by bit.  When I am happy with the temp I place it in the freezer.  10 minutes later the print pops off and most of the rolled on mix

I clean off the mix and then I repeat the water process but starting from cold to warm and then place the glass plate on the machine again, but I don't attach it with my clamps.  I just leave it on the build plate so that the water vapor can escape.  When it reaches 130 C I start over

This isn't perfect, I do still have extruder blockage on and off, but it is what works for me most of the time

[Michael Nichol]

so the simplify 3d creator can be used on the makerbo 2x..

 

do you like the software..??

[Jetguy]

I like the software provided you use these profiles by Enginwiz http://www.thingiverse.com/thing:147628

 

That's the only downside, the stock profiles in the software need a little tuning and thankfully members provided that.

 

The problem is for you, those profiles:

Aren't profiles, they are complete build enviroments (not necesarily a bad thing, just something to know)

Are for a Replicator 2 single head with no heated bed.

And, require significant mods to turn them into working profiles for the 2X with a heated bed and dual extruders.

 

I really, really like the software and met the developer, Clayton, at Maker Faire and I know he is working on updates to the software and does listen to suggestions and improvements.

 

I was specifically using Creator with my Ulti-Replicator based on the Replicator 1 and so I too have a heated bed (a really big one at that).

 

At the same time, Makerware came out with the new dualstrusion features and several fixes and I pretty much have recently focussed on using that and was waiting for updates on Creator rather than trying to build up custom profiles.

I really do like the software, the built in repair functions are great, the slicer is fast and accurate. It is a good software that only is going to get better, and better. It's great now, you just are best served using those profiles with some edits.

 

And what I meant by they aren't profiles. It's kind of like Makerware "thing" files. It includes the STL object and the settings being used at the time. I think of a profile as just the settings used to create the gcode. The software certainly provides the features to save both types (just a profile or the whole environment), Enginwiz chose to post the full environment which lets you do an easy test print and validate you are happy the profile works for you.

Nothing wrong with any of it, just an observation I felt should be explained.

 

Again, I have no issue justifying the cost of this commerical software based on the speed of slicing, ease of use, and the extra features such as repair and manual support material.

In the same way some other slicers have gone commercial, this is the way of the future.

 

The thing is, we have so many options these days it's hard to give a statement saying anything is the best and you should ignore all other software. For example, meshmixer has some very cool support structure. Creator has great repair functionality built in. Makerware is now getting better at dualstrusion printing. There are lots of other slicers out there as well.

 

For me, I was a diehard user of Rep-G (Sailfish edition with Pypy) but the new bot and it's huge build area was causing me problems slicing huge scaled up STL files. Heck, even bigger STLs from thingiverse can take forever to slice and sometimes crash the program. This more or less forced my hand to try other slicers. I've had a license to Creator for a while and finally got around to configuring it for the new bot. It's my fault for having a custom bot, otherwise it would have been click-n-print from the start. I knew how to edit rep-g for custom bots, I had had trouble in the past trying to get makerware customized, and there was a learning curve to getting Creator setup. Truth is, it's not even hard it's just something I had to sit down and take the time to go through.

 

The key difference here as I see it is there are basically still 2 camps of software/firmware out there. Reprap and Makerbot are fundamentally different because MakerBots use X3G files to print, which is a binary encoded file based from gcode with precalculated functions such as steps per mm built in. X3G is not human readable code. It's is highly specilized for the machine it was made for (X3G files made for a 2X will not print correctly on an original Replicator Dual and so on).

Rerap firmware (Marlin, Repetier, and other variants) and the matching software, produces straight gcode or human readable text.

The point being, to use certain other "Reprap" slicers with a MakerBot, you must use a utility such as GPX by the great whpthomas to convert the output gcode to an X3G file to print in your MakerBot.

The only products I personally have used (others may do it, I haven't tried them all) that do fully automatic conversion and printing with a MakerBot are:

Makerware

Rep-G

Simplify 3D Creator

 

So again, you kind of have to put the bigger picture into context, right now, Creator is the first commercial software to try and work in the MakerBot space.

You can print with all kinds of different combos of software, just some require more work than others to get from STL to X3G.

[Enginwiz]

Today I finally got Simplify3D Creator 1.1.5 and GPX 1.3 to heat up the Bottleworks heated build plate in my Replicator 2.

The trick was to select a Replicator 2X for postprocessing in Simplify3D Creator and configure GPX.ini for a Rep2 with HBP.

I am tuning in ABS settings and had problems with calibration cubes staying gooey during the whole print. At 100°C HBP temperature 

the whole ABS part stayed soft. It was possible to deform a calibration cube like clay immediately after the end of the print.

The parts were printed with white Octave Jet-ABS at 215°C. My Rep 2 has no doors and no hood and the room temp is around 20°C.

So this really was a surprise.

At 90°C HBP temperature the bottom of the parts still stick well to the heated glass plate with a layer of Garnier Fructis #5 and the 

higher regions of the print are nearly solid. I tried to reduce the nozzle temperature from 215°C to 208°C degree by degree

using the layer based temperature settings in Simplify3D Creator. This also looks promising. Maybe the combination of

slowly reducing HBP and nozzle temperature during the print is the perfect way to get flat bottom regions and good surface

quality with ABS.

[Steve Johnstone]

I agree with everything above and see S3D just as another tool in your toolbox.

Yes it works perfectly well on the 2X but there is a bit of a learning curve. Enginwiz's profile are brilliant and have save me a huge amount of time. There is one thing I have learnt and that is, the profiles just as starting point, there are a huge amount of variables that are going to affect the print. It's not very often that I'm able to use the exact same profile on a different part. This is because every print is different and I'm always trying to get it better.

Now when my 14 year old wants to print something I get him to slice it with Makerware. Why? because it's very easy to use and 90% of the time it works perfectly. On the other hand like Jetguy, sometimes Makerware just isn't up to it. This goblet for example,  won't slice correctly in Makerware. Don't ask me why, but it struggles with the fine detail.

If you do use Enginwiz's profile on a 2X just make sure that you go in and change the machine dimensions or the extruder gantry will crash in the front left hand part of the frame before printing.

All programs are going to have the plus & minuses. I can only comment on what's working for me and much of that is derived from those who have come before. Is it worth the money? In may case yes.

It does everything that Makerware does and more.

I have only ever use Makerware & S3D so don't really feel I could comment on whether it's better then other slicers out there.

I also had a first today.... I managed to print the goblet in blue PLA. I have never been able to print PLA on my 2X. I only tried it because other users posted their experiences and decided to give it a crack based on yesterdays success with the clear ABS.

This is the important bit... the slicing program was only part of solution in this example. Other factors were -

• Upgraded extruder - 3 in 1 by Dave,
  
• Upgraded Fans, and use of thermal paste - recommended by TaErog
  
• Upgrade Aluminium Carage by Carl (kindly donated by Eighty)
  
• DIY glass build plate - recomendation by Jetguy
  
• 0.2mm PLA Slicing profile by Enginwiz.
  
• Everyone else who contributes in these groups

 

 

My first successful PLA print on the 2X :-)

 

[Jimc]

Just any fyi, i talked to clayton yesterday and the new update is going to roll out in a couple weeks. Its supposed to be going into the beta testing this week coming up. He tells me this is a big update. Its been a long time since they had a release and will have alot of new cool features......so im told

[Enginwiz]

With one layer of Garnier Fructis #5 on the heated build plate is possible to reduce the HBP temperature

step by step from 90°C to 70°C during the print and still have the ABS part firmly sticking to the build plate.

This increases convective selfcooling of the ABS part and the recently printed upper surfaces

are less gooey. Still there were no cracks and no corner lifting during the print.

To get better bridging at the top of the hole I decreased the nozzle temperature

step by step from 215°C to 205°C during the print. 

After removing the glass plate I took pictures of the bottom of the print through the glass plate.

2 minutes after the print the outer edges of the part start to lift from the hairspray. 

5 minutes later the build plate has cooled down to around 40°C and the part separates itself from the hairspray layer.

The bottom of the printed part is flat and the part has no cracks and a nice surface finish.

On the glass plate the layer of Garnier Fructis #5 stays intact and it is possible to print

the same part on the same spot again.

[Steve Johnstone]

Great work Enginwiz!

It great being able to control both the bed and extruder  temperatures during the print. It would be great for people doing production type runs of part as you could really dial in the settings.

I'm going to try a dual goblet with the Blue PLA base and frame and the Clear ABS for the cup.

[Dan Newman]

And for folks who don't know, if you want to play with changing the extruder temp
during a print, you're better off changing it by no more than 10C at a time from the
current target temp. If you change it by 11C or more from the current target temp,
then the firmware resets the entire PID state and you're subject to larger over or
undershoots. This is true of both MBI's firmware and Sailfish.

Dan

On 16 Nov 2013 , at 12:52 AM, Enginwiz wrote:

> With one layer of Garnier Fructis #5 on the heated build plate is possible
> to reduce the HBP temperature
> step by step from 90°C to 70°C during the print and still have the ABS part
> firmly sticking to the build plate.
>

> <https://lh6.googleusercontent.com/-2dLygLsZbiY/Uocs11j3RiI/AAAAAAAAAgc/ie7Qm3aUAZg/s1600/Screenshot+2013-11-16+09.21.16.png>

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> This increases convective selfcooling of the ABS part and the recently
> printed upper surfaces
> are less gooey. Still there were no cracks and no corner lifting during the
> print.
>

> <https://lh4.googleusercontent.com/-zGG5GnpmIlk/Uoctv_tF-PI/AAAAAAAAAgk/JjbDPpraqpE/s1600/2013-11-16+08.47.59.jpg>

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> To get better bridging at the top of the hole I decreased the nozzle
> temperature
> step by step from 215°C to 205°C during the print.
>

> <https://lh5.googleusercontent.com/-l-LhzBLxfB8/Uocve_im1qI/AAAAAAAAAgw/DrIP2yz9uQg/s1600/Screenshot+2013-11-16+09.39.16.png>

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> After removing the glass plate I took pictures of the bottom of the print
> through the glass plate.
>
> 2 minutes after the print the outer edges of the part start to lift from
> the hairspray.
>

> <https://lh4.googleusercontent.com/-FYqWYII0jZI/UocwT1AlLBI/AAAAAAAAAg4/X6l7zjwEkW0/s1600/2013-11-16+08.49.06.jpg>

>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 5 minutes later the build plate has cooled down to around 40°C and the part
> separates itself from the hairspray layer.
>

> <https://lh6.googleusercontent.com/-wSGnq8PCmtU/UocxBuN8ugI/AAAAAAAAAhE/oUROh61rvX4/s1600/2013-11-16+08.50.51.jpg>

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The bottom of the printed part is flat and the part has no cracks and a
> nice surface finish.
>
> On the glass plate the layer of Garnier Fructis #5 stays intact and it is
> possible to print
> the same part on the same spot again.
>

> --
> 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.

[Dan Newman]

On 16 Nov 2013 , at 7:23 AM, Dan Newman wrote:

> And for folks who don't know, if you want to play with changing the extruder temp
> during a print, you're better off changing it by no more than 10C at a time from the
> current target temp. If you change it by 11C or more from the current target temp,
> then the firmware resets the entire PID state and you're subject to larger over or
> undershoots. This is true of both MBI's firmware and Sailfish.

P.S.

1. I'm mentioning this just to remind folks. I doubt that Engiwiz was making changes
larger than 10C at a time.

2. The same applies to the HBP -- the state reset. However, it's immaterial as the
"PID" control in the firmware for the HBP doesn't do actual PID. It's just "bang-bang"
style. I.e., PWM techniques to get power levels other than 0% and 100% to the HBP are
not used. The HBP power is either completely on or completely off. The extruders have
intermediate power levels between on and off (1/255 all the way to 254/255). As such,
resetting the PID state on the HBP doesn't have nearly as significant of a consequence.

Dan

[Rick L.]

So... am I understanding that one way to accomplish the change in temps during the build is to simply edit the gcode at appropriate places with these lines?

Hypothetical beginning of print... 

M109 S110 T0

M104 S230 T0

M104 S230 T1

Hypothetical middle of print...

M109 S120 T0

M104 S220 T0

M104 S220 T1

Hypothetical last third of print...

M109 S100 T0

M104 S220 T0

M104 S220 T1

[Steve Johnstone]

Thanks Dan, I didn't know any of that.

[Enginwiz]

Hello Dan,

thank you for explaining the PID reset after a temperature change of more than 10°C.

Reducing the nozzle temperature even slightly during the print results in an undershoot and a recovery phase. 

The PID temperature regulation of the nozzle temperature might still need some fine tuning.

My ABS print temperatures around 210°C are already near the lower end of the printable range.

Therefore I reduce the temperature step-by-step in increments of 2 or 3 degrees Celsius and

wait some layers before the next reduction. Otherwise the undershoot of the nozzle temperature

could lead to a blocked nozzle and a print failure.

For me it is was pleasant surprise that the HBP together with the Garnier Fructis #5

make ABS prints stick firmly even at relatively low HBP settings of 70°C. I measured

the top surface temperature of the glass plate with a high accuracy thermocouple

contact sensor and got readings about 10°C to 12°C lower than the display values on the bot.

So it is really around 60°C instead of the 70°C on the display (a normal difference from sensor

to surface) and the HBP temperature regulation works as it should.

Initially I used too much hairspray and a piece of glass got chipped off the build plate surface

during cooling after the print. With a HBP there is much more adhesion force available than we need.

I will try to reduce the preheat temperature from 90°C to 80°C and check wether this makes a difference.

Starting with lower HBP temperatures would save time in the preheat phase before the print.

Steve - your goblet came out beautiful. Please post a picture of the PLA / ABS version.

 

[Clinton Hoines]

I've been using the Garnier hairspary for almost a year now with ABS and PLA works perfect for PLA at anything above 50deg and with ABS anything over approx 80 deg. The larger the print area or higher infill the higher the temp I use for ABS up to about 98 deg, after that it will let go after around 20mm build height.

[Dan Newman]

On 16 Nov 2013 , at 1:24 PM, Enginwiz wrote:

> Hello Dan,
>
> thank you for explaining the PID reset after a temperature change of more
> than 10°C.
>
> Reducing the nozzle temperature even slightly during the print results in
> an undershoot and a recovery phase.

Agreed: MBI's PID is tuned more towards not overshooting. The way it
is tuned, it undershoots more significantly. You can always tune it yourself
and then set the PID parameters you wish to use for the extruders. (Or at
least RepG lets you set them.) I've not seen an interface to let you
set the PID parameters for the HBP but those are also saved and recalled
from EEPROM so changing them is possible as well given a UI to do so.
(or using s3g.py you could do it.)

That said, I've been pretty pleased myself with the PID tuning MBI uses: it's
worked reasonably well for me all these years. That in contrast to some of the
tunings I've had on other bots.

Dan

[Dan Newman]

On 16 Nov 2013 , at 8:19 AM, Rick L. wrote:

> So... am I understanding that one way to accomplish the change in temps
> during the build is to simply edit the gcode at appropriate places with
> these lines?
>
> Hypothetical beginning of print...
> M109 S110 T0
> M104 S230 T0
> M104 S230 T1
>
> Hypothetical middle of print...
> M109 S120 T0
> M104 S220 T0
> M104 S220 T1
>
> Hypothetical last third of print...
> M109 S100 T0
> M104 S220 T0
> M104 S220 T1

Mostly correct. Just realize that in the gcode to s3g/x3g conversion
process those Tn commands can trigger a tool change. So, if you're
doing dualstrusion and the gcode is expecting T0 (right) to be being used,
that M104 S220 T1 command at the end of the triplet will likely cause
a switch to T1 (left extruder) as the extruder.

Dan

[Steve Johnstone]

Enginwiz, I had the exact same glass chip experience when I first started using hairspray on the glass. It was almost like the glass had delaminates on the surface directly under the print. It's good to know what caused it.

The dual material goblet is as challenge, still working it all out, but as soon as I have a solution will let you know.

[Wingcommander]

> Hypothetical last third of print...
> M109 S100 T0
> M104 S220 T0
> M104 S220 T1

So GPX has a temperature control macro that already does this for the primary extruder, so I am going to investigate how I can adapt it to Dow what you are proposing. In theory you would just add something like the following to your GPX.ini and it would insert the temperature change commands at the appropriate layer height.

[macro]
temperature: 3.0mm 220c 90hbp
temperature: 5.0mm 210c 80hbp

But I will have to look at the parser to decide on the exact syntax

> Mostly correct. Just realize that in the gcode to s3g/x3g conversion
> process those Tn commands can trigger a tool change. So, if you're
> doing dualstrusion and the gcode is expecting T0 (right) to be being used,
> that M104 S220 T1 command at the end of the triplet will likely cause
> a switch to T1 (left extruder) as the extruder.

GPX treats these differently. Only an M6 or a naked T0 or T1 causes a tool change. All other G and M codes that contain a T reference, are only supposed to advance that tool in the tool carousel (according to the NIST standard anyway) so GPX does the same in a virtual sense i.e. You can change the temperature of a tool without changing the current tool - unless this triggers a tool change in sailfish? I have never actually checked.

[Wingcommander]

Actually there is also M135 - the new tool change command introduced by makerware.

[Jamesarm97]

I figured I would try one. Going to print in trans yellow next.

[Wingcommander]

OK, that was a pretty easy change to make. So I have added support to the GPX @temperature macro to change both nozzle and build platform temperature at designated z positions in the build.

You can either stick the macro at the bottom of your gpx.ini file as follows... (the start temp is optional).

[macro]

start: 230c 100c

temperature: 3.0mm 220c 90c

temperature: 5.0mm 210c 80c

temperature: 7.0mm 70c

or you can add it to the end of your start.gcode for Cura, Slic3r and S3DCreator

;@start 230c 100c

;@temperature 3.0mm 220c 90c

;@temperature 5.0mm 210c 80c

;@temperature 7.0mm 70c

;@body

or for KISSlicer (which strips ;comments) 

(@start 230c 100c)

(@temperature 3.0mm 220c 90c)

(@temperature 5.0mm 210c 80c)

(@temperature 7.0mm 70c)

(@body)

It should work - however it has only had limited testing. Sources are on github here https://github.com/whpthomas

and a Mac binary (ver 1.5) can be downloaded here http://www.thingiverse.com/thing:81425

Once I have had a chance to test more thoroughly I will release a Windows binary as well.

[Rick L.]

Awesome. Thanks and time to do more learning!

[Wingcommander]

[macro]

start: 230c 100c

temperature: 3.0mm 220c 90c

temperature: 5.0mm 210c 80c

temperature: 7.0mm 70c

I forgot to mention that the order of macro variables is unimportant, GPX uses the suffix to interpret what they mean, and temps above 120c are assumed to be nozzle temp changes and temps equal or below 120c are assumed to heated build plate temperatures.

For these macros to work, you must include the 

;@body

or 

(@body)

at the end of your start.gcode file so GPX knows when to start paying attention to Z heights.

 

[Dan Newman]

> GPX treats these differently. Only an M6 or a naked T0 or T1 causes a tool change. All other G and M codes that contain a T reference, are only supposed to advance that tool in the tool carousel (according to the NIST standard anyway) so GPX does the same in a virtual sense i.e. You can change the temperature of a tool without changing the current tool - unless this triggers a tool change in sailfish? I have never actually checked.

Tool changes at the firmware level require either

1. An explicit change tool command, or
2. An explicit wait for tool command.

So as long as GPX doesn't issue either of those two commands willy-nilly, things
are okay. RepG definitely will change the tool when it sees a Tnnn in any command
starting with M. The comment below notwithstanding, if there's a "Tnnn" in that
"M" line, it addes to the stream a change tool command.

private void buildMCodes(GCodeCommand gcode, Queue< DriverCommand > commands) throws GCodeException {
// If this machine handles multiple active toolheads, we always honor a T code
// as being a annotation to send the given command to the given toolheads. Be
// aware that appending a T code to an M code will not necessarily generate a
// change tool request! Use M6 for that.
if (gcode.hasCode('T') && driver instanceof MultiTool && ((MultiTool)driver).supportsSimultaneousTools())
{
commands.add(new replicatorg.drivers.commands.SelectTool((int) gcode.getCodeValue('T')));
tool = (int) gcode.getCodeValue('T');
}

I've seen similar behavior from MakerWare but as MBI has been polishing their dualstrusion
support that may well have changed recently.

Dan

[Wingcommander]

Tool changes at the firmware level require either

1. An explicit change tool command, or
2. An explicit wait for tool command. 

So does that mean that Makerwares new M133 - Wait for extruder - is actually a tool change as well, even though they also have an explicit M135 for that as well?

[Wingcommander]

Tool changes at the firmware level require either

1. An explicit change tool command, or
2. An explicit wait for tool command.

Do commands like M190 - Wait for build platform to reach (or exceed) temperature - which also require a tool id also cause a tool change?

[Dan Newman]

Without looking at the x3g they generate, I have no idea. It's all in how
they translate gcode to x3g.

Dan

[Dan Newman]

Again, it's all in MakerWare's gcode -> x3g translator. And as they've
gone closed source, it's hard to know the complete picture since just
because it does or does not happen in one test case doesn't mean in
general it won't: there may have been some conditionals involved.

Dan

[Wingcommander]

Without looking at the x3g they generate, I have no idea.  It's all in how
they translate gcode to x3g.

OK I will rephrase my question...

Aside from 134 (change extruder offset) do both of the following x3g commands also cause tool changes?

135 - Wait for extruder ready
141 - Wait for build platform ready

[Dan Newman]

Those are MakerWare-specific mcodes. I have no idea offhand if they do or do not.
I'd need to install MakerWare in order to tell. (MakerWare is a fine slicer; however,
I do not keep it installed as it leaves "stuff" around such as code off in
system directories intended for background services and whatnot. I dislike that
practice and so I do not keep it installed for long on my systems.)

Dan

[Wingcommander]

// These are our bufferable commands from the host

#define HOST_CMD_FIND_AXES_MINIMUM 131
#define HOST_CMD_FIND_AXES_MAXIMUM 132
#define HOST_CMD_DELAY             133
#define HOST_CMD_CHANGE_TOOL       134
#define HOST_CMD_WAIT_FOR_TOOL     135
#define HOST_CMD_TOOL_COMMAND      136
#define HOST_CMD_ENABLE_AXES       137
#define HOST_CMD_WAIT_FOR_PLATFORM 141

Sorry I didn't make myself clear - these are the x3g commands I was asking about - do they change the tool offset like 134 or is the the combination of x3g commands that does this?

[Wingcommander]

OK, so 134 HOST_CMD_CHANGE_TOOL seems to change the current tool index for the steppers and tool head.

} else if (command == HOST_CMD_CHANGE_TOOL) {

if (command_buffer.getLength() >= 2) {

pop8(); // remove the command code

currentToolIndex = pop8();

line_number++;

steppers::changeToolIndex(currentToolIndex);

tool::setCurrentToolheadIndex(currentToolIndex);

}

But 135 HOST_CMD_WAIT_FOR_TOOL and 141 HOST_CMD_WAIT_FOR_PLATFORM do not, which would suggest that these two commands do not explicitly change the tool index, but they do set currentToolIndex - which is a global variable in this namespace, although it only is referenced by within this file (Command.cc). I assume from this that only 134 causes a tool change and the wait commands to not - or am I missing something?

} else if (command == HOST_CMD_WAIT_FOR_TOOL) {

if (command_buffer.getLength() >= 6) {

mode = WAIT_ON_TOOL;

pop8();

currentToolIndex = pop8();

pop16();        //uint16_t toolPingDelay

uint16_t toolTimeout = (uint16_t)pop16();

line_number++;

// if we re-add handling of toolTimeout, we need to make sure

// that values that overflow our counter will not be passed)

tool_wait_timeout.start(toolTimeout*1000000L);

}

} else if (command == HOST_CMD_WAIT_FOR_PLATFORM) {

if (command_buffer.getLength() >= 6) {

mode = WAIT_ON_PLATFORM;

pop8();

pop8();        //uint8_t currentToolIndex

pop16(); //uint16_t toolPingDelay

uint16_t toolTimeout = (uint16_t)pop16();

line_number++;

// if we re-add handling of toolTimeout, we need to make sure

// that values that overflow our counter will not be passed)

tool_wait_timeout.start(toolTimeout*1000000L);

}

[Enginwiz]

I did some more ABS test prints with HBP temperatures around 80°C and for smaller ABS prints this seems to be the sweet spot.

Good adhesion to one single layer of Garnier Fructis #5, flat bottoms, no cracks in the parts and nice surface quality.

With the Bottleworks heated build plate 80°C on the bot display equals 70°C measured on top of the borosilicate glass plate. 

On the standard HBP of Steves Replicator 2X with the clamped on thin glass plate this might be different.

Immediately after the print I removed the glass plate and measured

the surface temperature under the print during cooling. At 55°C the

ABS parts started to separate from the hairspray layer and at 45°C

the ABS parts came off the build plate. 

So in real temperatures there should be enough margin between printing

at 70°C top surface temperature (which equals a setting of 80°C

in the software and on the bot) and the separation temperature

at 55°C to keep the part attached to the build plate during the print. 

[Dan Newman]

On 17 Nov 2013 , at 9:40 AM, Wingcommander wrote:

>
>
> // These are our bufferable commands from the host
>
> #define HOST_CMD_FIND_AXES_MINIMUM 131
> #define HOST_CMD_FIND_AXES_MAXIMUM 132
> #define HOST_CMD_DELAY 133
> #define HOST_CMD_CHANGE_TOOL 134
> #define HOST_CMD_WAIT_FOR_TOOL 135
> #define HOST_CMD_TOOL_COMMAND 136
> #define HOST_CMD_ENABLE_AXES 137
> #define HOST_CMD_WAIT_FOR_PLATFORM 141
>
> Sorry I didn't make myself clear - these are the x3g commands I was asking
> about - do they change the tool offset like 134 or is the the combination
> of x3g commands that does this?

Sorry, assumed you meant M135 and M141.

No, only 134 and 135. Command 141 will not. If you actually poke in the
firmware sources, you look for an assignment to currentToolIndex. And those
assignments only happen in three places

1. Initialization (0; T0)
2. HOST_CMD_CHANGE_TOOL (134)
3. HOST_CMD_WAIT_FOR_TOOL (135)

It's actually ignored for HOST_CMD_WAIT_FOR_PLATFORM even though the command
carries a tool index. The tool index is treated as superfluous. Likewise
for the 16 bit "tool ping delay" if it's MightyBoard electronics.

Dan

[Dan Newman]

On 17 Nov 2013 , at 9:55 AM, Wingcommander wrote:

> OK, so 134 HOST_CMD_CHANGE_TOOL seems to change the current tool index for
> the steppers and tool head.
>

> *} else if (command == HOST_CMD_CHANGE_TOOL) {*
> * if (command_buffer.getLength() >= 2) {*
> * pop8(); // remove the command code*
> * currentToolIndex = pop8();*
> * line_number++;*
> * steppers::changeToolIndex(currentToolIndex);*
> * tool::setCurrentToolheadIndex(currentToolIndex);*
> * }*

>
> But 135 HOST_CMD_WAIT_FOR_TOOL and 141 HOST_CMD_WAIT_FOR_PLATFORM do not,
> which would suggest that these two commands do not explicitly change the

> tool index, but they do set *currentToolIndex* - which is a global variable

> in this namespace, although it only is referenced by within this file
> (Command.cc). I assume from this that only 134 causes a tool change and the
> wait commands to not - or am I missing something?

No, you're reading of the code is correct: that the tool change isn't pushed
down deeper into the code for the tool wait. However, that's just because
it presently doesn't need to be pushed down deeper. But at the s3g parsing
stage -- Command.cc -- a tool change has occurred and will impact the operations
at that level which need to know the current tool index. And, at some point
in the future, it may be necessary to push it down to the other layers. (And
over on the Gen 4 electronics side there may be some considerations owing to the
extruder controller being a separate processor.)

So, presently you're safe with the wait command. But it could change in
the future or otherwise have subtle consequences as it is changing state
in the firmware's s3g interpreter.

Dan

[Steve Johnstone]

Thanks for the info Enginwiz. Will try your low temp limit tomorrow as I have only been brave enough to drop from 110c to 90c over 20 layers @0.2mm layer height.

The dual goblet is proving challenging as I can't keep the PLA side of the extruder block cool enough to prevent heat cheap.

I wonder if Jetguy has been able to print dual materials in the same part, ABS & PLA, on his custom bot. The reason I ask is I think he is using Carl's threaded block with threaded thermal tubes.

So my game plan at the moment is to get a nice std 0.2mm Dual ABS setup and then add clear ABS to the mix.

[Clinton Hoines]

Are you trying to print ABS and PLA in the same model/print? They wont stick to one another and they work at such different temps that you wont have much success in printing them at the same time. It's been tried just doesn't work.

[Jetguy]

No, sorry , the custom Ulti-Replicator is original Replicator based. I do have Carl's aluminum bar but that is going into another top secret (not really I will release it when done) bot that also uses the aluminum X ends. Because that bar is designed for the 2 series and mates to the aluminum X carriage, it's a better fit as a separate project. Full disclosure is that I do not own any 2 series bots (nor will I if I can help it).

 

Again, my bot is strictly Replicator 1 parts from that aspect and using David's 3 in 1 extruder upgrades.

 

So for me, I still reserve ABS for Dualstrusion projects. I've not even really tried PLA in Dualstrusion since Maker Faire.

 

In fact, it's kind of my fault that other than a few initial test prints for setting up Makerware, I really haven't done much dual printing. I put a lot of work up front to make sure the bot was capable but then was waiting to see what the best project is to make use of the build space.

Sorry that' not much help.

[Wingcommander]

So, presently you're safe with the wait command.  But it could change in
the future or otherwise have subtle consequences as it is changing state
in the firmware's s3g interpreter.

So just to be clear, are you recommending that GPX output a 134 HOST_CMD_CHANGE_TOOL prior to any GCodes that cause a 135 HOST_CMD_WAIT_FOR_TOOL command to be output? Or should I just leave that to the GCode to do it?

[Steve Johnstone]

Hi Clinton,

I'm not worried if they don't stick together as I don't mind gluing later. What I hoping to do is have them support each other during the print as I would lose some of the fine detail (Blue) at the top of the goblet if I printed them individually.

Also my settings have the PLA & ABS printing at 230c. I may try dropping the temp on the PLA as that may help with the heat creep.

The thing is I have printed both PLA Blue & ABS Clear versions at 230c and they came out great. I printed an ABS blue version last night and although it printed well, the blue doesn't pop like the blue PLA.

This is basically what I'm shooting for - Blue PLA, Clear ABS. 

Some time-laps video of the blue PLA print - 0.2mm Layer Height & 230C (based on Enginewiz's 0.2mm PLA profile) - http://youtu.be/Kk_cphgQCG0

[Steve Johnstone]

No worries Jetguy, it was worth an ask.

I'm looking forward to finding out more on your new project.

[Dan Newman]

1. I'd stick to whatever is working today which is basically leaving this to
the gcode.

2. This is largely a non-issue as there's no practical reason to be using a "wait for tool"
outside of the start.gcode section. Why on earth would gcode be tossing in a "wait for tool"
mid-print anyway? (Makerbot gcode that is; we're ignoring the fact that this whole tool
change gcode in Makerbot gcode is somewhat at odds with the larger CNC worlds usage of gcode.)
Makerbot gcode with a "wait for tool" midprint would just damage the print as the extruder
stops in place and waits some period of time (measured in 10's of seconds) for a temp
change to occur. For folks doing these gradual temp changes, waits are not needed and,
I'd argue, counterproductive. I suppose someone could put a pause into their gcode, then
expect manually for someone to change the filament to another which needs a
radically different temp at which point then having a "wait for temp" might make sense.
But that's a hypothetical situation and personally I prefer to not spend time solving
presently non-existent hypothetical cases. Personally, it's always seemed best to wait
for a real, existing case and then address it. And in this situation, there's already
a manual solution to such a hypothetical case: while the filament is manually changed,
the user can also manually change the temp from the LCD display and the bot will automatically
wait for the new target temp before un-pausing itself.

Dan

[Steve Johnstone]

Hi Dan,

Today I was dual printing, abs on both extruder and could have done with reducing the temp on the left extruder during the print. With sailfish, is it only the right extruder temp you can change on the fly fron the LCD?

Thanks

[Dan Newman]

On 18 Nov 2013 , at 12:55 PM, Steve Johnstone wrote:

> Hi Dan,
>
> Today I was dual printing, abs on both extruder and could have done with reducing the temp on the left extruder during the print. With sailfish, is it only the right extruder temp you can change on the fly fron the LCD?

It's the active extruder whose temp is changed. So, if one extruder is only being
used briefly, it can be tricky to change its temp from the LCD display. I don't
know offhand if there's enough program space left in the 1280's to be able to
have a UI element to allow picking which extruder to change the temp for during
printing.

Dan

[Steve Johnstone]

Thanks Dan, that's good to know.

[Steve Johnstone]

My wife took some abstract photos of the chipped glass build table ...

On Saturday, 16 November 2013 23:36:07 UTC, Steve Johnstone wrote:

Enginwiz, I had the exact same glass chip experience when I first started using hairspray on the glass. It was almost like the glass had delaminates on the surface directly under the print. It's good to know what caused it.

The dual material goblet is as challenge, still working it all out, but as soon as I have a solution will let you know.

[Dan Newman]

On 19 Nov 2013 , at 4:40 AM, Steve Johnstone wrote:

> My wife took some abstract photos of the chipped glass build table ...

Nice pictures!

But if you digitize them and put them on Thingiverse as 3d prints of
some ancient water flow feature found on Mars, they might get featured ;)

Dan

[Steve Johnstone]

LOL!

[Wingcommander]

(@temperature 3.0mm 220c 90c)

(@temperature 5.0mm 210c 80c)

(@temperature 7.0mm 70c)

I just tested these out in GPX 1.5 and they work just fine. Obviously it takes a while for the build plate to cool, so depending on the size of your print, you need to leave a bit of a gap so you don't exceed the 10c per change threshold. 

[Wingcommander]

1. I'd stick to whatever is working today which is basically leaving this to
the gcode.

As a precaution, I placed a compile time define to enable tool changes on extruder wait commands. That way, if this GPX behaviour causes a bug in some future release of Sailfish, its easy to test if the tool change is causing the problem.