The stepper motor does not work in a closed cycle

I have mt6835. But I don’t know how many times I can program it. I’ll leave it for the final attempt to start the stepper motor.

The magnet is correct. But I don’t know exactly how magnetized it is. In any case, it is very difficult to find a perfectly magnetized magnet in the center. My opinion is that every time, after replacing the magnet, or after the first assembly, there should be a stage of calibration of linearity. Otherwise, it makes no sense.

Oh, ok… Is it a One Time Programmable MEM @runger ? You seem to have some kind of strong attachment to the MT6701, Just let that go completely and move on to the calibration.

Yes. From a good vendor you can get different quality grades, reflecting how perfectly diametrically magnetised the magnet is.

If you have a “magnet viewing screen” you can take a look at it, and can detect bad asymmetries even visually. And you can see immediately if the magnet is axial or diametric.

But normally the diametrical magnets you get with the sensors all work fine. It’s only when dubious sellers supply you an axial magnet that there are problems.
Once the magnet is the right type, the problems are usually more to do with field strength (due to size of magnet or air-gap distance to the sensor), or the electrical connection to the sensor.

So its mysterious what is going on here…

Things to try include:

  • use the SSI mode of the sensor rather than the ABZ mode, and see if this helps anything
  • use a hardware ABZ driver (we have one for STM32 MCUs, and you can find code for ESP32 and RPi to sue with our GenericSensor class quite easily). This would prevent missed interrupts as a source of problems

I haven’t read the thread I detail, but it sounds like you are having issues due to the electrical angle offset doing the rotation, since the encoder isn’t linear.

I made a test program that estimates the offset for 50 points doing the rotation and uses a look up table when running.

The offset might change as much as 180 degree in our case - transforming the foc stepper concept from useless to awesome.

There should be a few other posts about it on the forum

Hello. I’ve seen those records. Under one of them, I asked about the possibility of calibrating the encoder in abz mode, but did not receive an answer.

I don’t see why not… the code is intended to compensate non-linearity caused by misaligned magnets of magnetic sensors. I think it should not matter what type of interface is used to get the sensor data.

1 Like

Hi guys. Today I ran a test using the A4988 driver. I took 200 steps in parallel to output the encoder values. My theory about the nonlinearity of the sensor was not confirmed. It has a +/-1 error. But this is most likely due to the 1024 steps of the encoder per revolution. Since the stepper motor has 200 steps, it turns out 1024/200 = 5.12. From here in some steps the difference is 5 in the other 6.



In the table, the last point is 202, this is because I did not write the code correctly, and the microcontroller took the steps before enabling the driver :slight_smile:

@runger I did another test today. Now I’m confused, because it turns out that the encoder has 1019 steps per revolution??

1 0
2 5
3 11
4 16
5 21
6 27
7 32
8 37
9 43
10 48
11 53
12 58
13 63
14 68
15 73
16 78
17 83
18 88
19 93
20 98
21 103
22 108
23 113
24 118
25 122
26 127
27 132
28 137
29 142
30 147
31 152
32 157
33 162
34 167
35 172
36 177
37 182
38 187
39 192
40 198
41 203
42 208
43 213
44 219
45 224
46 229
47 235
48 240
49 246
50 251
51 256
52 262
53 267
54 272
55 278
56 283
57 289
58 294
59 299
60 304
61 310
62 315
63 320
64 325
65 330
66 335
67 340
68 345
69 350
70 355
71 360
72 365
73 370
74 374
75 379
76 384
77 389
78 394
79 399
80 404
81 409
82 414
83 419
84 424
85 429
86 434
87 439
88 444
89 449
90 454
91 460
92 465
93 470
94 476
95 481
96 486
97 492
98 497
99 503
100 508
101 513
102 519
103 524
104 530
105 535
106 540
107 545
108 551
109 556
110 561
111 566
112 571
113 577
114 581
115 587
116 592
117 597
118 601
119 606
120 611
121 616
122 621
123 626
124 631
125 636
126 640
127 645
128 650
129 655
130 660
131 665
132 670
133 675
134 679
135 685
136 690
137 695
138 700
139 705
140 710
141 715
142 720
143 726
144 731
145 736
146 742
147 747
148 752
149 758
150 763
151 768
152 774
153 779
154 784
155 790
156 795
157 800
158 806
159 811
160 816
161 821
162 826
163 831
164 836
165 842
166 846
167 851
168 856
169 861
170 866
171 871
172 876
173 881
174 886
175 891
176 895
177 900
178 905
179 910
180 915
181 920
182 925
183 930
184 935
185 940
186 945
187 950
188 955
189 960
190 965
191 971
192 976
193 981
194 986
195 992
196 997
197 1002
198 1008
199 1013
200 1019
201 1024

