Thanks, My fault. The Printer is not inverted. You can see it in action here : https://youtu.be/gORqC7tfNXI?t=22 . The bed is at the place of the hotend and moving, the hotend is fixed, above the bed.

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.