Yea, I think I noticed that last night. Let me have a look into that as well. I really don’t use PROS much (for obvious reasons) so I forget what works and what doesn’t.
Here is some quick code I wrote to demonstrate what I meant in the last post:
int encLoadingTime = 0;
do {
numEncs = imeInitializeAll();
lcdPrint(LCD_PORT, 1, "%d Encs Found", numEncs);
lcdPrint(LCD_PORT, 2, "Enc Init #: %d", (encLoadingTime + 1) / 10);
encLoadingTime += 10;
delay(10);
} while (encLoadingTime < 3000 && numEncs != NUM_ENCODERS);Would this work or is there a better solution when encoders aren’t initializing?
The code will theoretically do what you want, that is, try and initialize the encoders if the correct number doesn’t show up. You may want to delay by a little longer between retries, perhaps 50mS.
I did another test and found that from power up the IMEs initialized every time so perhaps the root cause of your problem is something else, most likely a bad cable or intermittent connection. Perhaps check all of those first. I think the problem I had last night only happened when the cortex was rebooted when already on. When they don’t initialize, how many are lost? Do any of the IMEs have the orange led on still when that happens? If so, check the connections at that IME first, the plugs can be hard to push in all the way sometimes. Also there were some issues with early cortexes IIRC, the ones with NC1 or NC2 (??) as the rev underneath, perhaps check that as well if you can (they also do not have the raised VEXnet key, a completely flat top surface).
When I said the IMEs don’t initialize, I meant that we always have 0 initialized, it’s never just a few that initialize. When they don’t initialize, their LEDs are all orange, so it’s not that we have a loose connection (we spent a too long trying to shove them in to get it wrong :D). I cannot check the cortex at the moment, but this cortex is relatively new and I believe it does have a raised VEXnet key (it’s about two years old).
Ok, didn’t expect that unless the first one is intermittent. You could always replace the cable from the cortex to the first one and see if that makes any difference.
Sound like an A3 or A4 unit, that’s the latest as far as I know, same as mine.
Alright jpearman, we’ll check the wire connecting the Cortex to the first encoder later today.
jpearman,
We’re now experiencing an issue where imeInitializeAll() is hanging in our initialize() function.
What do we do? It’s not returning out of the function.
We’re also having issues where the encoders just drop out randomly (LEDs turn yellow).
You need to try and simplify everything so you can figure out what the problem is.
-
Is the battery good. Many problems are caused by bad batteries.
-
Create a new project and add a minimal amount of code, do something simple like initialize the IMEs and show their values on the LCD, something like that. The idea is to try and isolate the problem to your code or the hardware.
-
Simplify the hardware, does the problem happen with no IMEs connected, one IME etc. Is a particular IME or cable causing a problem.
-
Do you have access to another cortex you can try the same simple tests on.
It’s usually best to assume the problem is something simple and gradually eliminate these before moving onto things which are more complex.
Let me know what you find out. For what it’s worth, the code you sent me earlier in the week seemed pretty stable when running on one of my systems.
Thanks jpearman, this seems to have fixed the issues (surprisingly). The IMEs initialize every single time on the first try and the connection seems stable. Thank you so much again.
Yours,
sli908
Glad you found the root cause. Good luck.
We’ve now been having some issues with VEXnet disconnection when the IMEs are initialized. Any idea on how to resolve that?
The two things should be completely unrelated, the code for VEXnet is running on a different cpu. Can you describe what happens in more detail?
Never mind, we traced the issue back to something else. Thank you for your help again.
We’re having issues with the encoder again 
They’re randomly disconnecting while running. They always initialize and work for about a minute and then they return 0. However, they’re still blinking green as they were when they were working, so it’s not a wire that’s coming disconnected.
The IMEs have a bad reputation, many users have had issues over the years and we (myself, the ROBOTC developers and presumably the VEX engineers) spent a lot of time debugging issues in 2012 and 2013. ROBOTC implemented some improvements that helped significantly with reliability, I made some effort with ConVEX but probably didn’t go as far as the ROBOTC developers in considering boundary conditions and handling errors. I have no idea what the PROS team did, however, I do know that they are pushing the communication to the IMEs a little harder than everyone else (ie. higher clock speeds, more I2C traffic). We do know that static can cause the cpu inside the IME to reset, when this happens the count will go back to 0. I created some code for ROBOTC that could flywheel over this problem, I never did implement for ConVEX but the concept would be the same, you can read about that and some of the reasons why IMEs reset to 0 in this thread.
We had a “manual reset” button last year to force the arm down at -127 power and then reset the 0 back at the bottom. That way if your encoders reset during a match at least you can recover.
If I were debugging this problem, this is what I would do.
- Simplify the PROS program, driver control only, do the encoders reset?
- Switch to another programming environment (probably ROBOTC), try the same thing, do the encoders still reset?
If they reset in both cases then the problem is electro/mechanical (ie. static, bad cable or bad IME). If the simple PROS code doesn’t cause reset then there’s something else in you code that causes a probem (for example, I really didn’t like the way you constantly call resetEncoders() ). If ROBOTC works and PROS doesn’t, well, it’s the low level I2C code.