I will try to use mt6835, it is set to 3000 steps per turn. I do not want to calibrate it, since initially I planned to use in my project a nema 34 with a force of 12 N. m. But if nothing happens with nema 17, then there is nothing to spend money to buy a nema 34))))




Ha! This works without calibrations. The first time. Apparently the library does not work very well with encoders, which have not multiples of the ratios of steps to the magnetic poles. Or the MT6701 sensors are not very accurate.
I like mt6835. It is a pity that because of the new rules ali express no longer delivers goods to Austria. And I can’t order anything else there. Including encoders:(

2 Likes

It should be calibrated from MagnTek. The auto calibration can fix misalignment issues I think. Good to see some real progress!

Yes. But mt6701 must also be calibrated MagnTek

I’m really glad to hear it is finally working :slight_smile:

Are you using the driver code from the drivers library, or your own driver?

I have to think about this, but it really should not be the case. The encoder still has a fixed number of counts per revolution, it doesn’t depend on the number of motor turns. So the “zero point” should always be in the same location on the motor shaft. The electrical zero may be “between” two encoder counts, but the error (ignoring latency) should not be more than resolution/2 .

I think it more likely that is is an issue of control - resolution/latency vs the high pole count/accuracy required that leads to unstable control. Or that encoder ticks get missed - that would lead to position drift without the Z signal to correct it.

:angry: Yeah man, I hope they fix this soon…

But cool to meet a SimpleFOC user in Austria! I’m in Vienna, where are you based?

It’s unbelievable. I am also in Vienna :smiley:

I use everything from the SimpleFoc library :slight_smile:

I had a similar problem with the engine from the gyro scooter. I also used mt6701 in it and it didn’t work either. I will try to use mt6835 now. I hope it will be successful

1 Like

Very cool! Perhaps we can get a chance to meet up at some point.

It’s been working ok for me, in its SSI mode. I have still to test the ABZ and I2C modes… I just don’t get enough time :slight_smile:

I tested our driver for it out today, and fixed some more bugs. It is working well for me now in SPI mode for reading the angles. I’ve committed the changes to the dev branch of our drivers library.
I have not yet tested setting options or doing the calibration… I assume you’re using the ABZ mode?

Wir müssen uns unbedingt mal treffen :).
Yes, I use abz mode. Other modes do not suit me, because initially my goal is to build a steering wheel for the simulator of games))))). I receive the control signal from the stm32 board with emc firmware, and it, in turn, works only with encoders in abz mode. So I connected one encoder to two handkerchiefs in parallel. It works, but the hoverboard motor heats up, and has a deformation of the body)))))) because of which I had to shift the electric angle for each direction of rotation. Having weakened the Magnetic Field, the motor does not heat up so much. It is better of course to organize all this on one mk, but my knowledge is too small for this :slight_smile:

Hi. I tried to connect mt6701 via the SSI line and get strange readings. When the rotor turns, the values go from 3.14 to 6.28. Then it resets again to 3.14 and so on in a circle.
000

Hey, thanks for reporting it!

Not sure what is happening, because there was some similar reports before, I think it is maybe MCU dependent.

Was this the dev branch code or the official library?

Actually the dev branch and master are the same for this code.

On August 19th I committed a fix for a similar problem which affected RP2040 MCUs… which MCU are you using?