Mesa 7i43 + 7i39 firmware

kostas wrote:

andypugh wrote:

I'm testing with a free running hal configuration now, playing with the bldc comp frequency to see some action. Motor is turning smoothly but gets rather warm with a small current,

It will run hot in that mode, as it is being used as a low pole-count stepper motor.

To run it "properly" load the bldc component in "q" mode, then connect up the encoder and link the bldc "rawcounts" pin. Set the pole count parameter correctly in bldc, then you should be able to set the bldc "init" pin. That should cause the motor to rock the shaft back-and-forth and then you should find that setting the current makes the motor spin. Higher current, faster rotation. It should run very much cooler that way.

kostas wrote:

I tested this and does the job as advertised. How do I find the number of poles? increasing the bldc.0.value to 0.1 makes the shaft vibrate instead of rotate. I tested with different poles numbers (2,4,6,8) with no useful result. I'm powering the motor with a much lower voltage than 24V now, but this voltage is enough to rotate in free running, so I guess it's ok for the moment.

If you apply a very small current to the motor (in the mode you had earlier, and frequency set to zero) you can twist the shaft by hand and count. A 2-pole motor will be 1 detente per rev, 4 will be 2, 6 will be three. Count the detentes and double it. 2 pole motors are vanishingly rare.

A typical problem (50% of the time) is that the encoder and the motor run in different directions. make the bldc scale negative to fix that.

kostas wrote:

Runs smooth and silent now. I'l make a pid loop to test positioning tomorrow.

That's great. "bldc" is such a complicated component with so many combinations that I am always a little surprised when it works.
There was no way at all that I could test the full set of options with the hardware I have, so I am always aware that some features might need work.

I have tested encoder-only and 7i39 though, so that is something I expect to work, generally.

kostas wrote:

Is there any reason I should use the index for homing or am I ok with just the encoders?

Using index is better in some ways (ie, "qi" not "q" mode in the bldc config string) but you need to know where the index is relative to the motor phases.

q is the simplest mode, it will generally just work if the other, easy, stuff is correct. It isn't very good at aligning the motor under load. (It will generally not do very well in a heavy Z axis).
qi mode will rotate the motor in one direction until it sees the index. This is ideal if there is room to move the motor one full turn, and if you know where the index is (in encoder counts) from the motor "zero"
"bldc" considers the motor "zero" to be where the motor sits with the U phase at +volts, and V and W at -volts. This is often the index, so a 0 in bldc.N.encoder-offset is correct. But this relies on you having the encoder A and B wired the same way (2 options, 4 with differential encoders) and the motor phases the same as the manufacturer (3 options).

It is possible to measure the index position. It would even be possible for the bldc component to do it. I do have ideas for a "learn" mode where bldc is given a bare, unloaded, motor and tells you the pole count, encoder scale, offsets etc.

Maybe one day.