Hi,
I'm re-initializing the hall sensor table for a motor. I got 99-161-126-26-59-199. Now these are supposed to be evenly distributed on 0-200. Would it make sense to improve the running of the motor a little by by taking a 0-33-67-100-133-167 and rotating it (adding a 0-32 constant to all of them) until it matches the measured numbers as closely as possible? I have done that and set the hall table to 28-62-95-128-162-195 now (in the correct order).
What would happen if I had a running motor (at hall-sensor speed) and I dynamically changed the hall table, e.g. from a terminal command. I can imagine that with the numbers being not quite ideal, you could correct for say the magnet-hall positions a bit. However my motor has 18 pole pairs. And the detection only runs across about 2 ERPM, so 4/6 pole sets remain unmeasured.... Can we optimize the table dynamically?
Something like
if (argc > 1) offset = atoi (argv[1]);
if(saved_hall_table = 0)
saved_hall_table = get_hall_table (); // don't know how to do that. yet.
for (i=1;i<7;i++)
new_hall_table[i] = saved_hall_table[i] + offset;
set_hall_table (new_hall_table ());
in terminal.c ....
The hall sensor values are not in order as they don't count up like a binary counter, but I understand what your point is. You want to enforce even spacing between the values and choose a table that matches as well as possible. I haven't tested that, but I don't think it will make much difference, and it might even get worse. The measured unevenness is likely to be cause by mechanical placement as well, and in that case the detection takes that into account. You can test that by varying the detection current and see if the values and distribution change much. A higher detection current is likely to give more accurate results. Also note that the direction turns the motor in both directions and takes the average to compensate for possible lag from friction.
If it actually helps to even out the spacing, I would probably add that functionality in VESC Tool - it should be quite straight forward.
My motor requires something like 1.3Nm to turn. More like 2Nm yesterday. And there is a part in the rotation that something touches, so this friction is quite uneven across the 6 electric rotations across a single rotation of the motor. So when I run the detection ad 10 or 15A (6-10Nm) the motor does not gently move as the field is slowly turned. The motor jumps to a new position and the wobbles a while before jumping again. I try to dampen the wobble to get more consistent measurements. So I have the impression that some assumptions used in writing the hall sensor detection are not valid for my motor. A lot of cogging you say? No. No cogging. None.
If the sensors are not precisely positioned but the magnets are, then you are right: Two of the 6 transitions would happen at an odd angle compared to the other four. But I would hazard that the magnets might be unevenly spaced as well. My guess is that this is more common than bad placement of the hall sensors.
With that in mind... you might be right: 99-161-126-26-59-199. has 99-199, 26-126 and 60-160 Only off-by-one for the last pair. I'm not convinced that the measured offset of one of the sensors (its the 99-199 one) is due to a magnet placement or due to the hall sensor placement.
Hello.
Can anyone explain the Hall table?
I can not understand it.
The HALL sensors provide an indication as to where in the electrical revolution the rotor is. You get enough information to run the motor in BLDC mode depending on the HALL signal values. In BLDC mode there are six phases and the hall sensors conspire to make exactly six combinations.
When driving the motor in FOC mode, the position of the rotor during an electrical revolution is thought of as a position on a compass: say 0-360 degrees. Now the three hall signals combine to make a 3-bit number 0-7. So now for each possible combination you note the average compass value when that value is output by the hall sensors. So if during 0-60 the combination 001 or "1" shows on the hall sensors, you put the average "30" in the table at position 1. Now 60-120 teh hall sensors show 011, so you put the average 90 in position 3 in the table.
Now Benjamin decided to save a few bits by instead of counting the revolution in human-convention-units of a degree (i.e. 0-360), he decided to use units of 1.8 degrees. So now that first table-entry does not show "30 degrees" but "17 units-of-1.8 degrees". Except for a bit of rounding this is exactly the same. Close enough for our purpose.
Now, there are several things that make this table more regular than random. For example, when you move the rotor half an electrical revolution, all the hall signals will change value. The value will be the ones-complement of what it was before. In three bits the ones complement of x is "7-x". And an electrical revolution is 200, so half a revolution is 100. So table entries 1-6 should differ by 100. Is this difference not precisely 100, that points towards manufacturing tolerances in your motor. But in general it will be pretty close.
Thank you so much Roger