I just think it’s a matter of manpower, yes in a managed team of developers this is needed regardless and therefore easier to publish. For one person deving their project it is extra work since the roadmap is mostly in their head. Not saying that extra work isn’t worth the payoff though.
4 Likes
12s4p 30Q on TB6380 with VESC6+ and 3dservisas geardrive
2 Likes
Can someone tell Benjamin not to hold the motor when hes using current control? He almost dropped it when it was spinning up and while it was only a 5032 or something it can still do crazy damage to his precious fingers.
4 Likes
It doesn’t have to be this way. With the proliferation of third party devices, it would be a really nice thing to maintain backwards compatibility for some APIs, and announce in advance if these APIs will change.
Even better, to have versioned APIs with a convention for aging old versions out. This way the third party devices can check for compatibility instead of just doing random behavior.
It doesn’t have to slow down changes for vesc itself. Just a promise to 3rd party devices that 3rd party interfaces will remain stable, and changes to it are predictable.
BTW it’s amazing you got Jeff and Benjamin working together. Thank you @Trampa.
13 Likes
Still confused about why Benjamin is NEVER present in ANY discussion and we only hear of this mythical creature by proxy.
20 Likes
This check is implemented in metr now. A firmware compatibility check is a matter of the third party software.
Worst case now: After an update you realise that the third party App rejects functionality and you need to go back to the previous FW. In Benjamins Github there are all FWs for download.
The path is VESC-Tool >> res >> firmwares
Open the FW folder you need.
60 is for all VESC 6 and HW 6 based designs,
60MK3 for the latest VESC 6 MKIII,
410_o_411_o_412 for the HW 4.1x based ESCs and Focbox
There is a HISTORY button top right, click it. Follow these steps:
- Browse to firmware revision needed, click on <> at right side.
- The entire repository is now set back in time.
- Now browse again to the FW needed for your Hardware.
- Download the VESC_default.bin file.
- Open VESC-Tool and go to Firmware menu
- open the Custom File tab on top of the window.
- browse to the vesc_default. bin you just downloaded.
- hit upload and you will be back to normal
If you saved the Config before doing the update, you can now re-load it to finish the process.
3 Likes
He asked about an API check…
This would be an incredibly well received addition.
8 Likes
Yeah, this. It’s called Semantic Versioning and it’s a standard in the open source software world. Almost nobody makes stuff without using it, except VESC.
Seems like a good fit, naturally.
Anything 2.xx.xx is compatible with anything else 2.xx.xx but not 3.xx.xx et cetera
The first numbers represent breaking API changes, the second numbers represent feature additions and the third numbers represent bugfixes or builds.
10 Likes
Has been debated. Vedder thinks for the VESC stuff it is not super practical. In many cases a FW update brings incompatibilities on the table anyway. He keeps things flexible. In your example the first digit would change a lot, the last digits would not be used a lot. It would be quite confusing.
1 Like
Confusing is the current situation. Semantic Versioning is the standard.
7 Likes
Also Vedder didn’t say anything about this. Someone else claims he did, as hearsay.
Where is Vedder?
7 Likes
Actually no. I was talking about API versioning, which is somewhat common in web APIs. As @mmaner it’s more of an online check via API. To simplfy (and maybe a dumb explanation because I’m not that smart), when you make a api call, you include a api-version as part of the request. You can also query for which version of the API is implemented. This is a powerful concept, and different from semantic versioning.
The api version for web API calls is usually a part of the URL, but this concept can map over to function calls by adding a apiversion parameter. I think…
For example, on vesc side, a particular firmware would support get_values() for apiversion in [v1, v2, v3]. Each apiversion has slightly different behavior, but the behavior of each version is well defined. new firmware drops with new features for get_value(), so apiversion v4 is added, but because of policy, v1 is deprecated and removed. Something like that.
Ugh I realize now if the API change changes the parameter list or return value format, this might not be that easy. Of course it can be solved with “one more layer of abstraction” 
2 Likes
In VESC case: App asks for FW version. If it is part of a list of compatible FW numbers, the App would allow itself access. If not it would reject to perform changes. Pretty simple.
It can be better than this. The firmware can promise to have a certain set of behaviors, kind of a promise. That way the 3rd party is not tied to particular range of firmware versions (and automatically incompatible with future versions even if the api has not changed), but to the promises. And the promises can be versioned, so that they can change but in a stable predictable way.
4 Likes
He’s just gonna keep arguing, the man has never been wrong in his entire life…
14 Likes
Javascript async 
The VESC Firmware is kept very flexible to allow things to change as needed. So it is not super easy.
Open source apps can pretty much copy paste the code bits from Vedder to establish compatibility very fast.
Yeah I’m not debating that. Only pointing out that I can be vastly better.
2 Likes
I’m running into input wizard issues. It’s giving me “your vesc or canbus vesc has an old firmware” even tho both sides show v4.0
Motor detection passed on both sides. FOC. Sensorless.
Vesc tool 2.01
Fsesc 6.6 dual.
1 Like
I had multiple times the problem that after input config I couldn’t connect to FW 4.0 at all. Had to downgrade with 1.27 (the latest I dl before) to an older FW. In the older Tool it was no problem to connect to the ESC so it might be a bug.