Posts made by benjamin.forest

Hi,
Had this functionality been added ? It would be great indeed. Or maybe could you give me the github ticket number if any, to follow it ? Or the whishlist mentionned upper is not in github ?
I suppose implementation could be similar to M84 ?
All the best,

It doesn't work.

I think it is linked to the calculation method : we are using directionVector, and it is calculated without using kinematics. So I guess everything after this (DDA.cpp, ~line 300) is miscalculated. Notably afterPrepare.cKc will have the wrong sign when hmz0scK is calculated in DriveMovement.c, ~l542, as you guessed earlier. My problem is that changing my model won't change that.

Besides, I thougth about calucations performed in PrepareDeltaAxis and CalcNextStepTimeDeltaFull, but I do not manage to get the full picture. I can link tower position to motion direction and the percentage of accomplished motion, but that does not adds up with the code nicely. I get things in common, like A, B, aA, bB, but I'm still missing some pieces of the puzzle.

I don't get where the speed/accelerations, that seemed to be calculated in cartesian tool coordinate system are translated into articular one either.

Sorry if my questions seems naive.

All the best,

Great thank you !
I'll try right away.

It's really cool to calculate the quadratics equations, I didn't thought of it.

any tips about dsK signification ?
All the best,

@JoergS5 Thanks a lot. I've seen it was a popular fork, I'll look into it.
@dc42 Thanks as well. I'll try to get something out of Movement / DDA debug.

Hi,

Has anyone made any progress on isolating parts of RepRapFirmware ? I'm struggling to create a new kinematics, and the debugPrintf debugging method is not my favorite ...

On the other side, my quick tentative to extract a few cpp files from Movement folder lead me to Core.h and other deeply target-related files, so it seems quite intricated. Am I missing something ?

All the best,

Thanks for your time, I really appreciate it.

About the model, I agree that this is equivallent if the carriage are below the end effector. This is what I tried when I inversed motors directions. Maybe I screwed up with my model, though.

About pure Z motion :line 117 of DriveMovement.c, a comment about pure Z movement let me think that maybe it was handled differently ?

A few more questions if you have time, since i'm trying to read the code to try encircle my problem :

• It seems that LinearDelta does not use segmentation (GCodes.cpp, l.2047). I was thinking that segmentation was typically used for non-linear robots. What do I miss ? Is segmentation done somewhere else ? Probably in DDA, but where ?
• What does DDA stands for ? Wikipedia propose "Discontinuous deformation analysis", but that does not seem to correspond ;). Looking forward in results I found Digital differential analyzer, which seems better ! Is that correct ?
• So if I undestand correctly, DDA is performing two things : Motion planning, and rasterisation. Correct ?
• I'm a little lost with the functions Prepare, PrepareDeltaAxis, CalcNextStepDelta, CalcNextStepTimeDeltaFull. Are they following a known algorithm ?

My problem seems to come from DriveMovement.cpp, around line 527 : dsK < 0.
When I try a simple G1 Y10 motion for example, dsK is < 0 for two of my three axes, leading to bad motion. Do you know what it could mean ?

All the best,

I note as well that for pure Z motion, kinematics does not seem to be taken into account ...

I suppose I mp.delta parameters are miscalculated maybe ?

I've tried three strategies :

Invert Z in LinearDelta Model
Works, but X/Y moves in head coordinate system triggers wrong direction for motors. Leads to a strongly parabolic bedplate.

Change Linear model and inverse motors directions
Works for Z, but refuse motion for some axes in X/Y motion (dsK in DriveMovement taking negative values). Leads to only one axis on three moving for an Y motion for example.

Change Z at the source, in G1 command handling
Not interesting, but works. But create other problems (appart from not being maintainable), such as handling all function that need inverted Z.

Thanks,
A small video shows our printer in motion : https://youtu.be/gORqC7tfNXI?t=22.

Basically it is a LinearDelta, where the Head is fixed, and the bedplate moves. The only difference from a model point of view is a -Z instead of Z in CartesianTMotorSteps / MotorStepsToCartesian.

Thanks for your answer. I'm aware of M111 commands but they havent been that usefull so far, my problem doesn't seem to reach them.

Any doc on DDA / DriveMovement general principles ? I get it that it is responsible for motion trajectory planning, but can't get a general view of their flow ...

All the best

Note that I take any advice or documentation about DDA, DriveMovement and algorithm used as well

Hi,

As mentionned in a previous post, I'm struggling with something which seemed simple on a first glance but is a real pain in reality, ie adding an "inverse delta model" in kinematics.
This is because the delta kinematics logic is actually being disseminated in the firmware (search for isDeltaMovement for example).

I am not sure to perfectly understand why the DDA needs to know it is performing a delta movement, but I am encountering difficulties to understand what's going on, and where my motion fails.

Do you have any tips about how to efficiently debug my kinematics, without adding debugPrintf, or M111 commands ?

All the best,

Thanks, I'll think about it.

Sure, I'll be thinking about it. I remember you were working on some test as well, did you publish something about it ?

All the best,

Thanks, that's a good Idea. I made this by error when I started trying. The problem is that if it works well for Z, when moving along X/Y the model is no longer valid, since motors are moving in the wrong direction. This lead to the motion being parabolic and is not usable ... Unless maybe I change my model accordingly ? I'll investigate if no other solution is possible.

Thank you very much for taking the time to understand my problem, it's always a good thing to explain things, and helps my self understanding of what I've done !

All the best,
and until my next post

Yes, but I didn't found the way direction is actually calculated

bool DriveMovement::PrepareDeltaAxis(const DDA& dda, const PrepParams& params) noexcept Does seem to intervene as well, but I don't know how or when ...