Hey guys,
first of all I am sorry that I unlocked my account on a way that was not intended to use, but now I am here so I should use this forum also to share my observations on VESC Tool. So I used my chance to download the VESC Tool (V0.76) and flashed the new firmware (V3.24) to my second VESC 4.12 (which has the filters of the hall port removed). First of all I must say that the new VESC Tool looks amazing and it should be a lot easier for new users to set up the VESC with the wizards. Great work Benjamin. It was a piece of cake to get my motor running in FOC mode.
After everything was set up correctly I played around with the different modes and made my first observation with the keyboard control of the motor.
When using the right and left keys the motor spins up in duct cycle control. When releasing the keys there is a strange current oscillating which is also seen with the FOC Q and D vectors.
When using the up and down keys the motor spins up in current control and after releasing the keys the motor turn off and no current is floating in the non turning motor. So the way it should be.
You can see the realtime data screenshots in the pictures I have uploaded here.
https://www.dropbox.com/sh/vcnew8b3d9xrr6i/AAA4rZLbeobfkbmxsr-ugGUBa?dl=0
I hope I explained it good enough for understanding it.
I then realized, that after releasing the up/down key the motor behaves like I pushed the „Switch Off“ button and after releasing the right/left keys like pushing the „Full Brake“ button. So every time I pushed the „Full Brake“ button the strange current occurs. My second test was to rotate the motor by hand after I pushed the „Full Brake“ button. As you can see in the uploaded screenshots I got a oscillating current and erpm readout, so definitely some strange things going on there. Maybe this is a useful finding.
The next thing I noticed was the motor temperature which says something like -80 degrees celsius with nothing connected to the temp pin (so with the floating stm pin a strange reading is expected), but I also got a strange reading of around 90 degrees celsius connecting the temp sensor from my MXUS 3000 motor. I used a hair dryer to heat up the motor, but there was no change in the realtime data of the motor temperature visible. The specs say it has a KTY83/110 temp sensor in it, so maybe the current firmware is not build for that type of sensor. But would be cool if common sensors are supported in the future. So right now the motor will not spin with the temp pin connected to the regarding VESC port because of the 90 degree value that is limiting the current because of the motor temp limit.
The maybe most important thing I noticed was the behavior connecting a BT 4.0 module to the UART port and use the metr.at logging app to see if some data could be read. I thought it just couldn’t connect and doesn’t read any data because of a different serial protocol, but it was much worse. Connecting the app to the VESC just fried the STM32. No LEDs were blinking after a reboot and the VESC wasn’t found any longer over USB. Tried different things, but just flashing an old VESC firmware over JTAG with an STLink V2 revives the VESC. Looks like nothing is damaged permanently, but not everyone is able to flash a new firmware over JTAG and I am not 100% sure if really nothing of the hardware was damaged by this. But amazing that it is so easy to brick the STM just with a few UART commands. Wasn't expecting that.
SO TO ALL BETAs. DONT USE ANY OLD SMARTPHONE APP TO CONNECT TO YOUR VESC OVER BLUETOOTH, WHEN YOU DONT WANT TO RISK TO BRICK YOUR NEW VESC 6.
I have only tested with the metr.at app and investigate with Roman (the developer of the app) the following. It looks like command codes for COMM_GET_MCCONF and COMM_GET_APPCONF are 0E and 11 in FW3.24, when in the old FW2.18 the codes are 0D and 10. So instead of sending COMM_GET_MCCONF in metr.at app, I was probably most likely sending COMM_SET_MCCONF. Because of this my VESC was bricked afterwards. We fixed that behavior and also analyzed the serial data so data logging for FW3.24 should work in future versions of the app. But the best way would be getting the source code of VESC Tool and the firmware so we can confirm that and also compile the GUI for Mac.
I hope I am allowed to post my findings here in that thread in the BETA forum. When not, please remove this post or move it to a hidden area. Thanks so much Benjamin for everything you did with VESC Tool, VESC 6, this new website etc. and also Trampa for helping getting the VESC 6 out.
Best regards
Thanks for the feedback!
The motor temperature will show a large negative value with nothing connected since the pin will be pulled up by the voltage divider. This essentially results in not using any temperature limit when not using the pin, and no extra configuration is required. If you want to connect a temp sensor it has to be a 10k NTC resistor, which might not be the default on all motors. Your sensor seems to be a 1k PTC resistor, which will invert the temperature compared to what the software expects. Since it is 1k it will be way off in the reading as well. It would be possible to support more temperature sensors in the future in software, but for now only 10k NTC works. It is probably quite easy to change your sensor to a 10k NTC resistor.
Regarding the currents, that is normal. There is a bit of offset in the current measurement, and the oscillation comes when the observer tracks noise and rotates slowly from tracking the noise. When the motor is undriven the currents are assumed to be 0. If full brake is used and you move the motor, the observer will start tracking, but the current controller does not try to do anything which results in the kind of undefined "errors" you see in the FOC plot. That is also normal.
For now I don't recommend using any old app or device with the new firmware since the communication protocol has changed quite a bit. Also, I don't really like the model of making closed source apps that communicate with the VESC, so I would like to get support for mobile devices into the code base of VESC Tool as soon as possible. There are already preparations for that by separating the communication and configuration code from the user interface. If anyone wants to get involved with that I will do what I can to help, but currently I don't want to spend any time on supporting the development of closed apps.
Thanks for the response.
That explains it why the reading was wrong. I would love to see other temp sensors like PTCs supported in the near future. I think a lot of motors use other sensors than 10k NTCs. And with the higher current capability of the new VESC 6 the motors will get hot a lot faster. Would be nice when it would be possible to not destroy the motor involuntary with destroying the magnets with heat. With the build in hub motor in my eBike it isn't that easy to change the sensor type. It is a lot of work to remove the motor from the bike and open the motor. It is a lot easier to add/change the temp sensor on skateboard motors.
Good to hear that it is normal. I haven't seen that in BLDC Tool because I haven't tested. I was thinking the erpm oscillation couldn't be right.
I can understand that you don't want to support closed apps, while the whole VESC project is open source. But the metr app is the only useful app I found that works both for Android and iOS.
Thanks Hexacopter and Root! I have several VESC 4.xx, but from the notifications from Frank i thought the VESC Tool would not work with them for another week or so (as in a few weeks in reality - know how busy you all are). I don't want to kill a VESC 4, but would love to use the new VESC Tool and only have the VESC 4's currently (until my Six arrives).
Also curious on the Metr.at app and BT option. I understand not wanting to support a closed source solution that piggybacks on Ben's OS work, but it's the most polished and functional option i was able to find. Frequent improvements and quick feedback from Roman... Seemed worth it compared to the other solutions that were vaporware or slow...
Thanks All!
You haven't understand frank wrong. The VESC Tool which is available today supports just the VESC 6 hardware. You can see that when you go to the firmware tab. You will only see 6 as an option. So you cant use this VESC Tool version for VESC 4.XX hardware right now. You need to wait for the new VESC Tool version that comes in a week. (franks information)
I helped Roman instantly to fix that problem. I think with the current metr.at versions you can not brick anything. But you can also wait for my test with the VESC 6 hardware and FW 3.25 first, so you know if it works. I will test as soon as I receive the VESC 6.4 hardware.
When everything works, the warning: "going to spin up the motor" is useful. But I have now clicked "yes, I know its going to spin up the motor" ten times..... Also the "detection failed, click OK" becomes annoying after a while.
As you may have guessed, my motor does not detect without problems. The motor jerks back and forth, but usually does not spin.
I have managed to get it to start to spin, but then the detection stops (fails) before it stabilizes. I've since then increased the current ("spins but doesn't reach target speed"), and now it no longer spins.
When the motor cogs I get to increase or decrease the current. The motor may cog worth of 2A of current. but at 2A it should be able to reach max RPM. At least that's what I've been doing before with other hardware.
This motor probably DOES have "high Inertia". How low can I go with ERPM? On 2A near 100% dutycycle it should be able to run 2100 ERPM.
Can the detection use Sensors? I'm going to try to hook up the sensors now.
The HELP cannot be kept open as a "help" while adjusting the parameters. You have to decide what to do, close the help, do what you intended, and then for furhter tips reopen the help and scroll to where you left off.
I can't get the VESC to detect the linkage "lambda". I've measured it before, and it was 0.011. The current version does not allow me to enter that value and try to run the motor.
Ok. I can enter the lambda at the top, but this means that the tool does not calculate the other parameters for me. With Lambda set to 0.011 the motor continues to turn for a few seconds if I give it a shove (in the wrong! direction).
Firmware: The terminal foc_openloop command doesn't seem to work.
None of the detections work for my motor. BLDC mode is able to start my motor if I instruct a low current 1-2A, and then give it a shove. Then the motor starts to spin and will spool up to the voltage limit. With 6 pole-pairs and 15.6KV that means 860 RPM at 55V (5160ERPM). I can then increase the current and load the motor a bit.
The tests I have done with the early VESC Tool on the VESC 4.XX hardware I also need a lot of trys to detect the FOC parameters of my MXUS 3000W motor. With the rim and the tire the motor has a quite high inertia, but I don't remember what exact settings worked at the end. I know that I had to lower the ERPM and use a slight higher current than the default 5A. And when I remember it correctly it wasn't able to detect with my 3s pack. I need the full 11s for the detection. But don't know if it works the same with the new VESC 6 hardware because I haven't received it yet.
I think the sensors can not be used for the FOC detection. They are detected after the general FOC detection I think, because the motor needs to spin up when I remember correct. but maybe Benjamin can tell you more about that.
I also think it would be quite useful if the help screen could stay open while adjusting the settings.
The sensors-detection for FOC mode seems to work like: commutate to next BLDC state, wait 1 second and commutate again. i.e. it is practically static, and as long as the configured current is high enough to move the motor, it will always work. This is good. :-)
The thing is: it looks as if the detected numbers in the table are the positions in 2-degrees in the E-rotation. In that case, I don't understand how you can detect it if you don't use the intertia of the motor to smooth out the rotation.
If you perform something like a FOC_OPENLOOP, then you can accurately guess where the edges are....
VESC Tool 0.79 is building now where the help dialogs can stay open while adjusting settings. FW 3.26 with two bug fixes (one of which is important when using RPM limits) is also included.
The flux linkage measurement has always been difficult. What I have done so far is making sure that it works with all the motors I have at home. The only ebike hub motors I have are two slightly different 1000W motors that I don't remember the brand of, but they work with the latest detection.
It would be possible to use the hall sensors as detection aid, but it requires a bit of work in the code and wizards. The best thing would be to not rely on hall sensors since not all motors have them.
Have you noticed if the detection makes a number different tries, or does it only try to start the motor once and give up?
This motor is like an e-bike motor in that it has more inertia than what you're used to. But it's not an e-bike. It is nominally 10kW, about 60A at 150V. Now I won't be able to drive it that fast with the VESC, but the 60-80A that the VESC does match fine with the motor's specs.
Yes, there are several tries to get the motor running. I'm pretty sure it is "3 or 4 times", I can't confirm the "4 times" yet.
Moving the motor is a hassle (it can be dragged for a meter by one person, but beyond that it requires two people to move), would it be useful for you to have access to the Linux machine controlling it? I can power the VESC from a lab powersupply (Switchable between 20A, 30V or 10A, 60V). My office has 24 milisecond ping times to sweden. And I think 100mbps bandwidth in the weekends.