To Choice a kit for PMSM

[oleg_sidorovich_1981]

Help me choose a evaluation kit for control PMSM (FOC) with encoder for learning. I need used Motor control Workbench with motor profiler with examples. I need to change code by CubeID and CubeMx and build graphs (STM32CubeMonitor).

I want to buy EVALKIT-ROBOT-1 but I do not undestend how i can connected to PC, because that board (STSPIN32F0A) have not USB port and have not embedded ST-Link.

Help me.

[chaaalyy]

That´s exactly, how it should look like :) Thanks for the pic :) I think, this will help some people, struggling around, how to connect the stuff :) One more thing to mention: VM (36V) need to be present for the f0-mcu to start up. The STLink doesn´t provide VDD for it ! So 1st power up VM, then debug ;)

[chaaalyy]

In schematics you can see that STR485 chip and the TP´s 13 / 14 / 15, connected to PB7 / PB6 / PA 15... So if you remove the STR485, you should be able to connect the used uart pins directly. PB 7 and 6 are mapped to USART1 RX and TX, but can be reconfigured as I2C1 SDA and SCL also ;) I don´t know, if it would be a good idea to leave the STR485 on the pcb for that.

[Enrico Poli]

Let me try to answer to some of your critics about how ST promoted this kit.

The EVALKIT-ROBOT-1, as you figured out while you played with it, is not general purpose development tool. For this purpose ST offers more suitable boards including STLINK programmer, more testpoints and easier setup.

The main objective of the EVALKIT-ROBOT-1 is provide a proof of concept (not a final product for sure) of a compact positioning solution.

Moving to some more technical stuffs.

• You said "In original settings, @36V the whole system provides a maximum power of around 0.07 Amps. That leads to calculated (more or less) 2.52 watts." : is this result obtained with the original binary file or starting from the MCWB project included into the firmware package?
• "Check schematics (Fig. 4, Schematic board 2). R21 / R23 / R32 / R34 / R42 / R44 should have a value of 100R. Soldered on the back of the board you´ll find them with 1kOhm" . The value of the resistors is actually 100 ohm. The numbering on the case of the resistor could be misleading.
• "Same page: on top it says a calculated gain of 15, which should lead to a max. sensed current of 5.5 Amps" Gain reported in the schematic is definitely wrong. Actual gain is 10.5/2.4 = 4.375 with an expected reading range of +/- 3.5 A considering the 0.1 ohm shunt. I'll ask for correcting this.
• "without block commutation (and therefore it´s needed to use the included hall sensors. unfortunately they are even not configured in the pinout) it´s not possible to come even close to the rated performance of the motors (which is essential). But anyway: with block comm. , there´s so much torque ripple, that a smooth position control is problematic (if not impossible)". The board includes the possibility of using the Hall feedback too. From the hardware point of view there is no limitation. The actual FOC library (5.4.3) is not able to use Hall sensors for electrical angle reconstruction + encoder for positioning. The encoder is used for both electrical angle calculation and positioning.
• "Oh... and by the way: Maybe the onboard mcu should be labeled as SPINF0A. atm it´s SPINF0" Device is the STSPIN32F0A. Marking could be misleading because the "A" is positioned in bottom right area.
• "As far, as i figured out, what happens here (And that´s NOT my job !): The encoder delivers 4*1024 pulses (and that´s also the coded ARR of the according timer. So every revolution it comes to an overflow." I'll double check with the development team if this could be the root cause of the position drift you noticed. Another possibility is that it is related to the init interrupt issue you reported (see here)

As soon as your list of bug and notes about schematic is ready, please share it.

[Enrico Poli]

If your idea is to not come back to the RS485, I recommend to remove the STR485. Otherwise, you can force the DE/nRE signal high (PA15) disabling the receiver of the STR485. In this condition you should be free to use the PB6/PB7 pair as you prefer.

[chaaalyy]

Hi =)

1st: Nice to see, that at least, somebody cares about the problems. Thanks for that =)

Ok, you asked for the 0.07 amps ... This was the measurement, my power supply showed as max. consumption (@36V) , when using the original stsw-robot-1. Just one difference to original: I didn´t use the modbus communication. Therefore i coded some movement loops directly in main.c, just to get some "movement". I´m not sure, if this is a result of (at that time) not reachable higher speeds. The problem was: After 3-4 full revs of the motor, something was definitely wrong and it stopped. 1st, i thought (as written in my bugreport), obviously it´s an overflow problem of the encoder.But nope, it wasnt´... Then i suspected the PID system (which showed unexpected behaviour, but i couldn´t find the reason) After one whole night searching for the root of the problem (i´m not too experienced in re-engineering unknown libraries ;) ), i found the reported function, which is called every revolution of the motor, when the index of the encoder gets triggered.

