Issue with SimpleFOCShield v2: inverted current sensing pins

1

Continuing the discussion from Current sensing issue:

Code version 1

All this time, I though the correct way to initialize current sensing on the SimpleFOCShield v2 was this:

InlineCurrentSense current_sense = InlineCurrentSense(0.01, 50.0, A0, A2);
current_sense.gain_b *=-1;
current_sense.skip_align = true;

but then, as explained in the previous topic, some mode combinations wouldn’t work.

Code version 2

Out of curiosity I tried this:

InlineCurrentSense current_sense = InlineCurrentSense(0.01, 50.0, A0, A2);
current_sense.gain_b *=-1;
//current_sense.skip_align = true;

In that version, my setup doesn’t work either (same behavior as code version 1), but I get this message:

MOT: Align current sense.
MOT: Success: 2

As stated here, “2” means “success but pins reconfigured”.

Code version 3

So I inverted A0 and A2:

InlineCurrentSense current_sense = InlineCurrentSense(0.01, 50.0, A2, A0);
current_sense.gain_b *=-1;
//current_sense.skip_align = true;

In that version, everything seems to work perfectly. At last I can set aggressive current PIDs and all modes seem to work well!

Funny thing, the message is now:

MOT: Align current sense.
MOT: Success: 3

where “3” means “success but gains inverted”.

Code version 4

I tried this last modification:

InlineCurrentSense current_sense = InlineCurrentSense(0.01, 50.0, A2, A0);
//current_sense.gain_b *=-1;
//current_sense.skip_align = true;

and got:

MOT: Align current sense.
MOT: Success: 3

as if nothing as been changed, and current sensing still works perfectly.

Any idea what’s going on here?

2

I found another way to solve my problem: when I invert the angle measured by my magnetic sensor (I changed the code directly in the sensor driver), then everything looks fine without having to invert A0 and A2 as explained above.

However the output is now:

MOT: Align current sense.
MOT: Success: 4

meaning “success but pins reconfigured and gains inverted”.

I discovered this while playing with the find_pole_pairs_number example. Inverting the sensor readings seems to be the only way to make it compute the true PP number.

Any feeling on this? I’m a bit lost here :slight_smile:

3

Hey @quentin ,
A lot of great questions.

So in terms what does happen during the align of the current sensor, there are few important things there. The initFOC code is first trying to figure out which analog input (current phase measurement) belongs to which phase of the motor. To do that the code sets a phase voltage to the phase A to votlage_sebsor_align value and zero to the phases B and C. Then it measures the current and basically the A phase current has to be two times the value of the B and C phase currents. Then it does the same for the phase B and C (if third current sense available).

Furthermore, the code will calculate the sign of the currents that are measured and make sure that they are right. For example, when in the first step, when the voltage_sensor_align is set to the phase A and phase B and C voltages are set to 0. The current A has to be positive, and B and C have to be negative. And so on…

The returned status saying that the pins were changed means that in the first step it has been found that the current sense measurements are not aligned with he motor phases. The code will switch the analog pins automatically.
The status saying that the gain was changed means that in the second step, certain phases needed to be inverted.

There is one catch though, one that I am not sure if I documented properly.
When you have 2 phase current measurements, the pin exchange during the alignement will work only for phases A and B (only two phases)

I am not sure what is the case in your setup, but it might me something similar.

Now in terms of inverting the sensor measurements, this does not make sense really. The position sensor is aligned with the driver(motor) directly, the same is true for the the current sense. The current sense should be absolutely agnostic with regard to the sensor direction.
But if you’re having an issue die to this, maybe there is a case that we’ve forgotten. :confused:

The pp finding example is a bit out of date I think, because there is a check inside that that does not us the absolute values of traveled distance but the signed value and that’s why it failes. I’ll make sure to update this in the code :smiley:

2 Likes
4

Thanks for your detailed explanation @Antun_Skuric.

I’m ashamed to say that I cannot reproduce the issue anymore. The “code version 2” above didn’t use to work, but one minute later it did. Same for inverting the sensor measurements. I’m sure I didn’t change my code. Moreover, there couldn’t be any compilation awkwardness, because I’m working with 2 toolchains in parallel (Arduino and STM32CubeIDE) with the same code and behaviors were the same. I’m stunned.

Anyway, the conclusion to this topis is that, despite what’s implied several times in the documentation (such as here), this code doesn’t always work with the SimpleFOCShield v2:

InlineCurrentSense current_sense(0.01, 50.0, A0, A2);
current_sense.gain_b *=-1;
current_sense.skip_align = true;

In my case, the required code was (notice the two differences):

InlineCurrentSense current_sense(0.01, 50.0, A2, A0);
current_sense.gain_a *=-1;
current_sense.skip_align = true;

If you don’t want to bother finding the right settings, just don’t skip current sense alignment and let the lib compute everything:

InlineCurrentSense current_sense(0.01, 50.0, WHATEVER, WHATEVER);
//current_sense.gain_a *=-1;
//current_sense.skip_align = true;
1 Like
5

Hey @quentin
I’m happy to hear that you do not have the issue any more :smiley:

Yep this is true. But bqre in mind that in docs it says if you’re sure in your configuration then, you should skip the align. :smiley:
This basically means that not just the right gains need to be negated but also the right pin order needs to be set. Basically you need to be sure that you aligned your InlineCurrentSense and the BLDCDriver3PWM. Depending on how you define your BLDCDriver3PWM the InlineCurrentSense will change as well. This was the idea behind the automatic calibration + align in the initFOC. To avoid and detect similar errors :smiley:

1 Like
6

After all, maybe I’m not crazy: it seems @Alexander992 also needed A0 and A2 inversion even whith skip_align = false. See this topic: FOC Current Mode.