View unanswered posts | View active topics It is currently Sat Sep 19, 2020 11:53 am

Reply to topic  [ 4 posts ] 
393 IMEs not counting after rebooting Cortex 
Author Message

Joined: Wed Feb 24, 2010 11:51 pm
Posts: 31
Post 393 IMEs not counting after rebooting Cortex
I have a new Clawbot with IMEs installed on both the drive motors (all motors are 393).
I'm running RobotC v4.10. All firmware and VEXNet keys are updated.

Frequently after rebooting the Cortex, the IMEs will show the correct green status lights (they've been enumerated correctly), but they never produce any counts either forwards or backwards, either manually or under power.

If I remove power from the Cortex for up to 1 minute and try again, it can take several tries before the IMEs start working again. Once they're working, they stay working just fine until the next reboot, at which time I'm rolling the dice to get them working again.

This sounds like a problem with the RobotC firmware, but I wanted to check with the group to see what other people's experience has been.


Vex & FLL Coach and robotics instructor

Tue Jun 17, 2014 5:24 pm
Site Admin
Site Admin

Joined: Thu May 24, 2012 12:15 pm
Posts: 722
Post Re: 393 IMEs not counting after rebooting Cortex
I was not able to replicate this issue in the latest version of ROBOTC 4.10; do you have a simplified piece of sample code that demonstrates this issue (the simpler the code, the better) that you would be able to post for us to use for debugging purposes?

Check out our Blog! And our Facebook page!
Need help? Take a look at our updated help documentation and the ROBOTC Forums.

Wed Jun 25, 2014 4:38 pm

Joined: Wed Feb 24, 2010 11:51 pm
Posts: 31
Post Re: 393 IMEs not counting after rebooting Cortex
Actually, I'm not sure the code matters. Here's the procedure I used to see the problem:
1) Define two drive motors (left&right) with IME encoders and PID disabled
2) Download to the robot via the programming cable to the remote, which is linked to the robot via VEXnet 2.0
3) After download, the debug controls appear, but it's not necessary to Start the program. Just open/select the "Sensors" tab of the debugger windows.
4) Move the IME motors by hand and note whether or not the counts change.

In my case, on the first boot, the counts changed. On a series of boots following the first, the counts stayed at 0. When this happened, if I ran the program that relied on the IME counts, it would not work. My inference from this is that the numbers in the Sensor tab of the debugger are reflective of the true state of the IME driver. If the debugger doesn't see counts, then the program doesn't see them either.

I have not had an opportunity to explore this problem since I first posted my question, but I can do so later tonight and provide more details on reproducability. I've also added lights to the robot so I can display IME activity without requiring the debugger. That should help determine if the fault condition is influenced by the debugger.

I will post sample code for the display lights.


Vex & FLL Coach and robotics instructor

Thu Jun 26, 2014 11:52 am

Joined: Wed Feb 24, 2010 11:51 pm
Posts: 31
Post Re: 393 IMEs not counting after rebooting Cortex

I ran some more experiments and it looks like I was mistaken about the cause of the problem. It's not the reboot that causes it. Here's what I did...

1) Turn on robot
2) connect remote to download cable and cable to PC. At this point, the robot activated with its stored program and I could tell from the lights that the encoders were working.
3) I started RobotC, selected my program, and Downloaded to Robot.

As soon as the download finished, the debugger controls appeared. I looked at the Sensor tab and the encoders *were not working*. This happened on the very first try.

4) I clicked Start on the debugger controls and confirmed via the robot lights that the encoders really weren't working.
5) I rebooted the robot and the encoders started working again.

After several more cycles like this, I found that:
- The encoder failure (switch from working to not working) was always directly associated with downloading the program and going into debug mode.
- The failure was not consistent. In fact, the more I tried to recreate the problem, the harder it was to recreate.
- A very fast reboot (less than 1 second off) would not necessarily fix the encoders when they weren't working. A longer reboot (~8 seconds) always seemed to fix them.
- In cases where the encoders continued to work in debug mode, the Sensor tab would show any residual non-zero values from encoder motion before debug mode started.
- In cases where the encoders faulted, the Sensor tab would always show values of 0 for both encoders. These 0 values never change.

I took my larger program and stripped it down to just the bit that runs the lights. But downloading this program never triggered the fault in my testing. I'll include it below anyway so you can see how I'm using the lights to monitor the encoders. Just to be annoying, I was no longer able to reproduce the problem with the original program either despite repeated attempts.

So I'm baffled as to where the fault is occurring. Perhaps you have more insight into the switch to debug mode and how that could cause the encoders to get stuck.


#pragma config(I2C_Usage, I2C1, i2cSensors)
#pragma config(Sensor, dgtl3,  sonar,          sensorSONAR_cm)
#pragma config(Sensor, dgtl7,  rightGreen,     sensorLEDtoVCC)
#pragma config(Sensor, dgtl8,  rightRed,       sensorLEDtoVCC)
#pragma config(Sensor, dgtl10, leftGreen,      sensorLEDtoVCC)
#pragma config(Sensor, dgtl11, leftRed,        sensorLEDtoVCC)
#pragma config(Sensor, I2C_1,  leftEncoder,    sensorQuadEncoderOnI2CPort,    , AutoAssign)
#pragma config(Sensor, I2C_2,  rightEncoder,   sensorQuadEncoderOnI2CPort,    , AutoAssign)
#pragma config(Motor,  port1,           leftMotor,     tmotorVex393_HBridge, openLoop, reversed, encoderPort, I2C_1)
#pragma config(Motor,  port10,          rightMotor,    tmotorVex393_HBridge, openLoop, encoderPort, I2C_2)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

short leftEnc()
   // left motor is reversed, so need to negate left encoder
   return -SensorValue[leftEncoder];

short rightEnc()
   return SensorValue[rightEncoder];

task main()
   while (true) {
      short lEnc = leftEnc();
      short rEnc = rightEnc();

      static short lLastEnc = 0;
      static short rLastEnc = 0;

      short lChange = lEnc - lLastEnc;
      short rChange = rEnc - rLastEnc;

      lLastEnc = lEnc;
      rLastEnc = rEnc;

      SensorValue[leftGreen] = lChange > 0;
      SensorValue[leftRed] = lChange < 0;
      SensorValue[rightGreen] = rChange > 0;
      SensorValue[rightRed] = rChange < 0;


Vex & FLL Coach and robotics instructor

Thu Jun 26, 2014 9:37 pm
Display posts from previous:  Sort by  
Reply to topic   [ 4 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.