Our team is now facing a weird problem that after we upgraded a brain to .13 firmware, the pistons go to a neither high nor low stage after we quit from a running program. (Never happen after restarting the brain and before entering any program). Brains with .12 firmware have no such problems. Is there any solution out there?
This leads to an air leak after quitting from the program and is really annoying.
Hm, not sure there is a short term solution to this.
3wire ports are now cleared to a default condition when a program exits, that’s currently digital input. Pneumatics are notorious for not handling valid control signals in a consistent way, it may have been that the power up condition (which was analog in) may have just been enough for them to turn off. We default the 3wire ports as a safety measure, we don’t know what the next program may be configured to do, and we also want to make sure any motors are disabled, using digital input is the de-facto way of achieving this type of thing.
Over the years we have had similar issues with pneumatics and other programming environments. see my detailed explanation of the root cause of problems with the cortex here.
We can consider adding something in 1.0.14 to mitigate this, but that may not be available before the end of this season. perhaps consider just creating a small program to set 3wire to digital output that you can run to keep the pistons activated or install an air valve.
I see. Is there any way to downgrade the firmware back to .12?
We do not provide a way to downgrade. I’m actually surprised that the difference between an analog input and digital input is enough to cause the solenoid driver an issue, but as I said, they are notorious for being temperamental. I’ll do some tests this weekend and try and see what may be going on. Do you have an air valve you can install between the tanks and solenoids ?
Yes we do but I think we would just shut down the brain to prevent the air leak since we have more than 1 solenoid so adding all would be too many. Thanks for providing solutions!!!
ok, usually the value is used near the tank, but I understand if the routing of your air lines make installation difficult.
Thanks for the feedback, we will try and provide a solution for this type of condition in 1.0.14.
Is there a reason for this? I think a tool (if even a privately-shared one) for doing this for debugging if a program-breaking change was caused by a VEXos update would be appreciated on occasion.
Why? That’s insane…