Im not sure if anyone had this problem or even tryied it out, but yesterday i was failsafe testing and realized that if i unplug the receiver cable while holding the throttle, the VESC will keep spinning at that speed until i reconnect the cable! Am i missing some setting or what? This is extremely dangerous.
Im wondering if there’s any solution. I can see a “timeout” setting in the VESC, but it does nothing. When there’s no PWM signal the board should do nothing, not keep the last value. I’ve set my remote failsafe, and that works fine if my remote disconnects or i turn it off.
There is a solution, but not on our end - you’d have to get either Vedder himself or a good C++ programmer to go into the VESC source and locate.
Now that Chinzw has found what looks like an easy repro scenario it shouldn’t be that difficult to fix. However, I’m not certain that there is just one bug here, there might be several.
Seems as though the best way to do it would be for those who send him checks every month to put a note in that politely asks him to look at the issue…
I’ll start going through the code once i get some free time. It seems that the timeout isn’t working as it should.
1 Like
The same problem exists in the serial interface - if you can look at that as well you might save my life 
Forgot to update this thread, as Benjamin explained in his forum BLDC Tool sends packets to the VESC to keep it awake, so the disconnect failsafe wont work while plugged in to the USB port. I haven’t had the time to try this out, but im pretty sure it will work like that.
That will likely clear up your repro scenario, but my failure was on the road.
What’s your exact problem?
I have a control board upstream that takes the input from the handheld controller (XBee) and converts it to commands the VESC understands and sends them via serial. The control board is powered by VESC. While riding on a trail the control board (I suspect) got hit by a static discharge that killed the processor (a Teensy 3.2) and shorted the power to the board to ground. (as soon as I removed the Teensy the power came back) So the control board is completely dead.
VESC did not timeout correctly and continued to execute the last command sent, which unfortunately was an accelerate command (it’s actually the VescUartSetCurrent(); command in RollingGecko’s arduino library.
Thanks,
Hmm,thats odd, since i can see in the code there’s a timeout implemented:
case COMM_SET_CURRENT: ind = 0; mc_interface_set_current((float)buffer_get_int32(data, &ind) / 1000.0); timeout_reset(); break;
I think the problem is in the code that receives the serial command.
My best guess is that there’s a buffer that the serial data goes into and that buffer does not get cleared between serial receive calls, so that when the call fails the buffer does not get updated and the same value gets passe down the line.
that code i pasted in my previous message is the one that handles the serial commands
what happens if mc_interface_set_current doesn’t return?
That’s part of the VESC so having your Rx or UART disconnect will not stop the function from returning.
I’m coming at this from an end-user standpoint, not a code standpoint, so maybe I’ll stop guessing what’s wrong
The bottom line is that somehow VESC does not time out in the instance where the serial stream is interrupted in an unknown fashion. My best guess is that holding both TX and RX low will cause this.
The other anomaly was that the power on the controller board was shorted to ground, but that was on the other side of a 3.3v regulator, so that wouldn’t pull the VESC 5v output directly to ground, but would put a significant load on it.
In any event, thank you for looking into it. I will try to create a repro scenario and will post here if I can do it.