Smoothieware: New Firmware for PnP

The Open Source motion controller firmware Smoothieware is optimized for 3D-printing, milling, laser cutting and similar. It is a very nice and versatile firmware but sometimes problems get exposed in the Pick&Place use case. I found and fixed some missing features and bugs and tried to contribute them back to the project. Quite unsuccessfully. Some bugs were then fixed by the authors, others not. Untreated bugs now pop up with the new advanced motion control. To address this, I decided to make a special “PnP” version of the firmware.

This page contains a lot of complicated technical descriptions as to why the special firmware is needed. If you’re not interested in these details (there is no need to know them), you can skip right to the Downloads at the bottom. After flashing the firmware, be sure to let the OpenPnP Issues & Solutions system help you setup the driver properly.

Mixed Axes

One bug concerned motion with mixed Axes. When tiny linear moves (e.g. X, Y axis) are mixed with large angular moves (e.g. C axis), Smoothieware would not respect the maximum allowed angular feed-rate and acceleration limits. This can result in the stepper motor being stalled and losing steps. If you’re interested in the details, please read the Description in the PR.

With OpenPnP’s Nozzle Tip runout compensation we got exactly this: tiny linear moves (the runout compensation in X/Y) mixed with large angular moves (the actual Nozzle C rotation we wanted).

I fixed this, but my contribution was not accepted. After some discussion in the user group, the authors finally chose to create their own fix. The first attempt failed. Eventually, they restarted and made a minimal fix. It only addressed the most pressing of my concerns, but after spending so much energy, I thought, it was better than nothing (and at the time OK for OpenPnP usage).

But with the new work in advanced motion control the untreated bugs have resurfaced.

Applying the Feed-Rate to the wrong Axis

The following G-Code reproduces the first problem and practically “hangs” Smoothie:

G91 G1 X0.00009 C100 F100

Because the linear axis X0.00009 is (mistakenly!) assumed to be too small to apply the feed-rate, Smoothie just takes the C100 instead. But now the F100 has a completely different meaning. It will take C100/F100 = 1 full minute to complete the move, instead of the correct X0.00009/F100 = “no time” (underlying machine limits still apply).

The example is a bit extreme, but I had multi-second hangs in my tests, jogging the C axis repeatedly was the worst.

Ignoring the Rotation Axis in Junction Deviaton

The following G-Code reproduces the second problem, it stalls the C stepper and loses steps.

G91 G0 F100000 X100 C100 G0 X100 C-100

It happens in the so-called junction-deviation optimization. Smoothie tries to ride through junctions (corners) in subsequent path segments as fast as possible. This obviously depends on in the angle of the junction: the straighter, the faster it can ride through. When looking at the angle, Smoothie checks the X, Y, Z linear axes but again forgets the rotational axes. The example above has a straight junction in X but a full reversal in C. Ignoring C, Smoothie will ride through at full pace, completely stalling the C stepper.

The bugfix was rejected along with the other, see here.

Mid-Axis Homing

Another issue is described in the post Smoothieware: Adding Mid-Axis Homing. A missing feature rather than a bug. Again my PR was not accepted. The following clip shows the 6-axis firmware (linked below) in action on the cool 4-nozzle machine of Mike Menci. You see the homing of both nozzle pairs, one from each side of the mid-axis homing switch:

(footage credits: Mike Menci)

The new option is only available for the modern 6axis endstop syntax and defaults to false. It follows the following syntax pattern. In order to enable it, change it to true.

endstop.minz.release_first                   true            # first move away from endstop until released

Update: Advanced Motion Control

The new OpenPnP Advanced Motion Control feature-set uses quite advanced techniques. For those to work, more changes were integrated into Smoothieware.

Position Reporting and Resetting

The G92 offset is stored for all axes, i.e. also for A B C.

Based on this, M114.x can now report all axes i.e. including A B C.

Allows setting the G92 offset, while a move is still pending.

See the Pull request (rejected, as usual).

Interpolation Step Feed-rate Issue

OpenPnP can now use interpolation to simulate Jerk Control. Read the Wiki.

