In the code shown below, why would the brain often skip over the “drive reverse” command?
If I put a wait command in between, it doesn’t skip over the reverse. I just do’t understand why the wait command is required, though.
If I put a wait command in between, it doesn’t skip over the reverse. I just do’t understand why the wait command is required, though.
Is “BEGIN” being brodcasted?
it could be that the code is moving onto “drive reverse” from “drive forward” too fast without the wait command. Two years ago, trying to activate a pneumatic piston for a fraction of a second, we would set the piston to TRUE and then FALSE, and it wouldn’t work without an incredibly small wait command in between, because unless specified, the code will essentially run the commands put into it with no perceivable gap between. It’s hard to remember, but the code takes everything you put into it literally to the fullest extent. I still struggle with remembering that. 
additionally, If you are ever having issues with any code, you can always add wait commands for debugging, to help identify exactly where the issue is.
1 Like
I think so? Honestly I’m a bit confused by this code. I’m a teacher and a student came up with this version of code, and it seems as though using events like this are the only way for the brain to listen simultaneously for both the gyro and the bumper. So I believe BEGIN is being broadcasted - the brain does respond to the bumper being pressed.
This sounds like a reasonable explanation, thank you. But I don’t understand why the brain wouldn’t “know” that it didn’t go reverse at all. Like wouldn’t it check the encoders or wouldn’t there be something telling it that it skipped that? I just really want to understand the “why” here.
Is this on a generation 1 or generation 2 brain ?
1 Like
Have seen the same thing MANY times. The wait can be even smaller… I’ve seen good results with .02 seconds.
1 Like
this is a generation 1 brain
Had a quick look but could not reproduce the issue.
2 or 4 motor drivetrain ?
which motor ports ?
Any external gearing ?
Using a gyro for turns ?
Any more details you can provide ?
1 Like
the brain can do only as it is told, if you tell it to check the encoders, It can do so, but without specific instructions, it won’t. I am not an expert by any means, I’m all self-taught, but what has happened for our team, and what I’ve seen happen for others is that the brain thinks it has gone far enough and completed the code, when it hasn’t, or there is some technical caveat that allows the code to progress without full completion. Usually, if it gets too far out of hand I’ll recode the program in another project from scratch, but doing it a different way, and that can help. Other people on the forums are more qualified than me, ill let @jpearman answer this better 
I tried it in two different robots, two different computers. Same issue with skipping the reverse command.
2 motor drivetrain
ports 1 and 6
1:1 gear ratio (using standard drive base)
yes using a gyro for turns
1 Like
web version of VEXcode
Try it again, but hold the robot in the air… let the wheels free spin. See if that makes a difference.
1 Like
I did look at this today, and occasionally could reproduce, but it is very intermittent. I’m not exactly sure where the problem is yet but have some theories on what may cause it. Later this week I will see if IQ generation 2 has the same issue and plan from there, however, to fix on IQ generation1 will need an SDK/VEXcode update. For now, add the small delay (perhaps 50mS) as a workaround.
3 Likes
Sounds like jpearman has something to pursue, but I’d also be curious to see if the wait was moved into the forever loop either before or after the if block check.
Read the OP. Unless I’m missing something, ONLY the reverse block is being skipped, not the rest of the moves.
Yep, understood; it was a comment based on what James was seeing, and wondering if the tight loop checking for the end condition is potentially starving the rest of the system, which could cause strange behavior. In polling-based conditions, this is a very real issue that can happen, although I am pretty sure there’s attempts in the Vex OS to try to prevent that.
root cause for the issue is motor behavior.
The motor has a command to move to a relative or absolute target, we only use the absolute command but both work the same way. The motor is commanded and then, after a short delay, we check motor status in a loop to see if it has achieved the move. On top of this there are further complications such as an alternative motor spin or stop commands that may be sent from another thread needing to be considered. Anyway, when back to back move commands are sent (ie. the drivetrain forward followed by reverse) the motor sometimes holds on to the status from the prior move command for too long, why I don’t know, the motor code was written over 10 years ago and is not exactly easy to read due to being highly optimized to fit onto the simple cpu it runs on. Anyway, still thinking about a good fix beyond just adding more delay after sending the initial command. Unfortunately the limitations of the IQ motor compromise what we can do.
6 Likes
This!!! Our team had the same issue last year when stringing drives and turns together. The “micro wait” entries that @turbodog mentions is a great strategy to address this.