I never thought of it that way - but I guess the brake current in the balance app means that technically the motor is running. When I first started playing with firmware changes my son once stepped on my board and rode away in the middle of a firmware update.... Agreed - hitting that upload button should stop the motor or switch the app to something safe
Tested the latest dev branch on a different balance setup and it seems to be running nice and smooth. ¯\_(ツ)_/¯
Also I tried a few different sleep commands with specified wake up times but it seemed to make no difference. I also checked the time that the balance app loop takes to run (excluding sleeps), and it sat consistently at 0 microseconds (not sure if that means its fast or i measured incorrectly lol).
I opened an issue for this, but thought I'd share in this thread too - selecting "No App" prior to a Firmware update is a bad idea - doing so disables/brakes Bluetooth forcing me to connect via USB to recover. For now I'll be selecting the UART app for firmware updates...
I now always switch to the UART app before uploading firmware, so no more current spikes. But the clunky motor noises are still there and I can't figure out how to get rid of them, and the transition to/from sensorless is also very scary (grinding noises). I had to go back to 5.2 last night so I could enjoy a little evening ride...
Sorry if this is the wrong place to ask this question - but can you point me to any tutorial (document or video) that explains how to properly calibrate and tune a hall-sensored motor by hand? I feel like the whole balance board community is just relying on wizards but nobody seems to understand how to properly troubleshoot or calibrate a motor manually. I would love to use 5.3 but right now I can't even focus on the new features since I can't get my motor control in order
it's not 100% related to FW 5.03. I'am running 2 x focbox unity (can bus) with FW 5.02 . When I do the motor wizard all wheels are spinning and it seems everything is ok but at the end it just shows me 3 of the 4 Motors in the motor detection list. With FW 5.03 it just shows me 2 Motors. Only with FW 5.01 all motors are shown correctly in the list. In all FW Versions all 4 motors are working when I use the remote.
Still trying to figure out why my motor runs like crap with 5.3, and also why a perfect 5.2 configuration when applied to 5.3 doesn't run smoothly - I noticed that the "Current/Voltage offsets" feature is a feature that appears to be enabled by default. Is there a safe way to disable this feature entirely? I can set "don't calibrate on boot", but what offset value disables the feature entirely? 0? Or 2048, which appears to be the default? Thanks!!
Yay! Beta26 magically fixed my motor issues. Now when restoring my 5.2 config my motor suddenly runs like a charm. It's a bit different, felt a bit weird at first at low speeds, but overall it's potentially even better than 5.2! Great work guys, whatever it is you did, thanks!!
hello I have a 4.2 flipsky vesc and I just did the firmware update that changed it to 5.2 as the latest firmware and now my throttle doesn't show up nor work to spin the motor but I can still use arrow keys to spin the motor? I have no clue HELP NEEDED
hello, i just updated my firmware from 4.2 to 5.2 on a 4.20 flipsky vesc and am not getting any throttle response in the vesc app or on the motor? HELP NEEDED
FWIW - with CheapFOCer, LittleFOCer, and BalancePro the odometer still gets reset on a firmware update. Do those VESCs simply not support the required EEPROM? Are there VESCs where the odometer survives a firmware update now?
Currently the odometer only works with hardware that has a shutdown function, as saving is triggered from there. It could probably be done when the input voltage drops below some level, but that has the risk of corrupting all eeprom emulation and thereby reset the motor configuration on the next boot.
What I did in another project was writing odometer value at the moment when RPMs or speed go from any number to 0. With some wear leveling, it can be a viable solution for the life of the controller. Some data can be lost only in an unlikly event of shutting down the controller while the motor is still spinning.
Another way is just writing it all to FRAM any time you want. A 16k chip would add only ~$1 to the bom and can also be used for saving mc and app conf between firmware updates.
Hey Ben, I see Shaman's Cheap Focer v1.0 is now natively supported with the new release; thank you very much for that! Can you please clarify if its for v0.9 or v1.0?
Thank you!
Mitch's Dterm filter commit in beta37 breaks compatibility with all previous betas and FW 5.2 - may I suggest that we reuse the old Dterm filter config value for the low pass filter value (we could change just the label, not the config value name), this would allow users to try the latest beta by just restoring their previous config.
This is my first E-Board using FocBox Unity hardware and the latest 5.03 beta from 5/23/21 and so far this has been super fun.
Default mode i use is FOC Mode with Hall Sensors on 90mm Hub Motors.
Tested HFI and HFI Start, it was a bit odd where it started great then cogged a bit, probably requires some additional tweaking on my end.
Field Weakening (I know its dangerous) gained another 3-5 MPH with an 8-10 amp change and seemed to work very well, i've been reluctant to go too much past 30 without some additional padding.
There is an odd brake phenomenon that happens around 1-2 mph where i get a noise/buzzing and almost a sticky feel from the brakes, i believe this is unique to the FocBox though.
Overall super smooth, the VESC-Tool on Android has some quirks, if you stay connected for a long period datalogging and go-to change a motor configuration it totally breaks and goes back to default settings in my case the wheels move opposite directions, disconnecting and reconnecting before a motor change seems to keep this from happening.
Thanks for the hard work!
Edit: can someone educate me on the phase filter's? i'd be happy to test but it seemed to make no difference for me.
I managed to blow up a FOCBOX Unity with the 5.03 firmware, but there are ton of different non-firmware-related things that could have caused it. The specific failure mode is a big two-terminal device near the battery-connector-side hall connector burned up (unfortunately the silkscreen label got burned off), and it seems to have taken out the DRV chip on the same side out as well.
I had it configured with FOC and hall sensors and it was working beautifully at low speeds, but when I took it outdoors and descended a really gentle slope at maybe a brisk walking pace I heard a sizzle and smelled smoke. I pulled the battery cable and took it indoors to check out the damage. Turning it back on briefly led to more smoke from the same part.
Things that might have caused this:
My software might have sent a 10A handbrake command at the aforementioned brisk walking pace (unlikely though, as I have a speed limit of 10cm/s and it only turns on for a fraction of a second to give a little haptic feedback).
My cheap-ass batteries might have had their overcurrent protection kick in while gently braking (I'm using two inexpensive 10S1P packs in parallel). I would think the firmware would hit a voltage limit and disable itself though?
The Unity might have had a hardware defect (this is the first time I used it on a rough surface so the first time it was subjected to a lot of vibration).
I might have broken something. There was a weird current-sensing issue with the USB-connector-side motor that I thought was hardware-related. I took the heatsinks off and poked a little hole in the conformal coating on the shunts while verifying the hardware, and then reassembled it, and maybe screwed something up with something conductive touching something it shouldn't.
The Unity might have been having trouble keeping up with the new 25kHz default switching frequency
I wouldn't read too much into this but I'll probably do the rest of my development with the release firmware/VESC tool on two non-unity FOCBOXen.
Dang, i have been using 5.03 for like two weeks now? Focbox unity and hall sensor with hub motors.
been ripping on it pretty hard, i will say there is a definite funky issue when braking as it switches from sensorless to hall as it follows the threshold ERPM when modifying it, the issue only happens in hall mode, tuning the PI controller made it 10x worse as its trying to correct more aggressively, ill be switching modes until i can diagnose is further.
By chance were you noticing this with yours?
Edit: Did more testing, its like when it gets back into hall sensor mode its position is backwards causing it to act like cogging, very funky. Maybe something to do with one of my motors being inverted? I don't think its why yours toasted though :-\
Been trying to squeeze a bit more performance out of this thing but i'm confused by these results.
The field weakening i raised up to 93% and same with the Q axis setting to match under advanced but it seems to always activate at 87-89% ? unless i'm reading incorrect and thats just when backEMF starts to hinder performance a ton.
am i misunderstanding id with field weakening, this is all new stuff to me.
edit: figured it out after countless hours of messing with it....must have been a corrupt config? i factory reset it fresh and with the same exact settings it works totally fine now :-|
Hello, I'm not very expert about Vesc configuration but I wanted to try this new firmware because the cogging start with HFI when you need a little more torque from standstill really brother me (for example when you start with the wheels stuck in tall grass or mud) and there was even the problem that quote often, mostly giving just a little throttle from standstill or using smart reverse, one wheel turn in the wrong direction. With my configuration (Trampaboard with 6376 160kw and Vesc hd60) this firmware works so much better than the previous version!! When you start you have just a moment of noise, the "whistle" is really for a tenth of a second and is much less loud then with the HFI mode of the 5.02, it give me so much torque and even power, with not load even the speed of rotation of the wheels Is more, zero problems with the wrong direction of the wheels (never happens), and much less cogging from start. The cogging is still present if you need very much torque starting from standstill but is significantly less and It happens much less. Very quiet and I'm not sure but it seems to me that it heats less.
So I'm very happy, with my configuration it works great.
Been trying to get a bit more top speed, seems with my weight/power even with more field weakening there is a point where it just doesn't help. (expected though)
This is the run with a high field weakening set, freewheel the motors do 12+ mph over base which is crazy.
The one odd item is the power draw, it could be inaccurate when in field weakening but according to this graph its wildly going over my battery max, set 17amp x2, seeing upwards of 55 amps which isn't even possible with this configuration and oscillation yet the board/motor feel totally smooth, this is a 2 shunt design so i know there is a mess of noise.
I use spintend ubox (based on 75/300), the current fw is 5.2.55 and I did not understand how to correctly use the APP to use: "ADC and UART".
My main control is "Current no reverse ADC2 break", but sometimes I want to manually brake via UART. However, when I try to somehow interact with vesc via uart (for example, in vesc tools-controls), the motor just makes a sound and nothing happens.
I assume that the set value is overwritten after (1 / adc update rate) seconds and it turns out that this scheme (adc and uart) is not working?
Am I doing something wrong or is it a bug in fw?
I'm running beta 37 on an ebike with a ZESC Raiden 7 and Crystalyte 3540 hub and I have 10 amps of field weakening (FW). At higher RPM I think I'm feeling a torque ripple from the FW. Has anyone else experienced ripple or vibrations with FW?
Was bench testing my motors one after another, and had vesc tool crash on me during motor detection. After I restarted the app it did detection fine the second time, so I'm not sure what went wrong here.
Console was filled / being spammed with the line
WARNING (qrc:/qt-project.org/imports/QtQuick/Controls/Styles/Base/CircularTickmarkLabelStyle.qml:260 ): qrc:/qt-project.org/imports/QtQuick/Controls/Styles/Base/CircularTickmarkLabelStyle.qml:260:28: QML ListModel: remove: indices [-1 - 0] out of range [0 - 0]
Using the 2021-07-14 build for FW 5.3 on Arch Linux, Stormcore 100D, 12s li-ion battery. Was setting up a single TorqueBoards 75kv direct drive motor with 28 poles at the time.
Not sure how important this is or not, but thought I'd mention it.
Hi, on my VESC HD-60T TWIN the beta firmware 5.3 is not available for update. How can I update this controller so I can use the same new firmware on all VESCs (they are connected via CAN with two additional VESC 6 MkV). Both of the VESC 6 MkV can be updated without problems.
400A Phaseamps are the limit of the default firmware of the VESC 75/300. When changing to the NO HW LIMITS Firmware, it did not use the 420A Phase I changed in Vesc-tool, which looks like a bug in beta fw from 27.06.2021. Is this behaviour normal?
thank all for they're work on this amazing project.
Field weakening works very good with my setup. I could increase top speed from 35 to 45km/h.
One little problem occurs within the Android app RT DATA screen. The ERPM and Speed gauge max values are not enough and the display goes up to the top.
After looking to the code i think the problem is within RtData.qml line 158 with doesn't respect field weakening:
Hi
Thank you for this amazing project.
The serial port is one of the most important ways to communicate with vesc.
I use Vesc 75/300. And the firmware version is 5.03.
I could not communicate with vesc using an existing library such as SolidGeek and similar libraries. Apparently, there are changes in the new version of vesc that no longer work with SolidGeek.
I think a library is needed to connect microcontrollers to vesc. And someone has to work on that.
Has anyone with version 5.03 connected to Arduino with the serial port?
Thank you and best regards
Hello, I'm running the latest beta on my vesc 100/250. I have 16 motor poles, gear ratio of 10,wheel diameter 320mm, 75v at 22000mah, 200amps current with 100amps field weakening. Loaded the configuration into the vesc. It works great but the speed only shows up to 30mph on the real time data sceen. Without field weakening the top speed is 28-30mph. With field weakening enabled goes over 30mph no problem. Is there a way to change the tach so it will continue to read the speed over 30 mph?
what I need to "hold on motor position" if brake apply, example:
100% brake apply = 100A hold on,
20% brake apply = 20A
Now apply brake is about 2A current, no idea where is that from (can adjust that) , parking brake of course can hold on motor with even 100A but is not a solution because parking brake load always 100A no matter if you move wheel, uphill or downhill ,
Just updated to 5.3 beta FW using a 60d+ and ran into several issues.
First test:
Restored 5.2 configuration on 5.3 FW. Noticed that at higher constant speeds, I would get random, split-second cogging noises. I tried with and without traction control and there was no difference.
Did a fresh setup (cleared settings, did not do a configuration restore) and manually copied all settings from previous config. The same cogging issue persisted in the same manor. I also noticed that when my input was set to current no reverse with brake, one of my motors would jitter when braking on the bench.
The only other (extremely) small issue I noticed was that the stormcore rgb button was not color changing in accordance with the battery voltage. A 50% battery still displayed green on the button.
Before I exited, I backed up the 5.3 configuration I was having issues with to test on personally known-good firmware. I then rolled firmware back to 5.2, restored the 5.3 configuration, and the stormcore light turned blue (correct for 50%), the motor no longer twitched while braking, and the motor cogging at speed was eliminated. I did immediately lose access to the second uart port however which is unfortunate. Is it possible to update the stable v5.2 firmware to enable just the second uart and not other changes?
@benjamin, the math changes released in these latest betas could be considered breaking changes, since the prior identified parameters are now "wrong" for the corrected equations. This might be why venom is experiencing difficulties.
Is there a way to force a wipe of the old R,L and flux linkage values, so that users can't accidentally import them from prior configurations?
@venom121212, I would recommend redoing the parameter identification routine. With luck, that will solve your issues.
now only RPM control does not work, IB makes the motor go crazy, and i did not test PID (solved in the latest github version)
Build v3 10-31 Windows(10)
crashes on enabling RT data ( i have had this issue but not anymore(only experienced it 1 time again so far))
I have had this issue:
All controls do not work,
if i set duty cycle, Amperage, RPM, through the tool do not work. if i use UART to set RPM and Duty it doesnt work either
To clarify, when I did my "second test" that fresh setup I referred to was a wipe of esc and motor params and running both wizards again, then changing my personal preferences after the fact. This setup reacted with the same cogging as described previously.
Can you test it again? I did some work on the braking, and it seems much better now. Also, I think the stormcore files haven't been rebuilt for a few versions because the build script had a problem and stopped without me noticing. That should be fixed for the latest version.
I tested again with the new 11-01 version of the vesc tool app just now. I installed the stormcore 60d+ 5.3 beta firmware package that was suggested. I erased previous motors and input configs. I reran motor and input wizard but this time, I did not alter any other settings manually.
I noticed immediately that the brake was still controlling one motor just a twitch. Video of that here:
I can say with certainty that it is only causing one motor to move. The other makes no response, physically or audibly.
I then did a rev up test to see if the motor would still knock/cog at speed. Unfortunately this resulted in the same issue as before. Video of that here at ~7s and 9s:
I noticed that the detected motor parameters between 5.2 and 5.3 FW seemed significantly different.
5.2 FW detected motor parameters:
Motor 1
Motor Resistance (R)
10.8 mOhm
Motor Inductance (L)
4.03 μH
Motor Flux Linkage (^)
4.189 mWb
Current KP
0.0040
Current KI
10.83
Observer Gain (x1M)
56.99
5.3 FW detected motor parameters:
Motor 1 (same motor as before)
Motor Resistance (R)
16.8 mOhm
Motor Inductance (L)
11.22 µH
Motor Flux Linkage (^)
4.174 mWb
Current KP
0.0112
Current KI
16.84
Observer Gain (x1M)
57.39
I hope this helps with diagnosis and am happy to continue testing/troubleshooting. I noticed another thread regarding motor R and L measurements being off and got curious.
The differences in R and L look correct. They are defined in a different way now and the L measurement is improved, so the difference you are seeing is expected.
Regarding the issue at speed, can you go to General > Advanced and try setting Duty Cycle Current Limit Start to 50% or 100%?
I never thought of it that way - but I guess the brake current in the balance app means that technically the motor is running. When I first started playing with firmware changes my son once stepped on my board and rode away in the middle of a firmware update.... Agreed - hitting that upload button should stop the motor or switch the app to something safe
Tested the latest dev branch on a different balance setup and it seems to be running nice and smooth. ¯\_(ツ)_/¯
Also I tried a few different sleep commands with specified wake up times but it seemed to make no difference. I also checked the time that the balance app loop takes to run (excluding sleeps), and it sat consistently at 0 microseconds (not sure if that means its fast or i measured incorrectly lol).
I opened an issue for this, but thought I'd share in this thread too - selecting "No App" prior to a Firmware update is a bad idea - doing so disables/brakes Bluetooth forcing me to connect via USB to recover. For now I'll be selecting the UART app for firmware updates...
Are the current spikes you posted gone as well?
The system timer will probably not tick even once while the balance code runs. You can use this 10 MHz timer:
https://github.com/vedderb/bldc/blob/dev_fw_5_03/timer.c
I now always switch to the UART app before uploading firmware, so no more current spikes. But the clunky motor noises are still there and I can't figure out how to get rid of them, and the transition to/from sensorless is also very scary (grinding noises). I had to go back to 5.2 last night so I could enjoy a little evening ride...
Sorry if this is the wrong place to ask this question - but can you point me to any tutorial (document or video) that explains how to properly calibrate and tune a hall-sensored motor by hand? I feel like the whole balance board community is just relying on wizards but nobody seems to understand how to properly troubleshoot or calibrate a motor manually. I would love to use 5.3 but right now I can't even focus on the new features since I can't get my motor control in order
Hi Benjamin,
I noticed that you commited some changes to the dev 5.03 of VESC BMS as well.
Is the example schematic ready for sharing?
Thank you.
BR,
Danilo
Hi,
it's not 100% related to FW 5.03. I'am running 2 x focbox unity (can bus) with FW 5.02 . When I do the motor wizard all wheels are spinning and it seems everything is ok but at the end it just shows me 3 of the 4 Motors in the motor detection list. With FW 5.03 it just shows me 2 Motors. Only with FW 5.01 all motors are shown correctly in the list. In all FW Versions all 4 motors are working when I use the remote.
Best
Philo
Still trying to figure out why my motor runs like crap with 5.3, and also why a perfect 5.2 configuration when applied to 5.3 doesn't run smoothly - I noticed that the "Current/Voltage offsets" feature is a feature that appears to be enabled by default. Is there a safe way to disable this feature entirely? I can set "don't calibrate on boot", but what offset value disables the feature entirely? 0? Or 2048, which appears to be the default? Thanks!!
Yay! Beta26 magically fixed my motor issues. Now when restoring my 5.2 config my motor suddenly runs like a charm. It's a bit different, felt a bit weird at first at low speeds, but overall it's potentially even better than 5.2! Great work guys, whatever it is you did, thanks!!
hello I have a 4.2 flipsky vesc and I just did the firmware update that changed it to 5.2 as the latest firmware and now my throttle doesn't show up nor work to spin the motor but I can still use arrow keys to spin the motor? I have no clue HELP NEEDED
brayden gast
hello, i just updated my firmware from 4.2 to 5.2 on a 4.20 flipsky vesc and am not getting any throttle response in the vesc app or on the motor? HELP NEEDED
brayden gast
Did you choose uart+(pwm) ppm in the app tab?
FWIW - with CheapFOCer, LittleFOCer, and BalancePro the odometer still gets reset on a firmware update. Do those VESCs simply not support the required EEPROM? Are there VESCs where the odometer survives a firmware update now?
Currently the odometer only works with hardware that has a shutdown function, as saving is triggered from there. It could probably be done when the input voltage drops below some level, but that has the risk of corrupting all eeprom emulation and thereby reset the motor configuration on the next boot.
What I did in another project was writing odometer value at the moment when RPMs or speed go from any number to 0. With some wear leveling, it can be a viable solution for the life of the controller. Some data can be lost only in an unlikly event of shutting down the controller while the motor is still spinning.
Another way is just writing it all to FRAM any time you want. A 16k chip would add only ~$1 to the bom and can also be used for saving mc and app conf between firmware updates.
NextGen FOC High voltage 144v/34s, 30kw (https://vesc-project.com/node/1477)
Hey Ben, I see Shaman's Cheap Focer v1.0 is now natively supported with the new release; thank you very much for that! Can you please clarify if its for v0.9 or v1.0?
Thank you!
mohammad
It is for v1.0 only
Mitch's Dterm filter commit in beta37 breaks compatibility with all previous betas and FW 5.2 - may I suggest that we reuse the old Dterm filter config value for the low pass filter value (we could change just the label, not the config value name), this would allow users to try the latest beta by just restoring their previous config.
This is my first E-Board using FocBox Unity hardware and the latest 5.03 beta from 5/23/21 and so far this has been super fun.
Default mode i use is FOC Mode with Hall Sensors on 90mm Hub Motors.
Tested HFI and HFI Start, it was a bit odd where it started great then cogged a bit, probably requires some additional tweaking on my end.
Field Weakening (I know its dangerous) gained another 3-5 MPH with an 8-10 amp change and seemed to work very well, i've been reluctant to go too much past 30 without some additional padding.
There is an odd brake phenomenon that happens around 1-2 mph where i get a noise/buzzing and almost a sticky feel from the brakes, i believe this is unique to the FocBox though.
Overall super smooth, the VESC-Tool on Android has some quirks, if you stay connected for a long period datalogging and go-to change a motor configuration it totally breaks and goes back to default settings in my case the wheels move opposite directions, disconnecting and reconnecting before a motor change seems to keep this from happening.
Thanks for the hard work!
Edit: can someone educate me on the phase filter's? i'd be happy to test but it seemed to make no difference for me.
I managed to blow up a FOCBOX Unity with the 5.03 firmware, but there are ton of different non-firmware-related things that could have caused it. The specific failure mode is a big two-terminal device near the battery-connector-side hall connector burned up (unfortunately the silkscreen label got burned off), and it seems to have taken out the DRV chip on the same side out as well.
I had it configured with FOC and hall sensors and it was working beautifully at low speeds, but when I took it outdoors and descended a really gentle slope at maybe a brisk walking pace I heard a sizzle and smelled smoke. I pulled the battery cable and took it indoors to check out the damage. Turning it back on briefly led to more smoke from the same part.
Things that might have caused this:
I wouldn't read too much into this but I'll probably do the rest of my development with the release firmware/VESC tool on two non-unity FOCBOXen.
Dang, i have been using 5.03 for like two weeks now? Focbox unity and hall sensor with hub motors.
been ripping on it pretty hard, i will say there is a definite funky issue when braking as it switches from sensorless to hall as it follows the threshold ERPM when modifying it, the issue only happens in hall mode, tuning the PI controller made it 10x worse as its trying to correct more aggressively, ill be switching modes until i can diagnose is further.
By chance were you noticing this with yours?
Edit: Did more testing, its like when it gets back into hall sensor mode its position is backwards causing it to act like cogging, very funky. Maybe something to do with one of my motors being inverted? I don't think its why yours toasted though :-\
i guess the 5.03 development seems a bit stale.
Been trying to squeeze a bit more performance out of this thing but i'm confused by these results.
The field weakening i raised up to 93% and same with the Q axis setting to match under advanced but it seems to always activate at 87-89% ? unless i'm reading incorrect and thats just when backEMF starts to hinder performance a ton.
am i misunderstanding id with field weakening, this is all new stuff to me.
edit: figured it out after countless hours of messing with it....must have been a corrupt config? i factory reset it fresh and with the same exact settings it works totally fine now :-|
when the minimum current is set at 0A, vesc can't save the configuration, after rebooting everything goes back to the default configuration
Hello, I'm not very expert about Vesc configuration but I wanted to try this new firmware because the cogging start with HFI when you need a little more torque from standstill really brother me (for example when you start with the wheels stuck in tall grass or mud) and there was even the problem that quote often, mostly giving just a little throttle from standstill or using smart reverse, one wheel turn in the wrong direction. With my configuration (Trampaboard with 6376 160kw and Vesc hd60) this firmware works so much better than the previous version!! When you start you have just a moment of noise, the "whistle" is really for a tenth of a second and is much less loud then with the HFI mode of the 5.02, it give me so much torque and even power, with not load even the speed of rotation of the wheels Is more, zero problems with the wrong direction of the wheels (never happens), and much less cogging from start. The cogging is still present if you need very much torque starting from standstill but is significantly less and It happens much less. Very quiet and I'm not sure but it seems to me that it heats less.
So I'm very happy, with my configuration it works great.
update 2021_06_15 kill switch not working
Been trying to get a bit more top speed, seems with my weight/power even with more field weakening there is a point where it just doesn't help. (expected though)
This is the run with a high field weakening set, freewheel the motors do 12+ mph over base which is crazy.
The one odd item is the power draw, it could be inaccurate when in field weakening but according to this graph its wildly going over my battery max, set 17amp x2, seeing upwards of 55 amps which isn't even possible with this configuration and oscillation yet the board/motor feel totally smooth, this is a 2 shunt design so i know there is a mess of noise.
hello Benjamin and other participants.
I use spintend ubox (based on 75/300), the current fw is 5.2.55 and I did not understand how to correctly use the APP to use: "ADC and UART".
My main control is "Current no reverse ADC2 break", but sometimes I want to manually brake via UART. However, when I try to somehow interact with vesc via uart (for example, in vesc tools-controls), the motor just makes a sound and nothing happens.
I assume that the set value is overwritten after (1 / adc update rate) seconds and it turns out that this scheme (adc and uart) is not working?
Am I doing something wrong or is it a bug in fw?
I'm running beta 37 on an ebike with a ZESC Raiden 7 and Crystalyte 3540 hub and I have 10 amps of field weakening (FW). At higher RPM I think I'm feeling a torque ripple from the FW. Has anyone else experienced ripple or vibrations with FW?
I am running 90-100A of field weakening with a small IPM motor.
Very smooth.
FW ramp time set to 0ms
FOC Current Controller Decoupling set to BEMF took care of the brake surge while letting off at high speed under FW
Also having problems with the Hub motor, huge torque ripple when FW is active.
I am haveing a small problem with my firmware updating .
It pops up saying
CAN forwarding must be disabled when uploading firmware to all VESCs at the same time.
Thomas Donohue
Was bench testing my motors one after another, and had vesc tool crash on me during motor detection. After I restarted the app it did detection fine the second time, so I'm not sure what went wrong here.
Console was filled / being spammed with the line
Using the 2021-07-14 build for FW 5.3 on Arch Linux, Stormcore 100D, 12s li-ion battery. Was setting up a single TorqueBoards 75kv direct drive motor with 28 poles at the time.
Not sure how important this is or not, but thought I'd mention it.
Hi, on my VESC HD-60T TWIN the beta firmware 5.3 is not available for update. How can I update this controller so I can use the same new firmware on all VESCs (they are connected via CAN with two additional VESC 6 MkV). Both of the VESC 6 MkV can be updated without problems.
Thanks for hints
400A Phaseamps are the limit of the default firmware of the VESC 75/300. When changing to the NO HW LIMITS Firmware, it did not use the 420A Phase I changed in Vesc-tool, which looks like a bug in beta fw from 27.06.2021. Is this behaviour normal?
Link to forum post: VESC help offered for private persons and companies
Website: www.electricfox.de
Hi
thank all for they're work on this amazing project.
Field weakening works very good with my setup. I could increase top speed from 35 to 45km/h.
One little problem occurs within the Android app RT DATA screen. The ERPM and Speed gauge max values are not enough and the display goes up to the top.
After looking to the code i think the problem is within RtData.qml line 158 with doesn't respect field weakening:
var rpmMax = (values.v_in * 60.0) / (Math.sqrt(3.0) * 2.0 * Math.PI * fl)
and also within RtDataSetup.qml line 260:
var rpmMax = (values.v_in * 60.0) / (Math.sqrt(3.0) * 2.0 * Math.PI * fl)
@benjamin
Could you please double check?
Thank you and best regards
lux
Hi,
vesc_tool_test_windows.exe
seems to be corrupted
in the archive: vesc_tool_test_2021-09-15.zip
Linux & Android files work fine
John
Hi
Thank you for this amazing project.
The serial port is one of the most important ways to communicate with vesc.
I use Vesc 75/300. And the firmware version is 5.03.
I could not communicate with vesc using an existing library such as SolidGeek and similar libraries. Apparently, there are changes in the new version of vesc that no longer work with SolidGeek.
I think a library is needed to connect microcontrollers to vesc. And someone has to work on that.
Has anyone with version 5.03 connected to Arduino with the serial port?
Thank you and best regards
Hello, I'm running the latest beta on my vesc 100/250. I have 16 motor poles, gear ratio of 10,wheel diameter 320mm, 75v at 22000mah, 200amps current with 100amps field weakening. Loaded the configuration into the vesc. It works great but the speed only shows up to 30mph on the real time data sceen. Without field weakening the top speed is 28-30mph. With field weakening enabled goes over 30mph no problem. Is there a way to change the tach so it will continue to read the speed over 30 mph?
Any chance you could look at UART for those of us who want to build dashboard mounted arduino based LCD displays (ebikes)?
Currently it cannot obtain any UART Tx despite the app set up correctly when using a VESC6 and fw 5.2,
It seemed that the fw changes from 3 to 5 have broken something as there are several videos of people doing this, but not with fw>5.
Thanks
SP
Any chance to add brake when is "stationary" ?
what I need to "hold on motor position" if brake apply, example:
100% brake apply = 100A hold on,
20% brake apply = 20A
Now apply brake is about 2A current, no idea where is that from (can adjust that) , parking brake of course can hold on motor with even 100A but is not a solution because parking brake load always 100A no matter if you move wheel, uphill or downhill ,
Martin
Just updated to 5.3 beta FW using a 60d+ and ran into several issues.
First test:
Restored 5.2 configuration on 5.3 FW. Noticed that at higher constant speeds, I would get random, split-second cogging noises. I tried with and without traction control and there was no difference.
Link to video showing motor cogging issue:
https://youtube.com/shorts/yb_bPZ0YAxQ?feature=share
Second test:
Did a fresh setup (cleared settings, did not do a configuration restore) and manually copied all settings from previous config. The same cogging issue persisted in the same manor. I also noticed that when my input was set to current no reverse with brake, one of my motors would jitter when braking on the bench.
Link to video showing braking issue:
https://youtu.be/9orF9KIbtV8
The only other (extremely) small issue I noticed was that the stormcore rgb button was not color changing in accordance with the battery voltage. A 50% battery still displayed green on the button.
Before I exited, I backed up the 5.3 configuration I was having issues with to test on personally known-good firmware. I then rolled firmware back to 5.2, restored the 5.3 configuration, and the stormcore light turned blue (correct for 50%), the motor no longer twitched while braking, and the motor cogging at speed was eliminated. I did immediately lose access to the second uart port however which is unfortunate. Is it possible to update the stable v5.2 firmware to enable just the second uart and not other changes?
Cheers!
@benjamin, the math changes released in these latest betas could be considered breaking changes, since the prior identified parameters are now "wrong" for the corrected equations. This might be why venom is experiencing difficulties.
Is there a way to force a wipe of the old R,L and flux linkage values, so that users can't accidentally import them from prior configurations?
@venom121212, I would recommend redoing the parameter identification routine. With luck, that will solve your issues.
The latest changes will not work with old configs, so that is the problem for sure. You need to run the wizards or do manual detection again.
now only RPM control does not work, IB makes the motor go crazy, and i did not test PID (solved in the latest github version)
Build v3 10-31 Windows(10)
crashes on enabling RT data ( i have had this issue but not anymore(only experienced it 1 time again so far))
I have had this issue:
All controls do not work,
if i set duty cycle, Amperage, RPM, through the tool do not work. if i use UART to set RPM and Duty it doesnt work either
To clarify, when I did my "second test" that fresh setup I referred to was a wipe of esc and motor params and running both wizards again, then changing my personal preferences after the fact. This setup reacted with the same cogging as described previously.
Can you test it again? I did some work on the braking, and it seems much better now. Also, I think the stormcore files haven't been rebuilt for a few versions because the build script had a problem and stopped without me noticing. That should be fixed for the latest version.
I tested again with the new 11-01 version of the vesc tool app just now. I installed the stormcore 60d+ 5.3 beta firmware package that was suggested. I erased previous motors and input configs. I reran motor and input wizard but this time, I did not alter any other settings manually.
I noticed immediately that the brake was still controlling one motor just a twitch. Video of that here:
https://youtu.be/Xr7uAm-h2FY
I can say with certainty that it is only causing one motor to move. The other makes no response, physically or audibly.
I then did a rev up test to see if the motor would still knock/cog at speed. Unfortunately this resulted in the same issue as before. Video of that here at ~7s and 9s:
https://youtu.be/7pF6Ltr6CGY
I noticed that the detected motor parameters between 5.2 and 5.3 FW seemed significantly different.
5.2 FW detected motor parameters:
Motor 1
Motor Resistance (R)
10.8 mOhm
Motor Inductance (L)
4.03 μH
Motor Flux Linkage (^)
4.189 mWb
Current KP
0.0040
Current KI
10.83
Observer Gain (x1M)
56.99
5.3 FW detected motor parameters:
Motor 1 (same motor as before)
Motor Resistance (R)
16.8 mOhm
Motor Inductance (L)
11.22 µH
Motor Flux Linkage (^)
4.174 mWb
Current KP
0.0112
Current KI
16.84
Observer Gain (x1M)
57.39
I hope this helps with diagnosis and am happy to continue testing/troubleshooting. I noticed another thread regarding motor R and L measurements being off and got curious.
The differences in R and L look correct. They are defined in a different way now and the L measurement is improved, so the difference you are seeing is expected.
Regarding the issue at speed, can you go to General > Advanced and try setting Duty Cycle Current Limit Start to 50% or 100%?
Absolutely. I tried both values for that setting and the same issue persisted.
Should the current value on the real time data tab jump negative at all when throttling forward? That was the only thing that stood out as odd to me.
Pages