Extra Klippy so it can also work with a dispenser instead of an extruder

General Discussion
21

For what its worth, I suspect you’re doing to discover this isn’t the case, unless you have no requirement for any precision in the sizes of features you’re “printing”. I have a setup here, running Klipper, that does pretty much what you’re talking about doing, just with other fluids. And without precise control of extrusion/dispensing rates, the output is essentially useless. It may be fine for a robot that is automating dabs of glue or something, but its really not otherwise. (Basically, if you’re dispensing/extruding while stopped, good. If you need to do it when moving, its just not going to work.)

So you probably should be planning from the start how you’re doing to do that, otherwise you’re likely to put a lot of work in and discover you need to start over.

The problem I immediately ran into is that Klipper has no way of coordinating concurrent moves across axis, and can’t aggregate moves between gcode commands, and when you’re doing fluid extrusions at fine levels of detail, you quickly run into the problem that small moves (or segments of arcs if you’re using the arc support) end up with extrusion rates that are at or below the minimum rate your control electronics can handle.

If you’re using an external device like the one you linked to, you’re also going to have a lag problem – even a millisecond or two lag is going to cause extrusions to end up in the wrong place. Klipper really needs to know precisely when its going to start and stop, and I suspect you will not be able to tune pressure advance enough if you’re sending commands to an external device with no feedback. (And to use any feedback, you’ll need a custom kinematic for the extruder.)

My toolhead utilizes a stepper, which at least gives me an immediate response to increasing and decreasing extrusion pressure. The problem I’ve got is that the smallest extrusion amount that Klipper can handle with 256 microstepping is about 0.00002mm at a 1.8 degree per step and 1mm-per-rotation rate. And, as it turns out, that’s bigger than the E moves that end up being required. Some slicers will do extruder pressure smoothing across moves (meaning, it’ll do multiple XY moves coordinated with a single extruder move) but Klipper doesn’t do that, so an E step less than that just rounds to zero and nothing comes out.

I ended up having to override G0 and G1 such that if there’s any non-zero value of E, it has to be +/-0.00002, to make sure things get output.

Basically, the TL;DR is that you may find you need a more sophisticated setup than you think, and if you do, you may discover the very long list of shortcomings in Klipper when you’re doing something that isn’t 3D printing. In my case, I am stuck with Klipper because the microfluidics toolhead runs on the same kinematic frame as my 3D printing toolheads, and the controller is Klipper, so it uses a combination of some tweaks to Klipper’s code and a few thousand (ugh) lines of gcode macros.

1 Like
22

As I did read your case previously in this post - for me it’s look like you did hit your hardware resolution limits, not klipper limits, and you chose to go thru nightmare of changing software but should upgrade hardware to get more detail control.

23

No, its a Klipper limitation, largely because of its broken implementation of arc support, but also because it both doesn’t aggregate extrusions smoothly and can’t coordinate moves asynchronously between different axis, unlike other firmware out there. When an existing hardware configuration works fine with other system, the limit is on the software. And, really, its strange to argue otherwise given the huge number of forks from people trying to work around these limitations. klipper-for-cnc improves a bunch of them, but there’s architectural issues that make proper coordination of motion problematic with Klipper, and adding ABC axis support makes a lot of them worse.

That’s a pretty significant series of problems that, as others have found, mean Klipper doesn’t work for controlling robots that aren’t FDM printers. Its bad at lasers or cutters, it bad at fluid extrusion systems, and its particularly bad at high precision work.

Which is fine – but if someone isn’t intimately aware of Klipper, its good for them to know the limitations before they go too far down that route. With what OP described, they’re going to run into them. (Really, theirs will be worse if they’re trying to coordinate with an asynchronous external extrusion system over a slow link.) Given they’re clearly spending some real cash on trying to get it to work, implying it’ll just work is kind of shitty.

24

Please point me to at least one firmware which can do REAL coordinate moves asynchronously between different axis by working on step based hardware systems. I’m serious !, I want to see a code which will be driving stepper drivers on such low level, because to achieve that task - that code need to manage a time periods for each single step, and driver need to support that.

As I’m aware - to achieve those goals you need a Servo based systems, not step based, because you can hit hardware resolution limits much sooner on step based system than in Servo based.

25

RepRapFirmware supports it – and its commonly used in robots that have multiple concurrent tools supported – via the M596 gcode that sets the active movement queue. Movement queues are run in parallel, so you can split axis among different queues and coordinate them that way. And, really, its a few lines of Arduino code to do it custom – there’s nothing magic about coordinating steppers. Taking two moves in X/Y for a single move in E is trivial to do, its just that Klipper doesn’t have a way to do it. Even if you weren’t trying to be fancy, you just run each axis in a thread. Coordinating threads is pretty basic programming, after all.

But that’s really only a limitation because the people who have run into this problem wanted to work around the extruder limitations by using another axis, like A, which would enable you to collapse extruder moves under a single G1 A… command while the kinematic is moving appropriately with G1 X… Y… commands. Given the feedrate and the distances, they self-coordinate. (That’s actually another issue with Klipper that has been an issue with klipper-for-cnc – Klipper’s feedrates are tied to a linear speed along all the axes, which is a bigger issue when you get movement in more than two or three at a time.)

And, this is really a separate issue, my point was that OP was probably wrong in the assumption that they could ignore extrusion rates at first. There are a lot of people who have built system like they’re trying to build, at least a half dozen public forks trying to improve Klipper for these scenarios, and a bunch of private forks (like mine), and the point was to make sure OP was thinking through all the potential issues and making better informed decisions about how to meet their requirements.

26

Your sample is not valid, RepRap Firmware can’t do real asynchronous movements between different axis. That command M596 is just creating parallel synchronization layer which have some “fake” independency but in hardware it will be still synchronized at some point.
BTW seems klipper have same possibilities as M596 in RepRap - with separate synchronization queue

SYNC_EXTRUDER_MOTION
DUAL_CARRIAGE

Yes, most probably you are right, that is wrong assumption.

That why I did my initial statements, because you was blaming the software, but real issue is hiding in step based hardware (Stepper motors)
With step based hardware you can’t reach real synchronized smooth controllable moves between 2 points, with steppers you have only 2 options: first is to bind your velocities to single step timings or you must have much greater hardware resolution to do approximation movements.

27

That’s a lot of words to say “I don’t know what I’m talking about”, but this isn’t helping OP, so I’m going to bow out of the discussion. Cheers!

28

Of course you can already use Raspberry Pi GPIO pins, but, and this is the killer question, can you live with “sloppy” timing? The problem is that the Linux OS is doing many things and is a general-purpose OS so you can never get really good real-time control over the GPIO pins.

That said it is very easy, nearly trivial to add another MCU to Klipper. You can buy a $5 Raspberry Pi Pico and it will have about a dozen pins you can use and the timing will be quite good.

However if you can live with Linux’s timing, you save $5, a USB cable and some effort.

You will need to tell us about the pump and the timing precision it requires. Also, look at the voltage and current you need. GPIO pins on the Pi3 or Pico are all 3.3 volts and can supply very few milliamps.

29

I agree with you so much. <3

@Sam I believe that you will eventually understand the depth of the sentence “Klipper is a 3D-printer firmware”, and realize that it actually means “Klipper is a 3D-printer firmware only”.

Having walked the path of Klipper customization, I’d really really really advise you to use something else. Be them RRF or any of the open-source GRBL successors that spawned recently.

Due to its underlying stiffness, I’d bet it will be succeded by a re-write in a few years. If that ended up being the case, sticking to Klipper makes no sense.

Same.