Pseudotron Kinematics

[Cognirit]

Good day everyone!

@dc42 I wold like to add new kinematics to the Duet3D ecosystem.
Later If everything works out and it is possible, it would be nice if we get the number 511 for our kinematics.

I have already read the post https://github.com/Duet3D/RepRapFirmware/wiki/Adding-New-Kinematics

I want to warn you right away that I am not a software developer. Also in the design being developed there are a number of points that I personally have not seen before in application to 3D-printers. In this regard, I had several questions, which I hope to sort out with the help of colleagues from the forum. Therefore, I thank you in advance for your patience and assistance.

============ Story mode activated ============

First of all, about the idea itself. Back in 2014, when I first made my first 3D-printer and was looking for alternatives to Bowden extruders, I came across an interesting approach, well described and illustrated here: https://pseudotron.ist-dein-freund.de/ideas-for-an-alternative-to-bowden-extruders.html

As follows from the article, to remove the extruder motor from the working area of ​​the 3D-printer, it was proposed to use a differential on the leadscrews, and then the idea was theoretically transferred to belts.

At that time, the idea was shelved, and a couple of years ago my colleague and I (both instrument-making engineers by education) remembered it again and it dawned on us how to implement it. A couple of days later, 3D models appeared, and a week later we assembled a real-life prototype.

Then, for a long time, we were looking for very long closed belts (we even tried to splice non-closed belts, which gave a result, but not very reliable).

And now, six months ago, a seller appeared on AliExpress who had closed belts of the length we needed. Having purchased them, we rebuilt the prototype for new belt sizes and now we have a fully mechanically and electrically working prototype.

Its main feature is that absolutely all motors are placed outside the working area of ​​the printer, because we want to achieve printing with high-temperature plastics (do not blame us for using belts, we are solving the issue)

============ Math mode activated ============
We compiled kinematic equations and tested them on a prototype by controlling GCODEs (for this we took Cartesian kinematics with 5 axes, where one of them is the Z axis). So we can say that the equations are correct (up to a sign):

E1=-A-C+X
E2=-B-C-Y
X=B-D
Y=A-C

Having solved these equations, we obtain:

A=0.5*X+0.5*Y-0.5*E2
B=0.5*X-0.5*Y-0.5*E1
C=0.5*X-0.5*Y-0.5*E2
D=-0.5*X-0.5*Y-0.5*E1

============ Question mode activated ============
While trying to view the kinematics files, I did not manage to understand everything, so there are a couple of questions:

1. Is it possible within the existing kinematics of the Duet3d ecosystem to control the extruder using a differential approach?
2. In general, it looks the same to me as CoreXY, except that an extruder is used instead of the second axis of motion. As a result, we get something like CoreXE1, CoreYE2, but combined into one system of four motors. Am I thinking in the right direction?

So I'm trying to figure out which side to approach the software part of adding kinematics. If the current assumptions are correct and there are no fundamental restrictions, then I take the ZLeadscrewKinematics class as a basis and from it I try to write this CoreXE1-YE2 miracle

============ P.S. ============
Colleagues, if you are interested in photos / videos
prototype while running - let me know. I will photograph and send. Because to understand the operation of this device by looking at the rotation of motors and belts is another charge for the brain

============ P.P.S. ============
I would also like to express my gratitude to everyone who took part in the development of the Duet3d ecosystem. I think the project is very cool, convenient and necessary. And not only as a consumer, but also as an engineer who values ​​modular solutions and data buses

[T3P3Tony]

@cognirit said in Pseudotron Kinematics:

Is it possible within the existing kinematics of the Duet3d ecosystem to control the extruder using a differential approach?

No its not.

As far as what the best approach would be to tackle this, @dc42 will need to provide some direction.

I note that extruders and motion axis often have very different parameters for things like steps/mm, acceleration, jerk etc. How does the system perform mechanically with these tightly coupled together? Before spending a lot of time on kinematics it would be possible to craft some manual gcodes (of the form G1 Xnnn Ynnn Ennn:nnn) to test this I suppose

[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:

1. To begin with, I chose Cartesian kinematics in the firmware
2. 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.
3. 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.