Posts made by Cognirit

@dc42 Good day!

I noticed the release of beta3 in the project changelog.

Could you please let me know if the sensorless homing issue for the Duet3 Extension 3HC board is planned to be fixed in beta3?

Thank you!

@dc42 Can you tell us if there is at least a rough prediction of when the update we need will be released at least in beta? We would love to take on testing it and actively share the results.

@dc42 thank you for reply! Am I correct that we would be best off waiting for this feature in 3.6.0beta3 or later? So as not to interfere with work on beta2?

Good afternoon! I'm facing the same problem.

I am doing a scientific project, I am making a printer as a platform for researching and comparing different kinematic schemes. I expect to use up to 12 independent axes.

In this regard, I was really hoping for Sensorless homing to avoid drowning in wires. I didn't expect that an expansion board might not have full functionality. =/

And the Duet ecosystem is very much to my ideological liking in this respect.

And there is hardly any board for 12 motors

Is there any way to help the Duet project with this problem?

Good afternoon, can you tell me if you managed to solve this problem? Did you end up using the limit switches on additional axes or did you change the board / firmware / find another way?

@dc42 Thank you very much for replying with a mention! Very glad you made a version of this sensor under the RRF! I hope to be able to procure it soon.

@dc42 Thank you very much for your quick response! As always on the level

Good afternoon, I would like to join the question. Can you tell me if support for this sensor has happened in the Duet ecosystem? Or maybe there are other interesting options for faster automatic table calibration? Thanks!

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

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

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

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

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