The problem is not the irq (or the according isr) itself. It´s the fact, that also the counter of the timer, used for reading the encoder, is manipulated, while it should be tied to the encoder itself and nothing else. After i corrected that (inside that trajectory...-file), everything changed in a positive way. PID could do it´s job much better, no position drift anymore and so on. Of course, when PID does a good job, also the overall performance and behaviour of the motor is far better ...

Best way to handle that index (just an opinion...) would be, to disable the interrupt completely after aligning the motor and reenable it just, when needed. After my corrections, of course that isr is unnecessary because it does just nothing ;)

You mentioned: ...ST offers more suitable boards...". Ok, that´s a statement, but anyway: The bug in mcsdk 5.4.3 concerns every motor control, where bldc motors and incremental encoders are used. Not just the evalkit-robot-1.

That error unfortunately is a component of the mcsdk and therefore i think, it´s widely spread ....

Until now, i didn´t check the library, what happens, when i use the hall sensors, but obviously they´re not tied to an interrupt directly, as long, as the counting timer isn´t set up to trigger one after (pole_pairs * 6). As is said, i didn´t check that until now ...

As @Community member​ measured yesterday, the markings on the resistrors indeed mislead to wrong values.

As far, as i can say atm, the interrupt-bug is a "small cause", but a "very big impact". Feel free to send me some boards / motors / what else is needed and i would love to do more in depth testing ;) As you already mentioned: The robot-1-kit is a little bit limited for that purpose

Edit: As i stated in my bug report: after i corrected that isr, i left the motor running for more than one hour, just doing one full rev (360 degrees in 0.1 seconds, HAL_Delay(250)? afterwards) after the other. even after that time, it stopped reliable at the expected position (within +/- 3 "encoder-steps") ....

[AdamDonovan]

Enrico Poli wrote: Is this result obtained with the original binary file or starting from the MCWB project included into the firmware package?

I would expect that the provided source software is the same used to compile the binary, if its not can this be made available to the community please.

[Enrico Poli]

Sorry, I wasn't clear.

I confirm the code is the same. In particular is the output of the IAR project.

My question was more about the possibility that the code was a new one generated starting from the MCWB. Unfortunately, as described into the UM of the STSW-ROBOT, this procedure 1 is not straight forward.

[chaaalyy]

That´s really a good point =) At the beginning, i got a lot of trouble, importing and building the project. In this case i worked straight forward with st´s tools (cubeIDE 1.3 , cubeMX 5.6.1 integrated as well, as stand alone, MCWB...) As far, as i remember, i imported the project from stsw-robot-1, changed some include paths (mainly modbus stuff) and began to work with that. I never used the precompiled binary.... Also cubeMX was mainly used to get a better overview of the hardware settings. It´s possible, it regenerated the f0-code, when i migrated the project to the actual 5.6.1.

Edit: mcwb was used on a second copy of the project, because i didn´t want to get in trouble with missing paths / files and so on, when updating the code ;) So i have one copy to try settings within mcwb and one, i play around with. That way, i prepared these two files with the needed settings. Within mcwb, i opened the *.stmcx file, provided with stsw-robot-1 ...

[chaaalyy]

Unfortunately i´m in the same situation as ADono.1 ... I have to search for that usb -> rs485 adapter cable somewhere in two cubicmeters of electronic stuff xD So the question is: What is the quickest approach ? Switching on the soldering iron or searching for that cable...

But anyway: Thank you for the information about driving high the DE/nRE :) That´ll keep the path open to use also rs485 :)

For anybody, who´s looking for a usable modbus master software, this one isn´t too bad :) :

https://sourceforge.net/projects/qmodmaster/files/

[Enrico Poli]

Dears,

Just to inform you that we just released the new version of the STSW-ROBOT-1.

In this new release we solved the positioning issue (fix included into the rev 5.4.4 of the MCSDK). Thanks again to @Karl Hönemann​  for discovering this issue and for his contribution to the solution.

The new version also increase the maximum current level in order to better fit with motor characteristics.

Other fixes and improvements:

• new startup procedure that takes care of failures during encoder alignment phase
• fix of the "zero target time" bug