I’m curious what you mean “with their cortexes, all 3 of them.” That doesn’t even make sense.
We like the idea and ease of programming with IMEs, but had problems with the static problems that everyone read about before Worlds. It was about 1/20 times that the routine would fail, the IMEs would lock up, and we would need to do a power cycle to get everything working again.
I heard that RobotC has some sort of safeguard to prevent the problems we had in EasyC. I’ll go pull up the information from some earlier topics if I can find them.
Sure. I think we’re going to be using the full ten this year. Hopefully a bunch of people will be, too. They’re really handy. Just keep in mind, the 4-wire extension cables and 393 IMEs are more expensive than the sensors that you would have otherwise used. It does free up more slots on the Cortex’s sensor ports, though.
Bear in mind that ROBOTC only allows 8 IMEs, not sure about EasyC. As more IMEs are added the update rate for each one will be reduced, not so much of a problem for ROBOTC as it polls them around 1000 times every second, more so for EasyC as it polls them much less often.
If you have multiple motors on a lift system then I would only encode one of them with the assumption that all motors should move together.
We had lots of problems with them under RobotC, but I believe that was before the update. I believe that we had a problem with static mainly because of our robot design that greatly increased the number of problems that we had. After 2 days of attempting to get them to work we switched to quad encoders, so we didn’t give them too much of a chance. We hade consistent failures when using them. I did not write the code so it could have been that as well. If you want it to just work then I would stick with quad encoders. If you want and are able to put in the time to get them to work, then I would use the integrated encoders. I believe that most of the problems have been greatly reduced if not eliminated from the integrated encoders.