Pseudotron Kinematics

dc42

@cognirit currently, extruders do not take part in the kinematics processing. To support the type of kinematics you describe, we would first need to include extruders in the kinematics processing, so that the motion of extruder motors takes into account other motion that is happening.

Another complication is that it would be difficult (but probably not impossible) to apply pressure advance, because it would have to be applied to all four motors.

A further complication is that the mechanism to track and accumulate partial extruder steps would need to be modified.

I have seen other proposed kinematics in which for each extruder, the movement of only one motor is affected by the desired extrusion (and the movement of that motor is also affected by X and/or Y movement). Pressure advance and partial step accumulation would be easier to apply to such a system, because for each extruder they would only be applied to one motor.

Cognirit

@dc42 said in Pseudotron Kinematics:

currently, extruders do not take part in the kinematics processing

I knew it =(

Is there anything I can help you with?

@t3p3tony said in Pseudotron Kinematics:

How does the system perform mechanically with these tightly coupled together?

Perhaps the text will not be able to describe it very well. But it's rather funny when the operation of one motor leads to the movement of one axis and two extruders in different directions at the same time And for linear movement without rotating the extruders, you need to use all four motors.

Probably, I really should send a video of his work.

@t3p3tony said in Pseudotron Kinematics:

it would be possible to craft some manual gcodes

I did this before creating this theme. Perhaps not quite that way. Here's what I did:

To begin with, I chose Cartesian kinematics in the firmware
Then I created the X, Y, U, V axes (all with the same parameters for speeds, accelerations, currents, etc.), plus Z for the vertical axis.
After that, following the kinematic equations, I wrote GCODEs manually into the web interface console such as:

G1 X-50 Y50 U50 V50 (Linear movement along the Y-axis by 50mm)
G1 X0 Y-50 U-50 V0 (E2 clockwise rotation)

etc.

After making sure that the result matches the equations, I decided to write this post.

========== New Question ==========
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?

========== P.S. ==========
@T3P3Tony, @dc42 It was very pleasant to receive two detailed answers at once and very quickly. I would like to thank you separately for that!

fcwilt

@cognirit

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

Cognirit

@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.

JoergS5

@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.

Cognirit

@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!

JoergS5

@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.

Cognirit

@joergs5 Thanks for the clarification!
Now I’m sure that I’m going in this direction.

I would also like to hear the opinion of colleagues @dc42, @T3P3Tony on questions and clarifications that I gave in the fourth message.

Thank you all very much for your time.

T3P3Tony

@cognirit

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.

JoergS5

@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.

o_lampe

@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)

JoergS5

@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.