I’m Sam, a mechanical engineering student. I am currently converting a RatRig vcore 3.1 printer for a uni project such that it can print liquid metal. This is for flexible electronics.
So for this application, I am not using a standard extruder but rather a pump/dispenser that can deposit precise amounts of liquid metal.
I would like to control this pump using my Raspberry Pi on which I am currently already running Klipper. Is it possible to write an additional Klippy that controls GPIO pins of the Pi when normal extruding should be done by the extruder? So this Klippy should be able to analyse when printing is done at what speed and then pass it on via the GPIO pins. I want to keep the full flexibility of Klipper.
Can anyone support/help me in this? I myself am very inexperienced with 3D printers and even less with coding.
Just FYI, one of the features I hacked into klippy is the ability to home extruders, just like the remaining axes. This is useful for syringe-like extruders (e.g. as in liquid handling robots, or other cold-goop-extruders).
Thank you so much for your response, I have been struggling with this problem for a while now…
The pump that I’m using is this one:
The idea was for these to be controlled using the RS232 protocol with a written python code. For the first version the pump doesn’t need to be synchronized with the XYZ (I think is never gonna be necesery). So the main thing is just turning the pump on and off at a constant speed defined in the G-Code.
If the RS232 protocol is to diffucult to handel I would transfer the data of when to extrude and at what speed to a computer (using the Pi). Then I would control the syringe with LabVIEW.
The main goal is to read out about when to print at what speed so that I can then use the Pi for the syringe.
An XYZ CNC machine that moves a dispenser tool to a spot.
To know when the machine has arrived at the spot.
To command the dispenser to dispense.
To know when the dispenser is done dispensing.
To command the CNC to move to the next spot.
Repeat.
Is all that correct?
I’m not sure I got what this means for the Klipper part. I’m not familiar with LabVIEW.
If you want to run your program just from GCODE, this would essentially mean that Klipper will be coordinating everything. You can write an extras module that talks to external stuff, waits for things to happen, etc.
But this road will lead you to months of spelunking uncommented code, with lots of undocumented behaviours (other stuff is really well documented), and potentially intense suffering if you are in a hurry.
From my understanding so far, it would be best if you avoided this, and instead treat the motion system and the syringe as completely different units, which you coordinate from outside Klipper.
In that last case:
You would interact with klipper through its UDS socket interface (or through moonraker) with a small python program, that also talks to your dispenser/labview.
You can use the G4 command (dwell) and wait for a response. The response indicates that the machine has stopped moving, and thus that you may dispense. I have not tested this very thoroughly.
I’d sugget not using Klipper at all. It is comparatively difficult to use it like this (e.g. lots of delays while waiting for more gcode before moving, complicated (web)socket stuff, etc.) and offers no advantage to the use case you described so far.
The folks at the Machine Agency lab at UW are really great. They have written a python framework to drive their Jubilee printer and coordinate its movements with other hardware (e.g. cameras).
I think it would be great if you got in touch with them. They are looking for poeple with use cases like yours to integrate more tools.
Indeed, my idea initially was to “just” read out (0 or 1) when to dispense, transmit this signal over a GPIO pin so that the pump can be activated. But this is not so simple apparently?
Ah okay, I understand. Another question, is it possible that when extruding/dispensing, another (unused) GPIO pin on the motherboard is triggered (from, say, an unused fan). I could then use this pin to drive the dispenser…
Is this easy to implement in Klipper’s current code?
How do I best programme that a particular GPIO pin on the motherboard goes high when the extruder is working? This may be basic but with my limited knowledge of programming and clipper not at all easy… Can anyone perhaps help me with this on how exactly I best approach it?
This is probably going to be the easiest solution to our current problem.
That feature is meant to sync lasers or spindles to a CNC machine, for engraving or milling. You can surely sync a dispenser to it by changing the PWM duty cycle from Klipper just before a move, reading its output on a GPIO on the Pi, then telling labview to tell the dispenser to dispense, and hope that the sum of all of the introduced latencies is not terrible.
By “when the extruder is working”, I mean when normally the extruder’s stepper motor is driven. This without having to change the G-Code from a slicer…
I use the Klipper on my desktop 3 axis dispensing robot to dispense liquids like UV adhesives, silicones or sealants. I can give you my settings and examples of applications. Maybe it’ll help you.
As you can see, I’m using the same MCU as you . I’m using a similar dispenser to yours. To switch the dispenser I use the foot pedal input and this is controlled via a relay module that is connected to the fan outputs. Here is code from my printer.cfg:
Pin PD14 is used to power the relay module and is always on. I’m only using 2 outputs at the moment. One to control the dispenser and the other to control the shut off valve to prevent fluid leakage when the machine is not running.
I also use a physical button to fill the nozzle with liquid before running the code itself. Here is code from my macro.cfg:
Thank you very much for your response. We are going to try to solve it this way. We ourselves were still thinking of writing a python script and linking it to our slicer so that the G-Code from the slicer is immediately uploadable to our liquid metal printer. We will still share the final result.
