Associate III

Question

To Choice a kit for PMSM

Forum|Forum|6 years ago
April 3, 2020
11 replies
3622 views

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.

This topic has been closed for replies.

Cristiana SCARAMEL

Technical Moderator

The EVALKIT-ROBOT-1 has a dual row 10 pins header with 1.27mm pitch spacing for programming/debugging (J12).

You can use the ST-LINK/V3 that have this connector type.

"If you feel a post has answered your question, please click ""Accept as Solution"""

AdamDonovan

Associate

It would be great of more of a walk through/documentation with setting these headers to the stlink v3 /including photos as its not included in the manual

as it stands its not working so well for positioning out of the box and Id like to start getting into programming/debugging.

chaaalyy

Senior II

Sorry that i have to say that, but this is definitely a "Buy something"-TRAP !!!

The STEVAL-ROBOT-1 indeed has the connector and also the cables are included with the STLINK-V3... It also can be programmed / debugged in this combination, BUT: You wrote, you want to use the motor profiler in MC workbench. THIS is definitely NOT working ! And to be honest: besides many bugs in the provided STSW-ROBOT-1 (if you can get it to be built...) the hardware doesn´t even come close to the promoted performance. The designers just miscalculated many values, it seems, they copied just the bullrunning motor from one of the nucleo kits (as they did for the board... they just copied the steval-3201 for that) . 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. Of course the motor turns that way, but you will be able to stop it by hand... Not, what you would expect from a promoted "ready to run" solution with a 100W motor. This kit is just a waste of money. At the moment i prepare a list of major errors in setup, schematics and usability (and this is a LONG and reproducable list)...

I´m just curious, what Maxon and Würth will say, if i forward that to them. I believe, they are not amused, when they get in danger of feedback like "hey, what crap of motor do you sell ?" or "you really endanger your good name for something like that ?".

Just one small example: 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 ... Same page: on top it says a calculated gain of 15, which should lead to a max. sensed current of 5.5 Amps... Try to set this in MC_workbench... You´ll find yourself stuck at a max. of 1.1 Amps ... Also the motor itself in the workbench: Originally rated with 2.72A rms, it´s crippled at 1.7A peak (which is even impossible to reach with the given setup...) And so on, and so on ...

Now the sad part: ST seems to have it necessary to lie at the customers about "how good they are". In reality, they have to show with that kit, how they can perform with sensorless foc. Meanwhile, i believe, the problem is just: 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).

Oh... and by the way: Maybe the onboard mcu should be labeled as SPINF0A. atm it´s SPINF0 (Or is it a F0 and just the documents are wrong here?) What should we expect, if even simple resistors are wrong.

Oh... another major bug: try to make a movement of 3 revs in position mode. More is unfortunately impossible without tricks. somerwher between 1180 and 1200 degrees as target position, it begins to turn in the opposite direction to a "not expected" end position...

But anyway: take the example, in mainloop, comment out the comm-stuff and let it run: 1180 degrees target position, when movement finished: 0 degrees target position and so on... after a couple of minutes, you´ll recognice that the REAL position differs from what should be zero (we talk about absolute positions, not incremental !) ... 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. Shouldn´t be a problem, if handled correctly... But nope, the developers aren´t even able to do simple math correctly :( When moving just below 360 degrees, everything is fine...

Enrico Poli

ST Employee

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.

chaaalyy

Senior II

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") ....

oleg_sidorovich_1981Author

Associate III

thank you!!!

chaaalyy

Senior II

good morning :)

meanwhile i have an update for the behaviour of that robot-1-kit:

https://community.st.com/s/question/0D73W000000Piga/bugreport-mcsdk-543-and-temporary-fix?s1oid=00Db0000000YtG6&s1nid=0DB0X000000DYbd&emkind=chatterCommentNotification&s1uid=0050X0000089sTU&emtm=1588455523620&fromEmail=1&s1ext=0

with the changes, i made (just a temporary fix...), it should be possible to get useful results.

AdamDonovan

Associate

Hmm, I must say I got this Kit because I thought it would be a good solution to get up and running quick.......im kinda dreading it now. Im not liking the almost non existing documentation. I've not used the stlink v3 or st products before and I am at a loss to even get started..which cable where. Im glad that at least there is some fixes Chaalyy and I really look forward to getting something usable. I've got a fairly decent little lab here for SMD work and perhaps Ill post some images of those resistor changes if it helps anyone.

chaaalyy

Senior II

I have the STLINK-V3SET in use and it´s fairly easy to connect. On the back of the debugger, you´ll find a 10x2 pin header, on the pcb of the STEVAL-ROBOT-1, you´ll find the same header. So just connect the (with the debugger) included flat cable at both ends, plug in a micro usb cable into the debugger and you´re up and running...

The resistors i mentioned in the post above: I did not measure them (fairly useless, while mounted and connected to something else ;) )... I just read the value "1000" on them and according to the specifications of 4-digit values on smd resistors, it should be a 1k resistor then. (while 3 digits "100" would be 0.1 ohms)

Also connecting the motor is easy: Plugs are already mounted and just need to be plugged in =) The only cables, you´ll have to connect, are GND and VM (36V, 120W) from a power supply ...

Edit: I try to find the link for a basic documentation... Just a moment please ;)

chaaalyy

Senior II

Found it :)

https://www.st.com/resource/en/user_manual/dm00665765-getting-started-with-the-evalkitrobot1-stmicroelectronics.pdf

there you´ll find basically everything, you need for a quick start. Check chapter 4.3.x ... The "command set" via modbus is very limited. Unfortunately, the comm connector isn´t connected directly to the f0-mcu. So you HAVE to use RS485. Of course you can delete all the modbus stuff and develop your own comm interface to use all the possibilities of the mc library.

I for myself did all the tests with calling the according functions directly in main loop (and without comm....)

AdamDonovan

Associate

Thanks Chaaalyy! Here is a photo of the programming cable hooked up in case it wasn't clear for anyone else. I did measure out those resistors and they all seem 100 ohm to me so should be ok. (the comm connector isn´t connected directly to the f0-mcu.)--geez. I would have thought to go with I2c not modbus but thats later/at the moment I dont even have a usb to rs485 so in the main loop I will probably also fiddle around there. Anyway I only got it today so tomorrow should be fun...I hope

chaaalyy

Senior II

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

Senior II

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

ST Employee

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

Senior II

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

ST Employee

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

Enrico Poli

ST Employee

By the way, now the schematic is correct ;)

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded