v2.0r1 firmware and ReplicatorG 0014 released!

[phooky]

Hello Makerbotters!

ReplicatorG 0014 and the v2.0 firmware are now available. Here's the
blog post:
http://blog.makerbot.com/?p=1477

If you installed the v2 beta firmware, please install the "release 1"
version on both the extruder and motherboard. (They're available in
the firmware uploader in ReplicatorG.) The minor version number
hasn't changed on this release, so ReplicatorG will not automatically
remind you to do so.

These releases are primarily stability fixes. A lot of the day-to-day
frustrations of printing should be addressed:
* ReplicatorG should be far less likely to hang, especially on Windows
and Mac OS X. You should be able to shut down ReplicatorG normally in
any situation.
* Abort commands propagate to the extruder. When you hit the stop or
reset buttons, the extruder will stop as well.
* Stops should be immediate, even in mid-move. (Pausing will still
wait until the end of the current stroke.)
* Connecting to the machine is somewhat faster with the v2 firmware.
* You should now be able to print smoothly over the USB connection,
without build burps or hangs.
* There are now many more tweakable options in the firmware; you can
open the Onboard Paramters dialog for the machine and the extruder
controller to see the changes.

There have been a lot of code changes, and there will inevitably be
bugs, so please let me know as soon as you run into a problem.

Special thanks to everyone who tested the v2 firmware, and an extra
shoutout to Len and others who accidentally tested the 0014 pre-
release. :)

-a

[Jordan Miller]

great! can we disable the debug blinking when MakerBot is off? I think
this should be the default... people are assuming there is an error.

jordan

> --
> You received this message because you are subscribed to the Google
> Groups "MakerBot Operators" group.
> To post to this group, send email to make...@googlegroups.com.
> To unsubscribe from this group, send email to makerbot+u...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/makerbot?hl=en
> .
>

[Matt]

I'm impressed with how fast it connects now! That's some great work. The stop button stopping the extruder is also much appreciated.

Have there been any changes to the temperature loop tuning parameters? It seems to come up to temperature a bit slower, and has leveled off at a lower temperature (187 vs setpoint of 225 in the control panel) a couple of times. I was able to extrude from the control panel with the temperature showing as 187 so I suspect it may just be something to do with the temp display.

Of course there's a chance my heater has decided to choose exactly this moment to flake out.

[Lyndondr]

No Matt it's slow. The extruder was slower mine made it to temp but
it took a long time. The HBP never made it to my 110 set point, I had
to set to 145 to make it to 110. My ir thermometer seems to agree with
the displayed temp. I went back to v1.8 and thats faster and I only
have to set that to 113 to get to 110 on the HBP. The jogging and end
stop testing with repg 14 no longer reset the axis inversion
settings.

I did the enabling auto reset procedure with one small difference. I
used a 2 pin header and used a jumper instead of wire. Now firmware
updates on the mobo don't require hitting the reset button. Here is a
link to the instructions http://wiki.makerbot.com/enabling-auto-reset-on-reprap-motherboard-v1-2

If the temperature controls for v2 get back to v1.8 I think I would do
more testing with it.

> > makerbot+u...@googlegroups.com<makerbot%2Bunsu...@googlegroups.com>

[Matt]

Thanks for the confirmation. I also found that the new firmware was unable to maintain temp during the print and it would eventually drop to ~190 and jam. Firmware teething pains I guess!

I've since reverted to 1.6 mobo/1.8 extruder and was able to successfully print the same gcode that failed with the new firmware.

To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.

[Jordan Miller]

same problem here. also, when a different print was complete in v2, the head went down instead of up. Did it all of a sudden forget my inverted z-axis setting?

On the plus side (we need more congratulations all around), Adam's put a metric a ton of effort on v2 (look at those git commits!). Excellent. I'm getting faster connections and rock-solid stopping whenever I need it. No more rampant over-extrusion after I push the stop button. Hooray!

jordan

[Thomas Charron]

  Hrm, this looks fishy to me at least..

void ExtruderHeatingElement::setHeatingElement(uint8_t value) {
        if (value > 128) value = 255;
        if (value > 0) value = 128;
        if (value == 0 || value == 255) {
                pwmBOn(false);
                channel_b.setValue(value == 255);
        } else {
                OCR2A = value;
                pwmBOn(true);
        }
}

  If it's above 128, set it to 255.  If, after that, it's greater then 0, set it to 128.

  Sooo, the PWM will never be more then 50%?

