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