two-stage axis for large printers

[Whosawhatsis‏]

I was thinking that for large printers with big, heavy gantries (I'm thinking of building-scale printers, in particular), it might be useful to have two motion axes capable of moving in the same direction. One might be a huge, heavy gantry that comprises most of the printer. I'm imagining this running on tracks on the ground, or maybe even vehicle wheels. Such an axis couldn't more terribly quickly, but more importantly, it would not be capable of high acceleration or high frequency oscillation for infill patterns.

To get around this problem without needing to slow the whole printing process, another axis might be provided all the way down at the toolhead. This would be a much lighter axis, and it would be kept light by keeping its maximum length of travel very short. The two axes would work together by essentially running the motion commands in that axis through a low-pass filter. The low-frequency motion is sent to the big gantry-carrying axis, and the machine would carry around a variable for the position error of this axis, which it would compensate for with this error at the toolhead.

A PID loop would be needed to ensure that the large axis would ramp up its speed before the small axis reached its limits. It would also be a good idea to use some kind of encoder or precise distance sensor that is decoupled from the motor drives on the large axis to feed the error variable, rather than relying on dead-reckoning. This is particularly true if the gantry is carried by wheels on the ground. Rather than laying down tracks, you might just put a stake in the ground at each end, and let the machine drive on wheels, but with a string (or preferably something more like a timing belt) running from one end of the build site to the other, around a pulley attached to an encoder on the printer vehicle.

I can even imagine a system that works like a Hangprinter, but instead of suspending the printer mechanism by using motors to pull in and let out each string, you just put a constant force spring and an encoder on each one (basically a tape measure sensor), so that you are precisely measuring the distance from some point on the printer to some fixed point on the job site. Combining several points at various heights, this should give you very precise positioning information on a wheeled printer vehicle as it moves (you'll want enough of these measurement points to also measure tilt), and you will compensate for the error on the small high-speed printer axes.

Linear axes may not be ideal for these smaller, faster-moving axes. If you're only doing one axis of compensation, this could be an ideal application for the Scott-Russel linkage. For more, I can easily imagine an angular deltabot, a SCARA arm, or even 3-axis serial arm being ideal.

I've thought before (particularly before multi-start leadscrews were easy to find) about using a hobby servo or the linear stepper from an optical disk drive to give you faster motion over a short range of motion for a Z axis to speed up Z lift (this might be useful for other applications as well, like making it possible to use mesh compensation on an IDEX machine), and multiple small-axis stages might even be able to simplify (or at least shrink) a Project Escher-type system. I can imagine several Helios-like machines mounted to a beam with overlapping ranges of motion, which is all mounted to a big, slow-moving 1-to-3-axis machine that moves that beam around as the print progresses to give those smaller print mechanisms different areas to work on.

[Whosawhatsis‏]

Forgot to mention, an adaptive look-ahead algorithm would be really useful for this. The simple and obvious use would be to cut out unnecessary motions for the large axis.

Say you have a machine with a large Y axis and a little Y axis. While infilling a wall that runs parallel to the X axis, a naive PID algorithm light let the big axis slowly rock back and forth in a roughly sinusoidal pattern as the small axis runs a sharper sawtooth-wave-like infill pattern. If this sawtooth fits entirely within the little-Y axis's range of motion, you can just low-pass filter the motion and have the big-Y axis hold still, saving wear on those parts. That unnecessarily repetitive big-Y motion could also wear a trench in a muddy job site if the machine is running on wheels, which would cause the machine to bump as it drives over it later, and could cause layer misalignment in other parts of the print if the error it causes isn't tracked very well.

A less obvious use would be for when the printer approaches a corner. Say you're printing a long, straight line along the X axis, approaching a corner that leads to a long Y axis move. Big-Y could move in the opposite direction of the upcoming long Y move in anticipation of it, so that little-Y is at its maximum extent. Then, as the corner approaches, big-Y would start to accelerate, so that little Y would hit its maximum extent in the other direction just as the machine reaches the corner. This way, the machine would be able to continue its motion along the axis at maximum speed, because the big-Y axis (which can't handle the high acceleration that cornering would otherwise require) is already moving in the direction of the long Y move before that move begins, and little-Y has been taking up the slack so that the toolpath is not changed by this extra move to enable the early acceleration.

The whole thing could, of course, be allowed to happen in reverse at the other end of the Y axis move to allow big-Y to decelerate smoothly as well. Of course, if there's a short X jog followed by another long Y axis movement, you may be able to carry out that move with the little-Y axis without the big-Y needing to slow down.

[Daren Schwenke‏]

As to the position sensing, I wonder how this would do outdoors.  
This would eliminate the need for physical coupling.  Just stake two of these on the corners and you have your position in 3D space:  https://hackaday.io/project/160182-hivetracker

Would probably need a much more powerful laser or modulation/carrier tone to more effectively differentiate the laser pulse from the ambient IR.  

I do know laser levels (the spinning type) work just fine but you basically get the entire beam instead of dropping off as a square of the distance like this would. 

I'm not sure about the low pass filter.  I get the concept, just struggling with how that would keep the fast axis from over-running its limits.

I think if I was writing this I would just seek to keep the fast version of an axis near the center of travel.  If the commanded position of the axis would cause the fast axis to need to leave some defined center region, then start to move the slow axis.  Basically have the PID loop for the slow axis dependent on the position of the fast axis, with a dead-zone. Coming up to a corner, your center region could be shifted to allow for the behavior you described above.

Perhaps that ultimately is the same thing as the low pass filter? 

I still have the dream of a tripod kinematics super-critical CO2 foam house building robot (which you then immediately fill with concrete) with three towers/cranes floating around in my head.  Not very space efficient I admit, but would be really fun to try nonetheless. 

[Daren Schwenke‏]

On a similar note, another idea.

If you added a 'start' position sensor to two normal laser levels, and the rotational rate was very regular, (it probably already is) you could then determine your position in 3D space with some form of bar sensor on the printhead by measuring the arrival time of the pulses compared to when the start pulse was detected.  

To avoid being blocked by the structure you are building, you would probably have to position the laser levels higher than what you are trying to build, and your sensor bar would also have to be at least as tall as your structure, which could pose an issue.\

But it's a thought.

[Ryan Carlyle‏]

I wonder if MachineKit could implement WW's positioning scheme pretty easily? Run a heavy X axis with low peak accelerations, and use the blending trajectory planner to round off all the sharp corners within a REALLY coarse tolerance limit (like 50mm). Then run a slaved U axis that is fed the error between the nominal trajectory and blended trajectory. MachineKit has all the necessary guts to run complex feedback loops and nested motion control schemes. I'm just not sure if you can access the blending planner error. Blending also only worked for 3-axis motion last time I looked, which means you need to use wire-printing type techniques with a slaved extruder as well. (I'm by no means a MachineKit expert.)

[dcro...@duet3d.com‏]

Ian Pegg is already doing something similar on his large CoreXYUVAB 3D printer. His machine has a separate gantry to carry the heavy extruder drives, which are coupled to the print head via short Bowden tubes, and a load-balancing gantry above that to counter the vibrations. Originally he was driving all 3 gantries in sync, with the load-balancing one moving in reverse. Now he uses a GCode post-processor to drive the extruder and load balancing gantries separately, so that he can avoid having them follow short rapid movements of the print head. See https://www.youtube.com/watch?v=rOP9QYAlhZU.