Closed Loop Control of Stepper Motors with Rotary Encoder
-
@sean Maybe you should split your analysis first to know which component is not working correctly, so using this controller with another stepper and then testing the stepper with a different controller.
The controller has ALM connections. I remember a discussion about this setting here:
https://forum.duet3d.com/topic/3519/yet-another-external-driver-question/2
(different controller, but maybe comparable meaning). -
@joergs5 That approach makes sense - my hang up is that i don't know if the settings on the Duet are matching the dip switch settings on the external driver. Questions like fwd v. CW, or Pulse edge rising v. falling, etc.However, I will mix & match drivers w/ motors to see if the issues are consistent.
I don't believe ALM has any bearing on the issues I'm facing. The ext. driver has a flashing LED that tells me when there is an issue, so the ALM connections are just to notify you elsewhere, such as activating a trigger on the Duet as @dc42 points out in the post you linked.
-
@sean Some more ideas: if your tests give no result, you could provide information how your wiring is: which pins you connected, which PSU and connected where (controller for stepper needs 24-48 V e.g.), especially where you connect the + signals. Your T parameters are at the edge of the minimium values, I would try longer times.
(In case you don't know) CW means clockwise, CCW counterclockwise, so I would set this switch to PUL/DIR.
I would not set/use ENA, because it is enabled if unconnected.
-
@joergs5 , the external driver has a dip switch for
"SW5, Motor DIR: off=CCW or on=CW"
"SW7, Pulse Mode: off=PUL/DIR or on=CW/CCW."I currently have it set to PUL/DR and CW to align with the Duet firmware "Forward." (This makes more sense to me than CW aligning with Backward).
-
@sean If you have an oscilloscope, looking at the signals would be another idea. I bought one myself (Hantek 6022) to look at controller signals. Not a quick solution, but maybe you experiment as often as me so that it pays off...
There is a youtube about CL57T, maybe you get some hints:
https://www.youtube.com/watch?v=S8c6c4CYZUU -
Update: I believe the issue was the external driver had a default amp setting of 8A, and the stepper motors I was using were only 2.0 A. When I finally was able to get into the external driver firmware (pro tip: order the RS232 compatible cable AND a serial-to-USB from amazon or something), I could toggle the amperage setting from 8A to 2A and create or turn off the vibrating motor issue I was experiencing.
With the omc-stepperonline driver and stepper motors, the pulse timing in M569 is set to 7.5. Anything less and the stepping from the motor sounded like grinding. 7.5 sounds pretty smooth.
-
I tried using the Closed Loop Stepper Drive/motor combo from Stepperonline. Motors ran OK but from my experience these drives are not truly closed loop. There is no makeup for error and I've switched to a REAL solution. They're Great but NOT cheap (Quality usually isn't)... https://www.teknic.com/products/clearpath-brushless-dc-servo-motors/clearpath-sd/
-
@da-sid-mon What do you mean "no makeup for error?" I am not saying they are perfect, but the driver-motor combo that I indicated above does attempt to correct the lost steps. The bigger problem that I don't see either of the solutions (mine or your linked servos) is that debris / mechanical fault causing lost steps won't be remedied by closed loop. The only thing that these solutions do in my mind is indicate steps were lost BEFORE you find out after the thing runs into a wall.
I'm genuinely curious about your implementation. These systems are new to me.
-
Hmmm... I'm a little reluctant to be "that guy", but at the same time, there does seem to be some discussion of "makeup lost steps" and "find an error before the machine hits something". May I point out that no amount of sensing from the motor shaft will detect a loose belt, or a loose pulley. These two causes are BY FAR the most common reasons for the "controlled point" not being physically where the firmware commanded. A sensor on the motor shaft literally cannot "see" either of these.
I'll be the first to say that a sensor on the motor shaft CAN, maybe, sense a "Jam", a failure to actually move when commanded, aka a "missed step", either because something got in the belt/screw or because the "control point" hit something or similar. At least some of the time a sensor will detect these.
So can TMCxxxx stall detect. Particularly, detecting the case of "things are so far off the machine just hit a travel limit" is extremely reliable.
So... I'm back to my original question: Encoders on steppers seems to be expense and complexity that accomplishes very little or nothing, vs. current state-of-the art drivers and steppers.
Of course, this is a free opinion and worth every penny.
-
I posted this here just recently.