Pseudotron Kinematics
-
Hi,
Is your goal to make your design work or just to have an extruder with the stepper on the frame?
The second is possible already with Zesty Nimble - a remote drive extruder.
Frederick
-
@fcwilt said in Pseudotron Kinematics:
Hi
Greetings, Frederick @fcwilt.
Thank you for your interest and suggestion!Various options for installing remote extruders (including Zesty Nimble) are known to me - have created a variety of 3D printers.
In this case, my goal is precisely to implement the conceived design. Its implementation opens up very interesting technical possibilities. For example, the ability to vertically stack devices for simultaneous printing of several copies of a part. Plus the ability to conveniently make a heat chamber, ease of assembly and other goodies.
And as an engineer, the development of this device was also an interesting challenge for me.
-
@cognirit if you give up the benefits of the rrf code (PA) which are specific for the extruder, you could reassign the E g-code to be a normal axis (maybe by a reprocessing E1 to U, E2 to V) and process the 4 axes in your kinematics code then. The extruder would be handled like a normal linear axis, the firmware cannot know that you're driving an extruder in reality. But this is only a start of course, handling extruder code in kinematics would be the better and cleaner solution.
-
@joergs5 said in Pseudotron Kinematics:
you could reassign the E g-code to be a normal axis (maybe by a reprocessing E1 to U, E2 to V) and process the 4 axes in your kinematics code then
If I understood you correctly, then this is approximately what I plan to do with the help of a post-processing script.
@joergs5 said in Pseudotron Kinematics:
if you give up the benefits of the rrf code (PA)
However, I may not have fully understood this part. Could you describe in more detail and reveal abbreviations?
RRF = RepRap Firmware?
But what is PA ?Thank you!
-
@cognirit sorry for abbreviations, I try to avoid them in general.
RRF = ReprapFirmware, PA = pressure advance*) as example where the firmware has specific code for the extruder, which will be missed if you use the extruder as normal axis. The extruder specific code could be reintegrated in the kinematics code again. I am not sure whether there is other extruder specific code in the firmware. But I would simply try it.
*) I have not much experience with it, for a reason, because it is used for Bowden based printers. Your differential screw doesn't need Bowden.
-
-
Do I understand correctly that now the most realistic way for me to make my prototype work at least on basic techniques without using Pressure Advance and other advanced features is to write a post-processing script for the slicer so that it converts GCODEs from X, Y, E1, E2 to my intricate kinematics with XYUV?
yes i think so.
-
@cognirit a little detail is that G90, G91, M82, M83 are not usable in the usual way to set absolute mode and extruder to relative mode. You'll need a substitute.
-
@cognirit @joergs5 said in Pseudotron Kinematics:
@cognirit a little detail is that G90, G91, M82, M83 are not usable in the usual way to set absolute mode and extruder to relative mode. You'll need a substitute.
And let's not forget, you need a several meters looong axis declaration for V + U in M208 even if you find a way to slice with relative extrusion. (at least for the positive direction)
-
@o_lampe if you program your own kinematics, you have complete control how M208 behaves, you can even ignore it. I've done so for the 5 axis robot, because M208 defines a cube, but robots have a print area which looks a bit like a donut.
