Third party software allowing configuration should really read out FW version, check against a compatibility list and refuse configuration if the FW doesn’t appear on the list. This is the hole point of FW versioning. Vesc-Toop has always done this for given reason.
8 Likes
It should, I agree.
But if you are supporting an API you should also refrain from doing breaking changes, unless you have a very good reason to!
The problem has nothing to do with open/closed source, if you have written a piece of software that integrates with others you should be careful with breaking changes. Give developers notice before hand and avoid changes not required.
Both parties are responsible, Vedder should have told everyone the changes are coming, and everyone else should have checked the version before sending commands.
It’s in your interest to have 3rd party apps integrate with the VESC, it allows the HW to be used by more people.
4 Likes
If you connect a VESC with the latest FW to an old VESC-Tool, you will get a message that the FW on the device is newer than the supported FW and you have limited functionality, basically only allowing FW changes. Configuration is not possible. Even the old BLDC-Tool had a FW compatibility cross check. The first 4 command lines have never changed and this trivial check has to be absolute standard in all Apps. Command 0 = get FW version. If the FW is not listed, your App should refuse to do anything other than offer FW update or downgrades, or state that no interaction is possible using the current FW.
It is a safety feature that exists since the very beginning to avoid HW damages or software issues. Standard since years. You can even use the old BLDC-Tool to downgrade or upload FW to a recent device.
Benjamin posted a video about the changes, we dropped a release notice here, so devellopers knew that a brand new tool is about to hit the market and it was obvious that the changes are massive and would require new FW support. Code release is happening probably tomorrow. There are a few changes to be made before everything can get uploaded to Github.
The safest way to configure your device is always using the official release. Benjamin can’t know how other Apps exactly interact or what they do. There are many Apps available and some are closed source. App developers are responsible for their releases. A FW version cross check should be a standard procedure to avoid mishaps. This is not the first time that changes in VESC-Tool require new FW and vice versa. 3rd party Apps will then have to adopt to the latest FW. Changes don’t happen for the reason to annoy developers and users, they happen to bring new features and functionality to the market and are unavoidable, especially if things get shifted forward a lot. I introduced Roman to Benjamin and organized a meeting at Benjamins house. Both know each other and contact details have been exchanged, and matters have been debated.
10 Likes
Agree.
Nonetheless see how APIs usually handle than in the SW world. Search for “API deprecation”. You should have a sunset period at least so consumers have time to update their apps and end users don’t get bricked devices.
No one is arguing against evolution, we are just asking (some with a bit of rage) that it is done properly. VESC FW is not a special piece of software that can’t follow industry best practices.
4 Likes
If a mechanism has existed since beginning to check compatibility right from the start and one still hasn’t used it. They are the only ones to blame here. You can’t seem to understand that. You have unreasonable expectation from a one man army open source software. Feel like I am in www.reddit.com/r/ChoosingBeggars here.
1 Like
This is not true, if you do breaking releases you are telling your customers that they can either use your apps or the third party one. That’s just wrong unless you are trying to block third party apps.
Sunset period is one way to mitigate this problem. Being a one man army has nothing to do with it, does head count change what’s a good practice or not?
I’m just saying that there’s a better way, you might ignore it and keep doing it wrongly, or you can learn something new a do a better job next time.
3 Likes
Bricked devices shouldn’t exist if the Apps would do crosschecks and would refuse to send commands if FW doesn’t match. This standard was implemented from the very beginning to avoid bricked or damaged devices. 4 simple command lines handle that.
Vesc-Tool has the option to save the configuration into XMLs before updating to new FW. If you experience incompatibilities, you can simply upload the old FW, load XMLs and you are back to normal. Once the 3rd party App got updated you can update to the latest FW.
If things get bricked, it’s not a problem of VESC-Tool. On top of that, the official HW releases always featured a SWD port to allow re-flashing. Devices without SWD port shouldn’t exist. If anything goes wrong you are locked out and then things get more complicated. I prefer to have two doors and a key for the back door to hand.
4 Likes
All you guys had to do was care, even just a little bit, backwards compatibility.
I would suggest 2 things…
- If it is only FocBox’s that are getting bricked, might this not be purposeful? Seems convenient anyways.
- Frank, You literally just told half of your customer base to get lost. So many people are not going to trust your software now, so buying your hardware is off the table for them.
3 Likes
The issue here is that you seem to think we’re piling the blame all on one man. We’re not . In truth everyone is an fault. The app developers for not implementing the necessary FW detection to prevent such from happening , The user for not doing all the assurances of getting the compatible firmware, and Ben for engaging in software breaking practices where there were absolute alternatives presents.
Here’s the reality of what needs to be done and something I think Everyone can agree to :
-
All VESC-comptbaile applications Should do FW checks and block Read and writes if it is not on a list of Compatible Firmware. This can be as easy as creating an ever growing Enum/List and crosschecking the current FW to that structure.
-
The Github needs releases and change logs. Screw that Vesc-forum bullshit. I shouldn’t have to hunt down firmware in different locations and scour through to find them, much less someone who just bought a Focbox and needs to scour for specific versions. Utilizing Github’s release feature is the cleanest and easiest for everyone, and it’s something that you @trampa can do since Ben is so busy. There is no reason why this is something isn’t present on an ever-changing project like this. And change logs need to accomidate these releases (On github) or in a read.me file. There’s no reason I should have to open the software to see what’s changed.
-
Any update that Vedder does needs a grace period one , so that third party applications can have time to see these changes and implemented them (and lets be real here , one of the reason the VESC is so backed is because the various third party applications , they need to be treated with more respect.) and two so that community’s can give proper input of how the update affects their respective applications.
I’m not trying to hit on Ben here , but everyone here needs to take responsibilities on how their actions cost money, time, and support.
9 Likes
The speed and distance estimated in the mobile app works well. Pretty close to the GPS one.
Just need to restart your board to reset everything to zero. For as long as the board is on, the trip continues.
1 Like
Mate, get real! The new VESC-Tool is fully compatible with HW4.xx to the latest HW 6.6 (VESC 6Plus). A Focbox is a HW 4.xx design and can be configured using the new Software and Firmware. Benjamin even shows this in his video, configuring a 4.7 and 4.12 on his bike.
The only HW that is incompatible is Unity, which was purposely designed to be incompatible with VESC-Tool and standard FW.
VESC-Tool is OS and creating incompatibilities on purpose would not work, since someone could just change that part and have it compatible again. Believe me, someone would do that…
If anything, bricking happens if a 3rd party app doesn’t do FW version compatibility crosschecks and sends configuration commands although it shouldn’t. This is a problem of such apps, not VESC-Tool. BLDC-Tool and VESC-Tool have always had a feature preventing such things from happening. First thing that happens when you connect to VESC-Tool is a FW compatibility check. If it fails, you have to load compatible FW before doing anything else.
If an App writes settings without checking for compatibility, this is nothing Benjamin can prevent. The feature exists, but it needs to be used by the app connecting to the device. FW have version numbers for a good reason.
5 Likes
I’m out, you clearly don’t have a very good idea how firmware (or software broadly) development works…
C follows A…
A: You release new app & firmware C: VESC’s are bricked
The think you need to figure out is what happens at B. Getting pissed at me doesn’t do any good, take responsibility for your customers experience and product usability.
@Gustdd Honestly I think he does, he just has a pathological inability to listen to or understand other points of view ir admit when he is wrong. It’s been going on so long Its comical at this point.
2 Likes
I’m new here ^^
3 Likes
I think you are being unfair now. A. All the coding for the VESC tool is being done by Vedder not Frank. So any problems you have with the fw should be directed at him. It was already mentioned by @rpasichnyk that it is Vedder that does not care about backwards compatibility. B. Not only focboxes were affected by the change that caused the escs to brick. The fact that you heard more about them is due to the fact that i) they are the most used esc in this community ii) they lack the pins to connect an ST link to upload the bootloader so it is even more of a hassle to solve the problem. I should know, I was one of the lucky guys affected. C. I don’t see how he told off half his customer base. If you stick to using vesc based hardware with the VESC tool there is no problem If you want to use 3rd party apps you need to make sure they are compatible before proceeding. D. The solution to this problem has already been mentioned multiple times. 3rd party apps should check fw version before doing anything.
Maybe Vedder does not make it easy for 3rd party app developers (and in my opinion he should) but I don’t see anyone else (apart from @Ackmaniac) writing firmware if you don’t like Vedder’s.
5 Likes
To be fair with Benjamin, let me mention what he answered in an issue I created on Github :
Regarding compatible communication, I will write some documentation about that soon. The thing that is most likely to keep changing between firmware releases (for good reasons) is the motor and app configuration, but the other commands should be quite backwards compatible. At one point, when moving from BLDC Tool to VESC Tool, I inserted a command in the middle, but in the future I will avoid that.
If only Benjamin could be on this forum to talk with us directly. 
I’m in peace now. Can leave this shitstorm. 
6 Likes
OK, maybe I am, let’s look at each or you rpoints and see.
Doesn’t Frank make the choice when to release said software, I am pretty sure he has said so in the past. Assuming that is correct, doesn’t that make both Frank and Ben culpable?
OK, regardless of the presence of pins or not, most of the affected ESC’s were FocBox’s. I didn’t not say it was by design, just that it seemed convienent given the animosity between Trampa and Enertion.
OK, so if I put Autozone brand brake pads on my Charger instead Mopar brake pads the I am at fault when my brakes lock up at 60 mph? I’m sorry, saying “don’t user other stuff if you want reliability” is antithetical to what we do here, re DIY.
Is it not a basic expectation that, assuming Ben/Frank knew that this was an issue, we would be warned of this either in the app or more preferably at download? Its also possible that they did NOT know it was an issue and released the app/firmware prematurely which is an entire different conversation.
I’m not saying Trampa or Ben is at fault, I’m saying they share at least some of the fault because of the lack of warning and that is either because the didnt know not as thorough testing was not done or they didn’t care because it wasn’t VESC ™ hardware that would be nerf’d.
If the testing wasn’t done then it should be a simple thing to say “sorry, didn’t realize it was going to be an issue, here’s how you fix it”. If they just don’t care about 3rd party apps or hardware, at least be honest enough to admit it so people know to NOT use VESC™ apps/firmware on Non-VESC™ hardware.
In closing, I don’t expect anything from Trampa. For years they have not given a damn about the DIY community, profit is the holy grail. This is just the second coming of the same old calvary as my Granpa used to say.
2 Likes
i searched for Vesc Tool but i can’t find it in the play store. anyone got a direct link?
@mmaner to play devils advocate, If I jailbreak my iphone (don’t kill me @b264 
) is it apple’s responsibility to ensure that their software update doesn’t brick my phone because I jailbroke it?
5 Likes
That’s actually a really good point. In fact, no it is not Apple’s responsibility…but if Apply Open Sources the iPhone project then releases firmware updates that brick the OS versions of the iPhone then it absolutely IS Apple’s fault.
You gotta have apple’s to apple’s when making analogies. When you use the term jailbreak, that lends the connotation that FocBox users are somehow stealing from Trampa and that is simply not the case at all.
3 Likes