[KwartzLab] 3D Printer: possible hardware upgrade

[doug moen]

This email thread with TechZone tech support is quite interesting, at
least for me and Kevin.  Lambert is describing a hardware upgrade with
improved motor control chips -- this upgrade is designed specifically
for our printer hardware, and will be available as a kit.  Also, there
is some nice history explaining why the current hardware is the way it
is.

Doug

---------- Forwarded message ----------
From: Lambert Andrus <support at techzonecom.com>
Date: 16 September 2011 14:59
Subject: Re: 3D Printer: Next Steps
To: doug moen <doug at moens.org>


Doug,



a separate stepper controller connected in addition to the electronics
you have will give you better control and consistency with the
extruder; but it isn't a necessity - you have to decide if it is worth
it for your situation. I expect that many of the problems that people
had with the extruder controller can be explained by the "bug" you
identified and told me about.



A little history might be helpful for you here. We released the
LaserCut Mendel almost a year and a half ago, it included the gen 3
electronics since that was the best electronics available at the time.
Although we manufactured the electronics, they were designed by
makerbot for their cupcake cnc. we did not alter the schematic, except
to change some connectors to incorporate changes that were recommended
at the time on the RepRap.org website. We were trying to make the
RepRap printers more accessible to the general public. We weren't
trying to create a new project or fork the reprap project and we were
trying to stay consistent with the documentation that already existed
for the RepRap.



When makerbot designed the extruder controller they set it up to run a
DC motor as the extruder motor, so the chips on that board are much
better suited to running that motor than they are to running a stepper
motor. The ability to run a stepper motor was a clever software hack
done by somebody out there, and it became the most popular method of
running the machine. That is why I think they may have left that code
in there, so that it would stay backwards compatible with the DC
extrusion method that was still common at the time. I expect that it
has never been cleaned up properly and that the newest versions of the
reprap firmware still has it in there.



The nature of the RepRap project is a bit unique, in that it has no
strong central guidance, which results in an "anything goes"
environment. We have had numerous problems with people altering
instructions, or even deleting part of them, as well as good valid
instructions begin depricated because someone else released something
new (even thought the new thing never became main stream). It has all
been quite frustrating here... but we are working on it and working on
keeping a separate set of instructions as well.



Anyway, the part of that which is relevant to our situation is that we
were trying to stay consistent with what was mainstream at that time,
so we did not make a major change to the electronics design. We did
put on our instructions that we recommend a fourth stepper controller
to be used to run the extruder motor, I think the instructions are
still there  which describes how to do that.



I am sorry if this situation has caused undue frustration on your
part. Next week, we are releasing some new boards which are for people
who are in your situation (there are hundreds of you out there). We
have re-designed the Gen 3 electronics set and we are using updated
motor control chips so that it will have 1/16 step controllers. We
don't intend to sell them as main stream, but rather as replacements
and updates for people who already have gen 3 electronics. We are
doing this because we sell several parts of the gen3 every week to
people who have makerbots and mendels and all sorts of stuff, and no
one else is still making parts for the gen3 electronics set.



We have also had a new company contact us about making gen 3
electronics for them... they intend to "clone" the older makerbot
designs, since they were so popular, and Makerbot simply dropped them
from the product line in favor of their newer more expensive design.
We will probably come to some sort of agreement with them.



At the same time we are also updating the Monotronics to include the
1/16 step chips.



Thanks,
Lambert

On September 16, 2011 at 12:27 PM doug moen <doug at moens.org> wrote:

> We have gen 3 electronics, and the M108 bug is affecting the
> extruder's ability to feed plastic, as best as I can remember.
>
> We have a separate extruder controller because that is how your mendel
> kit worked at the time that we purchased it.  We purchased a complete
> kit with all parts and electronics.  If there is a hardware upgrade
> that will give us better quality or faster printing, then tell me what
> you recommend.
>
> Doug Moen.
>
> On 16 September 2011 14:14, Lambert Andrus <support at techzonecom.com> wrote:
> > Doug,
> >
> >
> >
> > That is an interesting "bug"... it should still be irrelevant to the
> > operation of our system since the extruder speed is not set by the pwm
> > anyway (but I can see that it could cause some problems with the current
> > settings on the extruder controller - if you have a separate extruder
> > controller, which we don't recommend anyway). Setting the current to a pwm
> > of 255 would be even worse than setting it to a lower value if your motor
> > has resistance that is borderline... I have to do some checking to see if
> > that was put that wa intentionally for some sort of backwards compatibility
> > or not. Hopefully it is a true mistake on the part of some past programmer.
> > Either way, I like your solution.
> >
> >
> >
> > Of course I may be missing something else entirely. being a extruder command
> > I am assuming  it is only affecting the extruder controller not the
> > mainboard or electronics other than the gen 3
> >
> >
> >
> > That portion of code was not created by us, but existed in the firmware when
> > we got it. We then added our code to it so that our tip manager and
> > thermocouple A-D would work.
> >
> >
> >
> > I really appreciate he feedback on this. I had not seen it affect our
> > systems here.
> >
> >
> >
> > Thanks,
> > Lambert
> >
> > On September 16, 2011 at 11:14 AM doug moen <doug at moens.org> wrote:
> >
> >> Please read this entire message.  Possibly your email client is hiding
> >> part of the message.  Summary: there is a bug in the TechZone firmware
> >> which is easy to fix. (I haven't tested the proposed fix yet.)
> >>
> >> You said:
> >>
> >> > Also, in the firmware we provide on our electronics, the m108 only sets
> >> > the
> >> > extrusion speed of the DC motor extruder - which is not used on our
> >> > electronics. Could you please give me a description of how it is causing
> >> > you
> >> > problems?
> >>
> >> I supplied a full description in my previous email, which was at the
> >> end of your message. Here it is again.
> >>
> >> >> >> The TechZone firmware contains this source code:
> >> >> >> // If there's an S field, use that to set the PWM, otherwise use the
> >> >> >> pot.
> >> >> >> case 108: // Depricated
> >> >> >> case 113:
> >> >> >>     #if MOTHERBOARD == 2
> >> >> >>      if (gc.seen & GCODE_S)
> >> >> >>          ex[extruder_in_use]->setPWM((int)(255.0*gc.S + 0.5));
> >> >> >>       else
> >> >> >>          ex[extruder_in_use]->usePotForMotor();
> >> >> >>     #endif
> >> >> >>     break;
> >> >> >>
> >> >> >> This code causes M108 to be interpreted as if it were M113, which is
> >> >> >> different from ignoring M108.  And that is a bug.  Note that in
> >> >> >> order
> >> >> >> for M108 to be ignored, the code would have to be written like this:
> >> >> >>     case 108:
> >> >> >>        break;
> >> >> >> With the break statement missing, we fall through into the next
> >> >> >> case.
> >> >> >>
> >> >> >> I created a gcode file using 3dtoolchain.com.  Near the top, it
> >> >> >> contains M113 S1.0, which sets the PWM to 255, which is the maximum
> >> >> >> value.  This is fine.  It's the only M113 command in the file.
> >> >> >>
> >> >> >> Later on, there are a lot of M108 commands, such as M108 S47.6.  If
> >> >> >> you do the math, this command sets the PWM to 106, which is much
> >> >> >> smaller than 255.
> >>
> >> In other words, M108 is like M113, except that it sets the PWM to a
> >> bad value, because it misinterprets the S parameter.
> >>
> >> We did some test prints where the M108 commands were setting the PWM
> >> to such a small value that the motor was stalling, which was messing
> >> up the print.  Commenting out the M108 commands fixed the stalling
> >> problem.