When you have nozzle runout compensation, doing rotations will also generate very small adjustments in X/Y. If you have a (relatively) large rotation, then the X/Y will move very slowly in coordination with the angular turn.

The jerk control interpolation will break up the movement into many small steps and the already tiny X/Y adjustment will be divided into truly microscopic step movements. Some of these will then collapse below one micro-step/resolution tick, i.e. become zero for some interpolation steps.

Side note: We need to handle this “collapse to zero” due to the G-code decimal output with limited digits and due to the fact, that some controllers will swallow tiny moves and then behave unpredictably, for similar reasons as described below.

Consequently, the X/Y axes will sometimes be included in an interpolation segment and sometimes not (collapsed to zero). Only the C axis will always be included. Now we’re in big trouble, because of the NIST RS274/NGC Interpreter – Version 3 standard, more specifically section “2.1.2.5 Feed Rate”:

A. For motion involving one or more of the X, Y, and Z axes (with or without simultaneous
rotational axis motion), the feed rate means length units per minute along the
programmed XYZ path, as if the rotational axes were not moving.

B. For motion of one rotational axis with X, Y, and Z axes not moving, the feed rate means
degrees per minute rotation of the rotational axis.

C. For motion of two or three rotational axes with X, Y, and Z axes not moving, the rate is
applied as follows. Let dA, dB, and dC be the angles in degrees through which the A, B,
and C axes, respectively, must move. Let D = . Conceptually, D is a
measure of total angular motion, using the usual Euclidean metric. Let T be the amount
of time required to move through D degrees at the current feed rate in degrees per
minute. The rotational axes should be moved in coordinated linear motion so that the
elapsed time from the start to the end of the motion is T plus any time required for
acceleration or deceleration.

As you see, the meaning of the feed-rate changes completely, between when X/Y are or aren’t included in the interpolation step. In the case of Smoothie this will force the internal move planner to zero junction speed between these segments, the rotation might take minutes!

On Smoothieware this can be addressed with the PAXIS= setting, explained on the 6-axis page. Therefore, the newest firmware is now compiled with that option.

CAUTION: With PAXIS= or similar, the rotational axes must be treated as linear by OpenPnP. You have to use the Switch Linear ↔ Rotational checkbox, as explained in the Wiki. However, the OpenPnP Issues&Solutions system will automatically suggest all the right settings for you.

G-code Command Decimals

Update 2021-02-15: Smoothieware used the strtof() function to scan for decimals on a G-code line. This function will interpret a 0X character sequence as a hexadecimal prefix, or the E letter as an exponent, mistaking legal G-code sequences as part of the decimal. This happens when compressing the G-code i.e. when removing whitespace before letters, which is legal by the standard.

See the case where this happended.

This bug was fixed by replacing it with a hand-made decimal scanner that adheres to NIST RS274NGC Interpreter – Version 3, section 3.3.2.1.

New Firmware

This firmware consolidates all my “PnP Goodies”:

• For current OpenPnP 2.0 versions: Download the newest 5-axis firmware.bin and don’t forget to let Issues & Solutions do the Switch Linear ↔ Rotational as explained above. Made with:

  make AXIS=5 PAXIS=5

• For current OpenPnP 2.0 versions: Download the newest 6-axis firmware.bin and don’t forget to let Issues & Solutions do the Switch Linear ↔ Rotational as explained above. Made with:

  make AXIS=6 PAXIS=6

• For pre 2020-12-12 OpenPnP 2.0 versions: Download the 5-axis firmware.bin made with just:

  make

• For pre 2020-12-12 OpenPnP 2.0 versions: Download the 6-axis firmware.bin made with:

  make AXIS=6

• Get the Source Code
• This branch also contains a small add-on to allow building in Visual Studio, again read the PR Description.

Note, the branch is not based on the newest edge version. My machine won’t run with the edge, even unmodified edge. It seems the 6axis endstops have an issue (with disabled endstops it works). Might even be a free RAM issue, Smoothie seems to have become fatter. I’m fine with the proven 2019-05-16 version, this is now based on. Please contact me, if you need a newer feature dearly.

As usual, this is at your own risk. Be careful when testing on the machine.

Next step: Follow the instructions for flashing.