cancel
Showing results for 
Search instead for 
Did you mean: 

Confusing about behaviour of L6470 MOVE(dir, n_step) command

Muscle Man
Associate III

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.

1 ACCEPTED SOLUTION

Accepted Solutions
Muscle Man
Associate III

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...

View solution in original post

2 REPLIES 2
Muscle Man
Associate III

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.

Muscle Man
Associate III

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...