Sensored control - strange behaviour

Maybe, you need to do the calibration for encoder fisrt to get the correct rotor position.

Isn't the calibration being done each time I start the lab code, by re-estimating Rs? That's what it says in the instaspin_labs.pdf : "This project will setup the calibrated angle of the encoder. This ensures that both the encoder and the motor are aligned on a zero degree electrical angle. This step is done when the FAST™ estimator is recalibrating the Rs value of the motor."

I think you are mechanically torqueing the rotor so it is out of position with the initial alignment.

in my motors construction (Tiger U10 KV80) it is actually not possible (I mean slippage of the rotor). The encoder is mounted directly on the rotor. I am putting a load only on the rotor and not the encoder (so there is no slippage between them).

hmmmm. I've asked Adam from LineStream to comment as he supports the sensored labs.

Have you estimated the motor inertia using lab 12a?

Have you tuned the position controller bandwidth?

It is possible that the encoder module is losing counts due to the (presumed) very rapid rotation when the torque is released.  You could look at some of the posts on the forum about how to change the GPIO qualification settings which would allow the encoder module to capture higher speed pulses.

Instead of turning off the Flag_enableSys, try turning off Flag_Run_Identify.

I wasn't able to download the spec sheet for your encoder.  It would also be worth ensuring that your encoder module isn't causing these issues.  Since it is hall angle based it won't have the same level of performance as an optical encoder.

Yes, I did estimate the inertia, both with lab 05c and 12a, the inertia came out practically the same on both, the friction was a bit higher when using the encoder.
Yes, I did tune the bandwidth, although there is no difference if I use the precalculated one, or the tuned one.

The encoder missing pulses is the thing that I was suspecting to be the culprit, but didn't want to mention it beforehand. But still doing a Flag_enableSys =0 and Flag_Run_Identify=0 and then setting them both to 1, still has the motor screeching.

the documentation for the encoder eval kit I'm using can be downloaded here:
eval kit: ams.com/.../1085449
encoder chip: ams.com/.../34237

I would suggest that you try lab 13b and test fast profiles to see if you can replicate the behavior by using very quick ramps. This would help prove that the encoder module missing counts is the culprit.

Ok, so I tried lab 13b with an untuned controller, and nothing happened when I didn't torque the motor, but just let it spin. When I torqued it, the same thing happened, it started screeching and lost all torque.

I then tried it with a tuned controller and to my surprise no torque or rattling or overshooting was possible to cause the strange behaviour. I then tried to use the same settings on Lab 13a, and again no strange behaviour. I can understand why a tuned controller doesn't do this because it is responsible for the stability of the system, the thing I'm wondering is why an untuned controller would cause the behaviour I described.

Grzegorz Ficht50 said:

I then tried it with a tuned controller and to my surprise no torque or rattling or overshooting was possible to cause the strange behaviour.

This is the key.  In order for any controller to work properly, it must be tuned.  The SpinTAC controller will be stable across a wide operating range but that doesn't mean it will have the ideal performance across that range.  I would argue that the controller was stable and working correctly, but your issue was related to the encoder.  

The way you describe the controller behavior, it was very underdamped and would have settled.  This is still stable.  It is however not the ideal system response.  That is why you need to tune to get the ideal response out of your controller.