I have a small PMSM that I hooked up to the X-Nucleo-IHM16M1 board and a Nucleo-F303RE MCU board.
Btw.: Since, for me, with the MCSDK 6.x, nothing seemed like in the documentation or the youtube videos, nothing worked at all or gave any hints as to what's wrong, I have now installed the MCSDK 5.4.8 version, which actually allows me to select my boards & flash according control firmware on the MCU, profile the motor, and create a Motor Workbench project from that.
There are some hints already in the profiler, of something not being optimal, but my basic understanding of this technology is not enough to tell whether this could be a reason for the "sometimes works" problem:
The profiler notes that things are "optimized for" Rs > 1Ohm and Ls > 1mH. According to the datasheet, the former should be satisfied with the given 1.01Ohm, but the latter not, with only 0.32. But the profiled values are very off from that, giving 0.55Ohm and 0.09mH.
It's the 200188 here: https://www.maxongroup.com/medias/sys_master/root/8882562793502/EN-21-294.pdf
The winding's seem OK in so far as, connecting a star with three 100R resistors and looking at the voltages across the resistors with the oscilloscope (with nothing else than the resistors & scope connected to the motor for this test), I get 3 sine curves as expected (see image).
First, I was using BEMF-measurement for commutation, which would sometimes spin up the motor and let me alter the speed via the dial in Motor Workbench. But only every N tries & after maybe resetting the Nucleo board.
Changing the commutation to use the quadrature encoder that's also on the motor axis, subjectively made this work even less frequently, but I'm not sure.
The encoder output looks ok (see images).
I.e., most of the times I power the board, connect Motor Workbench, and hit "Start motor", it does not spin, or make any movement. Sometimes it starts to snap the motor into some alignment with a little remaining oscillation, then starts to spin (or not). There is a (well centered) "weight" on the axis, too.
Also I'd sometimes see the speed-meter in the WorkBench showing a "naturally fluctuating" needle at e.g. 2000 RPM, while the motor was, in fact, standing still.
Notable also is that I never saw the motor work with negative speed i.e. in reverse. So far, only moving it "forward" worked.
Edit: when I try to start everything new, with the motor speed set to moderate reverse speed, the MCWB shows it trying going from idle to unknown, then the speed needle going negative, but to 3000 instead of just the set 1000 on the dial, while the motor actually stands still but makes some slight noises. Then, MCWB will show over current (see MCWB screenshot)
The input voltage to the barrel connector on the IHM16M1 currently gets 10V and up to 3A from a linear lab power supply. (the nominal voltage of the used motor is 9V. In the profiling, the max current the slow ammeter of the supply showed was ~ 0.83A)
Btw, the workbench does not seem to have a pin assignment for the zero-ing pin of the encoder?
Does it have a display of the current encoder counter value somewhere? I didn't find it.
Does anyone have pointers as to how to diagnose why it only "sometimes works"?
The ultimate aim is to have a motor that can be set to do either of these: 1) rotate at a constant speed, 2) move to a certain angle & hold. The quadrature encoder shall be used for this.
Btw, I have not tried yet to use the CubeMx project that can be generated, all tests so far only were with the Motor Workbench and the firmware that the Profiler loads onto the Nucleo board.
(yellow is the phase-1 here, cyan is 2, purple is 3 - looks in order, not connected to the board while scope'ing this, but still on the detachable, green plastic block 3-pin connector of the IHM16m1 board.)
(encoder: forward, blue is CH1)
(encoder: backward, blue is CH1)
Hrm, profiled & tried with 4 very different motors now.
Negative direction never works at all, and positive direction sometimes works at first, and subsequent start of the motor only get it to turn a bit, to then stop (and maybe retry a few times - status goes back to unknown briefly), or sometimes with runaway speed...
Ah, and, if the motor runs seemingly nicely on 1st try after profiling again, it stops when going to low speeds. E.g. if a motor is rated for 3500 RPM under load, and I initially set it to 1500, then go down to 120 RPM on the Workbench dial, it tries to ramp down to that, but then the motor stops maybe at 150. That also happens with the 3 other motors (with different ratings)
Does this sound like my IHM16M1 board might be somewhat damaged somehow, or is this expected without actually hand-tuning parameters by a motor expert, and the profiling is only to get you in the ballpark?
I wonder whether it would make sense to buy one of the motors that the MC workbench already has profiles for, i.e. are known to work (though it depends on the particular power/driver board, I guess).
Just to get things working properly - unless the symptoms seen here really point to some HW problem that needs to be fixed.
It seems that either of the 2 - the IHM16M1 motor driver board, or the Nucleo-F303RE - have a defect.
I put together a 2nd stack of those boards, and have different behavior.
1. during profiling, at the highest speed (which still is <50% of datasheet max RPM), the IHM16M1 board at some point starts to abruptly pump back-EMF into my power supply, showing 35V or something (when running with 9V) and the thing sets some sort of electronical fuse & I have to power cycle.
2. when I limit profiling to a lower speed, at that speed, it draws ~1.2A instead of ~0.8x before, which is roughly the difference of 1 phase not being there, but all3 PWMs are visible on the U,V,W, so need to check more detail later.
3. reverse spinning of the motor works with this 2nd dev board stack, which it hasn't with 4 different motors before. So that was definitely an odd thing, hinting at a HW defect.
In Workbench, I am getting overcurrent error when fiddling with the speed dial, esp. from faster to slower speed, perhaps also due to some back-EMF thing. But it's much less likely, even for larger intervals, if I enter numbers for speeds, e.g. 3500 to 500 (as opposed to turning the dial).
So, while there are undesirable, but explainable, effects observed - this seems to be a lot closer to working now, so definitely the 1st pair of boards I was using must have >=1 defect.
Btw, is there no register for the running quadrature encoder position? (I don't see any in the Workbench tab of polled registers)