Extra Motor Driver
I have a Deltabot, and I would like to use my Extra Motor Driver to mirror the actions of the Z axis (not the z tower).
The plan is mount some fans to raise/lower/mirror the effector platform using the extra motor driver.
That requires heavy changes in code. We currently only support 4 motors for path planning and have no plans to increase that.
I am re-reading what I typed, and I might not have been 100% clear.
I want the 3 motors to control the effector platform as usual in a delta. But I want the value for Z height, to additionally control the "extra motor".
I suppose I could post-process my gcode, and add in lots of
G201 to make the extra motor keep up, but it seems like it would be easier to make it use the value for z height.
So what part of the code should I look into modifying? I think the part that parses the gcode and finds the value for Z in G0, the same time it takes that and hands it off to the path planner for delta control, it could at the same time internally send the value to the extra motor. could you point me in the right direction here?
No, I understood you fully. M201 will not work since it stops all other moves.
What you need is a extra dimension in nonlinear bresenham to handle your motor. Currently you have virtual axis, X,Y,Z and E and there you would need to add Z2 or however you would call this. Then in transformCoordinates you woudl also compute Z2 from x,y z and set it.
This is not really complicated, it only goes through quite some parts of the computation in motion.h/cpp. You would also need own accelerations and jerks for that motor and at last conditional compilation to only include all that stuff when needed. And it will take more ram, so a due based board would be good.
That would be the 100% correct solution. If it needs less steps/speed then the rest you might be able to handle this in a interrupt correcting while needed. Would reduce modified code greatly but requires that exact position is not an issue, which is the case here. Problem here arrises if you need acceleration. As long as you can simply add a step every inerrupt call or do not add it you are finished quickly. If this looses steps so you need acceleration this becomes more complicated.
Ah I see, that is very helpful. luckily I do have a Due+RADDS in one of my systems, so hardware wise I'm set.
but I am looking at motion.h/cpp, and the syntax is pretty daunting. At least I know where to look if I'm feeling frisky.