Steppers, Stops, and Skeins, oh my! (Part 1)

I recently purchased a kit for Wade's Geared Nema17 Extruder. This thing rocks! It pumps out a pretty hefty volume of material compared to the DC-motor based extruders I'm used to working with, at least on a test-bench configuration. However, trying it out on a 3D printer led to a long and continuing saga of soldering and software hacking.

Electronics Modification

This part is documented: extra wires need to be soldered onto the motherboard to connect it to the extruder controller.

This part is in the forums somewhere (I wish I saved the link): the extruder controller doesn't have a current-limiting driver, something that steppers really need to reach their full potential without burning out.

My solution (chances are others have done this also): run the extra wires from the motherboard to a stepper board instead of the extruder controller. The extruder controller now just does temperature control.

Firmware Selection

I've been using ReplicatorG and Skeinforge with the Generation 3 firmware ever since I purchased my MakerBot. Unfortunately the Gen 3 firmware doesn't currently support stepper-driven extruders. (I could have missed something; please post comments/corrections in the comments).

I decided to switch to the 5-D firmware and RepRap Host software. This sent me a long series of rabbit holes that I'm still working my way out of.

Firmware Changes

Many machine-specific parameters are compiled in the 5-D firmware. Things such as steps-per-inch, stepper polarity, and whether acceleration is needed or not are all in the header files in easy-to-change form. Everything, that is, except the stepper polarity for the extruder. This isn't a problem if your stepper is connected to your driver using screw terminals, but it is a problem if it's connected by a polarized plug. I dug deep into the sources and made the necessary change.

End Stops Part 1

The Generation 3 firmware mishandles end stops, so most people using Gen 3 don't bother putting end stops on their machines. I fell into this category. I was surprised to find out that not only does the RepRap Host software handle end stops, it requires them. I searched for a way to disable the homing sequence in the configuration window, but couldn't find one. I never bothered soldering up the end stops in my electronics kit, so I thought I'd just work around it on the software side.

Falling Back to a Familiar Standby

The RepRap Host software doesn't require end stops if it's used with externally-generated g-code. No problem! Replicator G only works with externally-generated g-code. Re-enter Skeinforge.

Skeinforge Upgrade

Skeinforge is a rapidly-moving target. Gen 3 users, including my myself, normally use an older version of Skeinforge. It's what most Gen 3 users are used to, it's what they document, and it's what they point new users to. Unfortunately this older version doesn't support the 5-D firmware, which requires a very different way of controlling the extruder.

Skeinforge Changes

Skeinforge is a rapidly-moving target; it's hard to know which version is new enough to have the features you need, but not so new that it breaks them. I went with the latest; it broke the features I need. Either that or I got confused by its large number of parameters.

Problem 1: E-axis handling. It was generating g-code which drove the E axis a much longer distance than the other axises (by at least an order of magnitude). I dug into the code to figure out why. I closely examined the formula it used, but was unable to make heads or tails of it. I replaced it with the following:

E distance = movement distance * flow rate / 255. Why /255? I'm used to the flow rate being a PWM setting in the range 0-255. I'd probably be better off dropping that old mentality and the /256.

Problem: Skeinforge was designed for DC motor-based extruders, which have very poor flow rate control. Skeinforge adjusts filament width for different portions of the print by varying the X-Y motor speed, which causes the filament to stretch out. My formula cancels this effect. I suspect the original formula was designed to preserve it. I should probably go back to reread it with this in mind. If I understand it, I should be able to adjust the parameters to make it come out well.

Problem 2: fast Z. Skeinforge has a Maximum Z Feed Rate setting. It pretty much ignores it. The resulting g-code was driving Z at a speed that was well beyond the set limit and what the printer could do. This effectively turns the Z motor into a speaker that makes nice sounds but doesn't turn. I did some surgery on speed.py (the code that regulates speed). No effect. I selectively disabled Skeinforge features until the problem lessened; clip.py was a culprit. It completely clobbered speeds on rapid moves. Fixed that. Tried again. Still too fast. Tracked it down again. Lots of filters modify paths but either preserve the feed rate as-is (not usable with the 5D firmware) or completely replace it with one of the fixed settings (again, not usable with the 5D firmware). At this point I gave up.

Note: this isn't a problem with Skeinforge; it just expects either the firmware or the host software to limit Z (Gen 3 / ReplicatorG does this). It also isn't a problem with the 5D firmware / RepRap Host Software; they just expect externally-generated g-code to completely control speed. It's an integration problem.

End Stops Part 2

To be continued...