Instapin_motion problem with a 2-pole pair motor

Hi Adam,

Running from Flash works fine ( a modifed lab13b).

Now I wonder if there is a variable that can tell me when the system is ready to run e.g. setting "gMotorVars.RunPositionProfile = true"

E.g. When the Rs calibration is done and the encoder alignment is done.

What I am after is a signal that is "Busy" from program launch until all calibration & alignment is done.

Best Regards,

Ingemar 

Ingemar,

The best signal to look at would be the gMotorVars.CtrlState & gMotorsVars.EstState.

Hi Adam,

The elapsed time from power on to both gMotorVars.CtrlState & gMotorsVars.EstState are on-line is about 12s.

The gMotorVars.CtrlState takes about 7-8s and the gMotorsVars.EstState about 4s in that order.

This is to long for us we need a system read witin 5s.

I know that we can skip the Rs recalibration or shorten the time of it.

But what to do with the CtrlState time ?

How long time does the bias calculation takes?

An other issue is the max acceleration. We have set it to 120 which is the maximum.

We need more acceleration. The 4 revolutons has to complete within 50ms. Now takes 140ms.

The motor phase current is 10A not near the max user current of 20A at the acceleration phase (ST or Trap curve of course gives faster acceleration but results in over shoot)

_iq gMaxCurrentSlope = _IQ(0.0); this is default in lab13b.

Can I set it to 127.99 ?

Change RsWaitTime too?

What about IPD ?

User system BW (100)

Jerk is set to 2000

Krpm is set to  4

Best Regards,

Ingemar

Ingemar,

Ingemar Dahlqvist said:

I know that we can skip the Rs recalibration or shorten the time of it.

But what to do with the CtrlState time ?

How long time does the bias calculation takes?

I would recommend that you review the InstaSPIN User's Guide for information about reducing startup time.

Ingemar Dahlqvist said:

An other issue is the max acceleration. We have set it to 120 which is the maximum.

We need more acceleration. The 4 revolutons has to complete within 50ms. Now takes 140ms.

The maximum allowable acceleration is 120.0 pu/s, one way to get fast acceleration and not violate this hard limit would be to increase the base frequency (USER_IQ_FULL_SCALE_FREQ_Hz).  This will make 120.0 pu/s into a larger effective value since you changed the definition of what a pu/s is.

Also make sure that your jerk limit is set to 2000.0, this is the maximum allowable jerk.

Ingemar Dahlqvist said:

_iq gMaxCurrentSlope = _IQ(0.0); this is default in lab13b.

Can I set it to 127.99 ?

You can change this but I don't think it will have any impact on the control in lab 13a.

Ingemar Dahlqvist said:

Change RsWaitTime too?

This is available in the user.c file.

Ingemar Dahlqvist said:

What about IPD ?

There is no example of IPD being used with SpinTAC, but you should be able to take the example project that is there and merge it into the InstaSPIN-MOTION labs.  But if you are using a sensored lab you should not need IPD since you have an encoder.

Hi Adam,

I would like to read the following variables sent to SpinTac Position Control block

θ_ref, θ_Fdb, ω, ω ̇_ref

Sorry for the paste did'nt work correctly, I hope you understand what I am after.

I want to know the angular speed, the angle for the instance if the motor is stuck/jammed by some mechanical issue.
The position error variable is not enough in this case.

How do I do that ?

Best Regards,
Ingemar

Ingemar,

I understand the signals that you are trying to look at.  My advice would be to look through the InstaSPIN User's Guide and Lab Guide for some help as to where you can find those signals.

Both of those signals can be found in between either SpinTAC Position Move and SpinTAC Position Control or SpinTAC Position Convert and SpinTAC Position Control.

Hi, Adam,

Can you explain the following, I don't get it.

gMotorVars.PosStepInt_MRev = 2

ST_POS_ERROR_MAXIMUM_MREV (2.0)

What will happen if the motor is stuck before the 2 turn revolution.

The first variable is an Integer but the second is an IQ_24 type.

Error = 2002 should be set bu when in this case ?

It seems that in lab13b if the motor is stuck by mechanical reason the pwm is still on

Best Regards,

Ingemar

Ingemar,

The 2002 error will only engage when the position error, the difference between position reference and position feedback, is greater than ST_POS_ERROR_MAXIMUM_MREV.

The PWMs will always be on unless the position error is greater than ST_POS_ERROR_MAXIMUM_MREV.

Hi Adam,

We have still problems reaching the acceleration we need.
Increasing the motor frequency did not make a signiciant change.
But setting the revolution higher than we thought results in a faster acceleration, this is still lab 13b.
It seems that that the speed is involved in the profile calculation regardless in what profile we choose.
Trapetzoid profile is not good enough either.

We start to wonder if the Spin TAC is able to supply the acceleration we need.
The motor is still the Maxon EC-4 24V, which is capable according to Maxon a time constant of less than 2ms reaching 6krpm/s
We are not even close to those figures.

