2023-06-02 10:33 AM
HI folks!,
I'm here because of I am a little bit confused about the behaviour of MOVE
commands sent to a pair of L6470 devices connected in daisy chain.
The problem that I'm facing happens also if I sent the commands only to
one motor.
In our project both the stepper motor spin a valve and in this project's
phase we can see the valve mounted on the motor's rotor.
The motor step angle is 1.8 degrees (200 full steps per revolution) and
we set the STEP_SEL field of the STEP_MODE register to the value
of 7 so that the step mode selected is 1/128 microstep.
The Homing procedure goes fine, the homing switch is correctly engaged
and after that event if I sent a GETPAR(ABSPOS) I get the zero value for
the ABSPOS register.
With a motor with 200 full steps per revolution and a step mode of 128
microsteps, to make the rotor perform a full revolution of 360 degrees
we send to the stepper a MOVE(DIR, 25600): we effectively see the rotor
rotating for 360 degrees.
Then the PROBLEM:
After the Homing procedure, we want the motor rotating clockcounterwise
for 4267 microsteps (25600 * 60 / 360) so that it reaches a -60 degrees
position and then rotating in the opposite direction (counterwise) for 8533
microsteps (25600 * 120 / 360).
So in sequence the commands sent to the motor are:
GETPAR(1) /* Get ABSPOS; it returns 0x000000 */
MOVE(0, 4267)
GETPAR(1) /* Get ABSPOS; it returns 0x3FEF55 ( = -4267 ) */
MOVE(1, 8533)
GETPAR(1) /* Get ABSPOS; it returns 0x3FFCF9 ( = -775 ) */
Every GETPAR command is sent after the previous motion command
has completed.
The RESULT:
The first motion hits the -60 degrees position; the second one puts
the rotor at 0 degrees instead of +60 degrees.
Also the wrong things concerning the second MOVE command are confirmed
with the ABSPOS reading (we expected a value of 0x2155 (+8533), we got
(0x3FFCF9, corresponding to -775 !!!)
I cannot realize where we are wrong.
Is something wrong about the reasoning I made and the simple numbers
I computed?
Thanks in advance to everyone will reply.
Solved! Go to Solution.
2023-06-05 03:15 AM
Talking to a workmate of mine, he suggested me the fix..
I let the SW_MODE bit cleared after the Homing procedure,
so every time I sent a MOVE command that crossed the
homing switch (we used a Hall sensor to accomplish that)
the L6470 driver stopped the movement with a hard stop
command...
2023-06-05 12:18 AM
Hi,
this morning I downloaded X-CUBE-SPN2 package and after properly modified
the motor parameters for our stepper motors, I've used a Nucleo-F401 board to
run the STM firmware and to reproduce via UART the same MOVE commands
that on our design manifest the problem above reported.
The result is the same, the second movement does not put the rotor to the position
corresponding to the +60 degree angle.
2023-06-05 03:15 AM
Talking to a workmate of mine, he suggested me the fix..
I let the SW_MODE bit cleared after the Homing procedure,
so every time I sent a MOVE command that crossed the
homing switch (we used a Hall sensor to accomplish that)
the L6470 driver stopped the movement with a hard stop
command...