--
-- Thomas

[Jordan Miller]

nevermind, I get it now. it only blinks if there was an error
(disconnecting the USB-ttl cable will start the blinking, I guess to
let you know it is disconnected?). resetting mobo fixes it sometimes.
I guess I'm still confused.

jordan

[Koen Kooi]

Looking at the history of that file leads me to http://github.com/makerbot/G3Firmware/commit/3577334d8ebafac7585d0ba878c8669b07686cf7 which does:

- if (value == 0) { TCCR2A = 0b00000011; }
- else { TCCR2A = 0b10000011; }
- OCR2A = value;
+ if (value > 128) value = 255;
+ if (value > 0) value = 128;
+ if (value == 0 || value == 255) {
+ pwmBOn(false);
+ channelB.setValue(value == 255);
+ } else {
+ OCR2A = value;
+ pwmBOn(true);
+ }

So it looks like some logic got changed here. Dunno if it was intended or not :)

regards,

Koen

[phooky]

Hi;

That change was intentional, although probably unnecessary; I was
reducing the number of variables in play during the rewrite.

The slower time-to-heat is probably related to the new PID
implementation; the parameters need tuning. I'll pop them into eeprom
in 2.1 so they can be easily tweaked.

-a

On Apr 15, 12:21 pm, Koen Kooi <k...@beagleboard.org> wrote:
> Op 15 apr 2010, om 17:13 heeft Thomas Charron het volgende geschreven:
>
>
>
>
>
> >   Hrm, this looks fishy to me at least..
>
> > void ExtruderHeatingElement::setHeatingElement(uint8_t value) {
> >         if (value > 128) value = 255;
> >         if (value > 0) value = 128;
> >         if (value == 0 || value == 255) {
> >                 pwmBOn(false);
> >                 channel_b.setValue(value == 255);
> >         } else {
> >                 OCR2A = value;
> >                 pwmBOn(true);
> >         }
> > }
>
> >   If it's above 128, set it to 255.  If, after that, it's greater then 0, set it to 128.
>
> >   Sooo, the PWM will never be more then 50%?
>

> Looking at the history of that file leads me tohttp://github.com/makerbot/G3Firmware/commit/3577334d8ebafac7585d0ba8...which does:

[Thomas Charron]

On Thu, Apr 15, 2010 at 2:29 PM, phooky <pho...@gmail.com> wrote:

Hi;

That change was intentional, although probably unnecessary; I was
reducing the number of variables in play during the rewrite.

The slower time-to-heat is probably related to the new PID
implementation; the parameters need tuning.  I'll pop them into eeprom
in 2.1 so they can be easily tweaked.

  Umm, I'm still a bit confused.  With the code, as currently implemented, it isn't even doing PID control.  It's either on, or it's off.  And even when it's on, it's only on 50%, as opposed to the old code, which could go to 100%.

--
-- Thomas

[phooky]

Oh, good grief. I misread. You're right, that's most definitely
*not* intentional. I have no idea how that slipped through.

I'll fix that and put out a new version right away. Thanks for
catching that.

-a

[phooky]

Okay, the fix is in and there's a new build. Next time you start
replicatorG you should see the update message.

Thanks,
-a

[Lyndondr]

Are the new v2 firmwares cross compatible with replicatorg 13 and or
the v1.8 extruder and v1.6 for the mobo. Basically are there any bad
combination's to avoid?

[Thomas Charron]

On Thu, Apr 15, 2010 at 5:58 PM, phooky <pho...@gmail.com> wrote:

Okay, the fix is in and there's a new build.  Next time you start
replicatorG you should see the update message.

  That makes a little more sense.  :-D

  I do have a silly question, however.  Why not just simply say,  set the output to value?  Why not just let the PID loop moderate the value to whatever it wants?

--
-- Thomas

[RyanP]

Improved heatup time on 2.1 from 2,0, but increase error from 1.8 at
steady state between commanded and measured. I'm only getting 205C
when set to 220C and 97C when set to 117C on the HBP. Firmware 1.8
gives 5-10 more degrees on both.

I'm printing a part right now. Extrusion seems okay, but I lost
adhesion with some of the internal outlines which is making a bit
precarious. I think it's going to pull through...

[Nate True]

