Firmware Problem?

School properties:
Win 10 Pro
Super Kit w/SMART Radios
VEX firmware 2.0.2

Home properties:
Win 10 Pro
Same super kit from school
VEX firmware 2.0.1

Just starting with three students programming in Modkit for VEX
Had them execute a square project: forward 300 mm/turn 90° left (x 4)
They all changed the power settings for drive & turn to 60 but no motor timeout used

I just attached the micro USB cable when I got home but DID NOT re-save the program from the from my home computer to the Brain

Works at home but will not work at school
School results are:
drive fwd 300
turn left 90 (about 105° actually)
turn left
turn left
turn left
turn left
turn left
turn left

It executes 8 movements only does one drive fwd

in the repeat 4 times loop, I added a wait 5 sec after the move fwd and the turn 90 left

The results were the same.

Rather stumped about the school results but at home, it works just fine with the same program in the Brain

I would like to get back to firmware 2.0.1 at school so I will uninstall VEXos Utility & reinstall which (IIRC) should display the various versions of firmware

Any other possibilities?

Thanks - Dennis

Dennis Munro
Technology Coordinator
All Saints Catholic School
Berlin, WI

A SNOW day today but I’m here

Spent more time at school today trying to figure out my problem.

Not sure how I erased the firmware in the Brain but it was setting at 1.01.
Got it back to 2.02.
Finally found where the .vesos files are located but 2.01 did not show up?
I think it did when I deleted everything VEX & also ran CrudCleaner & did the registry clean up.
Try that after supper.

Went home, restored the Project file I had setup, ran it, & of course it ran just fine.

The snipping tool does not work in this app?? so I entered it in as text
**when Start
set drive speed to 40%
set turn speed to 40%
set timeout to .3 sec
(repeat 4 times)
drive fwd 200 mm
turn left 90 deg


Cortex Wireless Programming.jpg
Cortex Wired Programming.jpg

Modkit users will probably be familiar with the occasional skipping of a motor command, it is something I have seen so many times over the years and never found a reliable work around for. The only (not particularly) helpful advice I can offer for this is to use ROBOTC instead of Modkit and you won’t see this issue at all, I guess it handles the motor movements differently.

What I ended up doing was to put a wait 2 seconds command in after doing two turns.
The way I found this was to display the value of each turn in degrees because I included the gyro in the mix as a debugging tool.
Primitive but it does work & is better than nothing.
Watching the display, I could see the messages posted to the display after each turn were ahead of the where the robot was actually at in its movements.

I would like an explanation (Modkit help is useless, in most cases - IMHO) of what the timeout does & some real life examples where it makes sense to use.
After spending 30+ years in the business world as an IBM business systems programmer & getting 12 lineal feet of manuals with each system we installed, I am spoiled.
Granted IBM killed a lot of trees, but the answer was behind me on my credenza & I just had to look for it.

Calvc01, thanks for the reply but I want the 6th graders to learn Modkit first & then step up to RobotC.
I am reluctant to throw C at then to start but I did think about it.
I’m considering converting the program to Graphical RobotC to show them the difference.

Thanks - Dennis

@asctech – All Hail the Red Book Collection!

I’ve taught 3rd and 4th graders RobotC, you might find your 6th graders are smarter than you think.

The random errors in Modkit are a deal breaker for me. Sadly I have a group that only has iPads, so I’m stuck with Modkit for them.

@ascstech I’ll give you my understanding of the timeout function.

As you know, the motors have their own processors and firmware. So when your program tells a motor to turn say 2 revolutions, the Brain says: Hey, motor, turn 2 revolutions and let me know when you are done. Once the motor comes back saying yep, done it, the Brain sends the next instruction in the thread.

Now, if the motor gets stalled and never reaches it’s target, it’ll never go back to the Brain to say it’s finished it’s move and sometimes, you might want the rest of the program to execute anyway. In this case, I think you can use a timeout so if nothing happens for X amount of time, the Brain just cracks on with the next instruction anyway.

If you use the attached 2 programs as an example, you can see the functionality. You just need 1 motor with an axle with a wheel so you can stall it.

First, download the left program to the Brain.

  1. Run the program and the wheel will spin 5 times. When the wheel has finished, the I’m done message will appear
  2. Stall the wheel and then run the program. The I’m done message will never appear since the motor never completes the movement.

Now, download the right program to the Brain. This one has a 1 second timeout.

  1. Run the program and the wheel will spin 5 times. When the wheel has finished, the I’m done message will appear. The message only appears once the movement is complete, it doesn’t appear after 1 second so I assume the motor handles the timeout, not the Brain.
  2. Stall the wheel and then run the program. The I’m done message will appear after 1 second since it gives up and moves on due to the timeout.

I have no knowlege of the workings of the VEX IQ firmware at all, but my suspicion is there is a bug somewhere that sometimes falsely reports that a motor move is complete or falsly reports a timeout but this is speculation only. You don’t see this bug in ROBOTC ever since ROBOTC has it’s own way of handling motor movements.


I have decided to wait until next school year to do Robotc.
This is the schools first attempt at programming, either via or VEX IQ robots.
I will flat out say the enthusiasm is there & the problem is how to tame it down some.
That is what happens when I have 3 enthusiastic 6th graders with only one robot.
But it gives the other two to watch & learn, and that has worked out fairly well.

My firmware problem has been solved automagically - somehow.
After the firmware ended up at ver.1.01 (I wish I knew what I did to get it there), I reloaded ver.2.0.2.
And ever since that reload & update of the devices, things are working just fine.
So the big assumption is the firmware got corrupted somehow.

I have another problem that has since arisen but that is another thread on the forum.

Thanks to all who have added to this thread.

I will run the programs calvc01 posted this coming week because that is how you learn.

Thanks - Dennis


It could be a timeout issue as stated above.

My team is having this problem. My team is using RobotC (text). Our program ran fine 3 times in a row. On the 4th run, it hung up on the WaitUntilMotorStop command. It has consistently hung on that command since. I’m a veteran software developer with nearly 30 years of experience. This behavior has been very frustrating for my team and I. We’ve struggled to find an explanation or solution to the issue. Our state tournament is in 6 days and we have no solution to this issue yet. More info on our problem and a snippet of our source code relevant to the issue can be found in this thread: setMotorTarget...WaitUntilMotorStop Doesn't always Work

Thanks in advance for any insight into this issue.

Brian Severa

The basic thing is that the user needs to update the firmware version of any device at the point of update. If the firmware version is not updated, then the system will not respond perfectly. I have faced the error of Epson 031008 because I have not updated the firmware of the system.