IMEs Becoming Unresponsive

I have been having issues with unresponsive IMEs recently. I know of the static issue that is present with them but this isn’t matching that as far as I have learnt.

Sometimes when running and testing our robot the IMEs stop working. By this I mean the last value they held before they break stays constant. The lights on them keep flashing green and the variables are still present. They are initialized properly. It shouldn’t be static since the cortex did not revert to its firmware. it remained responsive and ran my code. The IMEs were the only thing that stopped working. Any ideas?

Jake

Sounds like standard behavior for EasyC, I know I post a lot but sometimes it feels like a total waste of time if no one reads them. If you are on ROBOTC then have you upgraded to V3.60?

Take a look at this thread.

https://vexforum.com/t/ime-technical-description-and-software-workarounds/23218/1

and this one.

https://vexforum.com/t/esd-my-thoughts/23332/1

They are more specific to ROBOTC but the principles apply to EasyC as well.

If an IME resets due to static (or any other reason like a lose cable), EasyC does not reset the I2C bus and you are left with frozen encoder counts.

I have yet to go through the links in detail but they look very interesting. where do you post these? i love the detail put into them and my team and myself would love to go through them.

we are on robotc v3.54
upgrading at this point might not be an option but if 3.6 wil help the problem i can have some members test it out on another robot.

what is the difference between the static you are suggesting here and the static that causes the cortex to revert to firmware?

We had similar issues and ended up going back to regular encoders just because they always seem to work. I realize this may not be an option for you, but if you can would switch. Our autonomous has become much more reliable.

thank you for the suggestion but unfortuneately with the current build of the base and the current time constraints that change cannot be made. if we had a couple more weeks we might have tried that. thank you for the idea

Jake

My post from Monday was probably not very helpful, it’s just that I though that so much has been said about the IMEs that everything would now be clear, I guess not.

IME encoder counts seen by user code will freeze if IME communication is lost, this applies to both EasyC and ROBOTC, there is no dispute here, it is a fact. Communication can be lost for a number of reasons, the most likely is an intermittent or bad cable, but others include corrupted messages or ESD causing the IME to reset.

If communication is lost and encoder counts freeze, ROBOTC will try and re-establish communication again, if this is successful the encoder counts will reset to 0. ROBOTC V3.60 was improved so that communication is less likely to be lost. It was also improved so that if communication is lost then it is more likely to be able to recover (although counts will still go to 0) and provides a mechanism for the user code to be able to monitor IME link status. I highly recommend upgrading. EasyC currently will not try and re-establish communication (as of V4.1.0.5).

You didn’t say how many IMEs you have, however, I would replace the cable between the cortex and the first IME. Make sure that the cables are pushed all the way into the IME, this can be quite hard on some of them. Try and avoid running the IME cables alongside the motor cables, I have no evidence to suggest that motor pwm signals are causing crosstalk but if you can avoid it then do so. Avoid having the cables loose and moving around, zip tie them to structure, try and avoid any movement of the cable at the cortex end and make sure it comes out of the cortex vertically and not at some crazy angle because a cable is too short or something like that.

If none of the above helps then I would replace the first IME/motor and see if that improves things. A student showed me an IME at one competition that was all chewed up for some reason, perhaps you have one that is damaged internally.

Let us know if you solve the problem.

Thanks for the help, sorry I haven’t seen your other posts. I am still new to the forums and haven’t found my way around it all yet.

We will definitely try 3.6 because this is a big issue for us.

To give you a bit more info on our robot, there are 4 IMEs all on the base of our bot. keeping the wires aways from the pwm cables might be tricky since all wires are held back underneath the robot but we will do our best. We had the cortex end of the wire tied back so it was bent a bit. we will change this as well. If we are looking to replace the IME as you said, should we only do the first one in the chain?

Thanks for the help

Due to the way the I2C daisy chain works, if the first IME has an issue then it can stop communication with all IMEs. As you have said that the encoder count freezes on all IMEs, then the first one is the most likely to have the problem. Please understand that identifying this type of problem can be hard and swapping out any one part only has a small chance of success. Do your best with the cables but don’t stress over it too much. My own demo robot also has four IMEs on the drive and it’s almost unavoidable to have the IME cables near the motor cables.

[ATTACH]7366[/ATTACH]
osr_base.jpg

Thanks for the info. we will do our best to follow those guidelines with our robot base.

If width is the issue with adding the quadratures to your base you can do something like this.

http://sbdrobotics.com/wp-content/uploads/2013/04/photo-1.jpg

interesting mount :slight_smile: do you mind if i borrow the picture to show my team? thanks for the help

By all means, were happy to help!