When trying to update my extruder firmware to 2.1, I get:

/Applications/ReplicatorG/tools/avrdude -C/Applications/ReplicatorG/
tools/avrdude.conf -cstk500v1 -P/dev/tty.usbserial-FTE5V7TI -b19200 -D
-Uflash:w:firmware/EC-ecv22-v2.1r1.hex:i -pm168


avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100%
0.01s

avrdude: Device signature = 0x1e9406
avrdude: reading input file "firmware/EC-ecv22-v2.1r1.hex"
avrdude: can't open input file firmware/EC-ecv22-v2.1r1.hex: No such
file or directory
avrdude: write to file 'firmware/EC-ecv22-v2.1r1.hex' failed

avrdude done. Thank you.


It looks like the firmware didn't download from wherever you are
serving it.

[Derekja]

For the most part the build looks great. I had some of the lost Z
settings issues after I had updated the firmware, but before I went to
the new replicatorG. Now that all firmware and replicatorG versions
are updated things seem to be working properly again.

I am seeing more temperature fluctuation than I used to, I think. It
hasn't prevented me from printing or caused any jams, but it's a bit
worrisome. With my temperature set to 215 I saw it range between 203
and 219 while I was printing a whistle.

It sure does connect fast!

Thanks,

--Derek

[JadeKnight]

I tried the latest v2.2 extruder firmware last night, and I get bad
temperature fluctuations.

I have the temperature set to 220 for ABS.

Using v1.8 it holds a pretty steady 220 (with only ~1-2 degrees
fluctuation).

Under v2.2 the temperature fluctuates between ~210 and ~220 (even when
idling). When extruding, and the temperature begins to drop, I can
hear the filament drive motor begin to strain and the extrusion speed
slows.

For now, I've reverted back to v1.8.

-Jason

[Steven Dick]

On Tue, Apr 20, 2010 at 1:13 PM, JadeKnight <jade...@gmail.com> wrote:

I tried the latest v2.2 extruder firmware last night, and I get bad
temperature fluctuations.

I also see more fluctuations with the 2.2 firmware.  However, I also see it heating up faster and actually hitting the target.

With the 1.8 firmware, it would heat up to about 5-10 degrees below target,  and just sit there for 5 minutes without quite reaching the target temperature.

I think some of it has to do with how well connected your barrel and washer are -- too well connected (with the nut) and it is too efficent of a heat sink.  A bit of kapton tape inbetween helps.  But too much tape and it doesn't heat sink enough and the PTFE overheats.

It would be interesting if the PID loop had a tuning parameter in it we could access via machine preferences.
Of course, this would add one more knob that newbees would be confused about, and PID controllers I'm told are tricky to tune, so maybe it wouldn't be that easy.

[Jordan Miller]

interesting. i'm getting the opposite effect. 1.8 HBP would always hit the target and only fluctuate ±1 ºC. Firmware 2.2 fluctuates wildly, ±10 ºC and makes my builds fail due to halted extrusion from the nozzle cooling down. ack!

jordan

[JadeKnight]

> I think some of it has to do with how well connected your barrel and washer
> are -- too well connected (with the nut) and it is too efficent of a heat
> sink. A bit of kapton tape inbetween helps. But too much tape and it
> doesn't heat sink enough and the PTFE overheats.

This *might* explain my issues, and the reason some people have luck
with 2.2 while others do not. On my machine the nut is very tight
against the washer, probably making it a more efficient heat sink as
you said. There is kapton between them (as per the original assembly
instructions), but maybe not enough. I'd prefer a more efficient heat
sink, than melt the PTFE though...

> It would be interesting if the PID loop had a tuning parameter in it we
> could access via machine preferences.

This would be nice. Maybe at least have a '1.8 PID' and '2.2 PID'
selection/switch to alternate between the two methods. If you wanted
to get extra aggressive, there could also be a 'custom' selection that
let you tweak individual numbers. Newbies (like myself, I must
admit ;-) ) would just use the '1.8' or '2.2' selections (whichever
has better characteristics for their machine). More advanced users
could go to 'custom' if neither got them the results they wanted.

I think I'm going to look around the firmware / ReplicatorG code, and
see how hard adding a switch like this would be. Unless someone else
more experienced in the firmware likes the idea ;-).

-Jason

On Apr 20, 8:04 pm, Steven Dick <kg4...@gmail.com> wrote: