View Single Post
  #8   Spotlight this post!  
Unread 17-02-2013, 16:55
tuyauxtu tuyauxtu is offline
Registered User
FRC #0781 (Kinetic Knights Robotics)
Team Role: Mentor
 
Join Date: May 2010
Rookie Year: 2010
Location: Kincardine, Ontario
Posts: 22
tuyauxtu is an unknown quantity at this point
Re: VEX 393 Encoder Issues

Continuing the previous post with the Integrated Motor Encoder code:

You plug the first IME into the second (right) set of I2C pins using a jumper cable as mentioned previously. The constructor sets the digital sidecar module number, the address you want to use (there are restrictions on what is allowed), the gearing type ("speed" or "torque" which changes the ticks per revolution), and the desired termination state, true being terminated.

I set the first IME to address 0x50/un-terminated and the second to 0x52/terminated. You can see in the code the values which are allowed.

When you first plug in and power up the encoder(s), the led light(s) should be flashing orange showing that it is using the default address and is terminated.

After you run your Netbeans project, if things work, the first connected encoder should have a green flash every 3 seconds or so, and the second should double flash at about the same rate. This means the first has been readdressed and is not terminated, while the second is also readdressed but is terminated. You then read the encoders with a getRaw() for counts, a get() for degrees (wraps at 360°) and a getRevs for encoder revolutions. You can also reset the encoder to zero.

While loading the code, there should be some output messages that show the addresses and termination states as they are configured. Please note that unless you power down the encoders they will keep their last set addresses and termination states, and should still work after disabling and reenabling, as well a power cycle. You can of course comment out the messages.

We could not get the encoders to co-exist with a HiTechnic colour sensor plugged into the NXT port. It may work if the sensor connecting cable is short, but we found that that the encoders would not always read consistently with an NXT sensor plugged in.

We also found that there appears to be a wiring problem with one of the supplied cables that we are still trying to track down. These cables are now buried in the robot, so I suggest testing a harness ahead of time to attempt to preclude such a problem.

Pat