Implement M569.3 Read Motor Driver Encoder in the 1HCL.
-
Implement M593.3 Read Motor Driver Encoder in the 1HCL. Have it work in open loop as well as closed-loop and assisted open loop.
-
@LindsayC And make it a parameter in the object model. This is actually more important.
-
@LindsayC Ditto!!!!
-
undefined davidjryan referenced this topic
-
That should be M569.3. Typo in the title.
[Fixed by Moderator] -
Another option. Rework M569.5: Closed loop data collection, so it can output to the standard output (eg the console) instead of to a file. This way it is something G-code could read back in the "reply" parameter and use, as well as external programs just getting the data stream directly instead of having to ask to download the file created and then parse it.
-
@LindsayC what's the reason for wanting to read the encoder directly? How often do you want to read it?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 I have an application with hard mechanical endstops for 2 positions built into a rotary valve. driven through a gearbox (5:1 precision planetary) with a NEMA 17 stepper and encoder. Angles can be between ~10 degrees up to ~90 degrees depending on application between the stops depending on valve design. In the application getting between the 2 positions quickly (sub 200 ms) and accurately is useful for various reasons.
The idea is to home and accurately find the 2 relative positions. First move in one direction stall and find the angle between them by finding the stall position and corresponding encoder count for position 1. Then move in the opposite direction till I hit the stop and stall and find the encoder count there and calculate the 2 positions based on that information . I have now discovered that there is a position error in full steps in the object model I can use instead that should work for this purpose when combined with the current position.
-
@LindsayC Although weirdly the position error is associated with the 1HCL board driver itself (boards->2->drivers->positionError) and not the axis it's assigned to (Move->axes) as you'd expect.
-
I would also benefit from being able to read the encoder directly.
My system does not work for Closed loop (no encoders have enough counts to be 2x+ my full step counts) but would like to implement meta commands with loops checking for acceptable range of encoder ticks since last referenced. Essentially exactly what M569.3 would provide.
-
@LindsayC said in Implement M569.3 Read Motor Driver Encoder in the 1HCL.:
@LindsayC Although weirdly the position error is associated with the 1HCL board driver itself (boards->2->drivers->positionError) and not the axis it's assigned to (Move->axes) as you'd expect.
To me the position error makes sense to be per driver because an axis may have more then one driver (e.g an gantry with a motor to drive each side) and the error will be different between those two drivers, even though they are on the same axis.
@LindsayC said in Implement M569.3 Read Motor Driver Encoder in the 1HCL.:
I have now discovered that there is a position error in full steps in the object model I can use instead that should work for this purpose when combined with the current position.
does this mean you can achieve your aim of determining motor position at each end using the position error?
-
@T3P3Tony It's is sort of round about, but it works reliably.
