Part 2 of the build documentation. You may want to check out the intro first.

Wanting some options for optimizing the speed of the machine, I needed to understand what’s happening.

How does the machine move?

The controller (G code interpreter) directs the motors how to perform an axis move. Usually there is some sort of trapezoid shape of speed over time. The image below shows a constant acceleration model (i.e. Smooothieware). Other controllers have more elaborate models where the acceleration is eased in and out to reduce jerk (i.e. TinyG):

First the maximum allowed acceleration limits how quickly the speed can be increased. Once the speed limit is hit, the actuator will cruise on. Finally, timely deceleration makes sure the axis does not overshot its target. Also quite important.

If the maximum acceleration is low, the actuator will never reach the speed limit on a short move. So it is often the maximum acceleration that actually limits the effective speed of the machine.

Why can’t the machine just go faster?

When the machine wants to move, it has to overcome two major resistances:

1. Friction
2. Inertia

Friction appears as a force opposing the motion. The energy needed to move is proportional to the distance. The faster the machine wants to move, the more energy per time i.e. power it needs to overcome it. At a point the motor reaches its power limit.

Inertia appears while the machine tries to accelerate (or decelerate). It is a force opposing the change in velocity and it is proportional to the mass that is moved. Again the required energy is proportional to distance, the required power therefore proportional to the velocity, and the power limit of the motor determining what’s possible.

The two resistances add on top of each other, so the motor must always have enough reserves to overcome both. In reality it’s much more complex of course, with vibration, flex, stepper characteristics etc. setting additional limits.

Thinking about the machine model

Almost all P&P machines are Cartesian machines. Their axes are stacked up, in the case of Liteplacer like so:

This means that each axis not only has to move its own weight, but also the full weight of all the subsequent axes. The Y axis is bit like the donkey in Grimm’s “Town Musicians of Bremen“:

It should be mentioned, that Cartesian machine model’s limitation can be overcome, most notably by a Delta robot. However it seems that the low cost Delta PNP solution has yet to be found.

As a compromise, some Cartesian CNC routers move the work-piece with some of the axes (X or Y or both) while moving the spindle and tool only with the remaining axes.

This way the weight pyramid can be split in two. In terms of acceleration this makes sense, if the work-piece (and holder) remains comparatively light.

A thought to keep in mind.

Where will the “bottlenecks” be?

From my professional life as a software engineer, I know one must identify the real “bottlenecks” before actually trying to optimize things. Otherwise the optimization will often simply not help. I concluded that acceleration in Y will be one of the bottlenecks for this machine.

There are many questions that follow…