Can you comment on this ?

It seens that there are a limitation in the position move or eventually in the velocity part in Spin TAC.
I know that our requirement are extreme.
We need to compete 2 turns in less than 20ms. The motor shall according to Maxon be able to do this in mucah less than 10ms .

Best Regards,
Ingemar

Ingemar,

What is the velocity limit you are using for this profile change?  In the Position profile generator the achieved speed (and profile time) is based on the supplied limits of Jerk, Acceleration, and Velocity as well as the position step.  The profile is generated in such a way that it will NEVER violate the supplied limits.  If you want the fastest possible profile you want to raise these to the mathematical limit, but raising the velocity limit above what the motor can do, will result in 

To back-calculate the acceleration to reach 6krpm in 2ms, you need 3000 krpm/s of acceleration.  So you need to make sure that your scaling system is setup so that 3000 krpm is smaller than 120 pu/s.  Otherwise you won't be able to accelerate fast enough using the profile generator.  Assuming that your motor has 2 pole pairs, the base frequency needs to be at least 833.3333 Hz in order to get enough acceleration.

Hi Adam,

We started with
Acc = 120
Dec = 120
Jerk =2000
Vel-Limit = 3500
Base frequency = 800

Too slow response around 120ms for two turn (720 deg rotation) e.g. ten times to long.
Increased the frequency did not shorten the response time significant either.
Then increased Vel-Limit to 12000 ( motor can handle 16000 rpms) and this made quit a change in the response

Best Rehards,
Ingemar

Hi Adam,

We have had quite a succes changing STPOSMOVE properties, getting rid of the of the scaling, we managed to reduce the motor position time to 20 ms.
However we are not satesfied with this, we need around 10ms.
It seems that there are a limitation in the STPOSCTL as well.

Setting the speed to more than 3.2 krpm results in strange behaviour like loosing control of postion.
Something like over/underflow somewere in the calculations.

The base frequency is now set to 1200 Hz.

Can you comment on this?

Still I hope to use your profile generator.
But what we really want is a trapeziod start and a ST end.

Best Regards,
Ingemar

Ingemar,

I'm glad to hear you were able to get the motor position time down to 20ms.  

There is a limitation where STPOSCONV needs to get 3 samples per electrical revolution in order to correctly control the motor's position.  This presents an upper limit on the speed of the motor.  This translates to the following:

Assumption: STPOSCONV is ran with a 1ms sample time

1/(0.001 * 3) = 333.33333 electrical revolutions per sec

333.33333 * 60 = 20000 electrical revolutions per minute

You can convert this into mechanical revolutions per minute by dividing by pole pairs.

This is the upper limit in terms of speed.  If you need to resolve faster speed, you need to decrease the sample time of STPOSCONV.

Ingemar Dahlqvist said:

But what we really want is a trapeziod start and a ST end.

This really isn't possible with the current profile generator.  What you can do is use a different acceleration and deceleration so that the motor will decelerate slower than it accelerates.

Hi Adam,

I have some more questions that might be of general interest.

We have four motors in our design. Three of them are of type position where the motor can be allowed to move during alignment of the electrical angle.

The forth motor is not allowed to move at all. It is preloded with a torque.
I have seen different solutions to this problem on the community.

The best I think is the 5 Hall sensor type but I only know of one Swiss company that have this feature the Sonceboz a competitor to Maxon.
it is possible thet we can convince Maxon to add 2 more Hall sensors.

I am also aware of the high frequency injection which is very elegant but this only works with salient motor designs. The Maxon line is non-silient.

But we already have an encoder the RLS AM4096 that has two more features.
We can get the absolute rotor position by issuing a SPI request before enabling the system.
Or we can use the Sine/Cosine outputs feed to the 320F2069M A/D converter , this will work but we are concerned of possible EMi/EMC problems, and of course up to 4 extra lines (differential 2 channels) The SPI is needed anyway because if there is a power cut.

Can you comment on this ?

Best Regards,
Ingemar

Ingemar,

This is a common problem for many people.  We use this trick of moving the motor to force alignment in order to help speed up motor control evaluation, but it isn't going to be suitable for all applications.  

I think the approach of using the SPI interface to get an absolute position reading is the correct one.  You will need to modify the firmware so that instead of preloading the QEP block with a 0 position, you will need to preload it with the angle you get from your absolute encoder.  This should be pretty easy to setup.

Adam,

I have seen a figure of +-5 degrees electrical allowable offset in order to get the encoder to work correctly with FOC.
Where does this figuere come from ?
Isn't i t dependable on how many pole-pairs there is in the motor too ?

Best Regards,
Ingemar

Ingemar,

That figure isn't based on any hard data. It is based on empirical results. Not having good alignment tends to fail fairly quickly since the motor won't be able to supply as much torque as it possibly could.

I don't think there is a relationship between this allowable offset and pole pairs, since it will have an impact on each electrical cycle.