I just ordered 2 encoders. too bad i’m using easyC, i don’t get to tell the direction… but my question is, how do i spin a motor until the encoder sees 90 marks (1 full rotation) with the encoder? i’m confused…whatever i tried didn’t work. thanks, code would be appreciated. i hope my encoder isn’t broken!
Here’s some psuedo code that should get you started:
clicks = encoder1;
while(clicks < 90)
{
run motor;
clicks = encoder1;
}
dont forget that “clicks = encoder1” needs to be placed in the while loop. otherwise it will not sample the value again.
Thanks paco, fixed.
hold on, i don’t really understand. so is clicks a variable? i’m good with building and hands-on things, but when i comes to computers, well…
This may help
You don’t tell the motor to turn until the motor determines that the clicks == 90.
What Corpralchee and Paco are trying to convey is that
[LIST]
*]you tell the computer to start counting clicks.
*]you tell the computer to tell the motor to start/continue spinning
*]while the motor is spinning you continue to count clicks
*]when the click count is near 90, you tell the motor to stop turning
[/LIST]
If you hold your tongue just right, the motor will coast to a stop at exactly the same time that the click count reaches 90.
In short, you tell the motor to spin or not spin and you tell it how fast to spin.
Separately, you keep an eye on the encoder click count.
Blake
PS: In the pseudo code below, I think the “clicks = encoder1” statement should be “clicks = clicks + encoder1”. I say this because I think that most encoder output functions will supply a notification when each single “click” occurs, and won’t give you an ever-increasing, running-sum of the clicks. I might be mistaken about this part.
Thanks blake for restating that better. However I’m pretty sure that there is a way to make the encoder output how many “clicks” have passed. It’s possible that easyC does that internally but what I posted above is how we always set up the encoders.
Octannet, yes clicks is a variable.
thanks! the only problem, though, is that it works for one time only after i program it to the microcontroller, but after that the motors start spinning forever, regardless of the encoder. is there something wrong with the microcontroller’s data retention?
One thing to remember is that you have to shut the motor off after you exit the loop. So in your code after the loop you should turn the motor off. Then if you want to use the same variable again you also need to reset that variable. Something like “clicks = 0;” would do that.
hmm…that’s weird. now it only works sometimes. does the axle in the encoder have to be exactly straight? the motor and the encoder for my testing aren’t attached to any metal, it’s just the axle connected to the motor and through the hole in the encoder. maybe that’s why…
oh wait never mind, got it fixed now. it seems that the light wasn’t going through the holes poroperly and thus gave an incorrect reading, so i mounted it on a metal plate. phew! i thought those encoder were a wasted $20!
Glad you got it to work OK.
I wrote a program earlier in EasyC that runs the motor for a certain number of encoder “clicks” every time you pressed one of the buttons on the back of the remote. I think I used the top button of channel 5. I just had the program check to see if that button had been pressed and then it ran the motor until the number of encoder “clicks” was greater than the desired amount.
I’ll be glad though when they update EasyC so that we can tell which direction the encoders are turning.
i think since there are two plugs coming from the encoder, you set up two encoders in the code (really just the one) and get the value of one and multiply that by two and subtract the other by the product? i’m gonna try that, although i’m not sure how…
I don’t think that there is any way to use both sets of wires from the new encoders without having a special programming block for it in EasyC, but I could be wrong though.
The new encoders use software to tell which direction the shaft is turning. There are 2 channels that why there are 2 sets of wires. One channel is 90 degrees from the other channel and each one is a series of 0’s and 1’s. The software works by detecting which channel changes state first and that indicates which direction the shaft is turning. The software also counts the number of pulses to proivide you with the number of pulses traveled either forward or reverse.
I have tried to use 2 different encoder blocks, one for each channel, but I couldn’t figure out to write a program to accomplish this. That’s why I’m just waiting for the next EasyC update to come out.
i wish that the product list told me that the encoders needed a software other than EasyC to tell direction. rip off artists! lol jk
and also what is the maximum rpm to run the encoder for optimum performance? i think i heard somebody say on the forum a while ago that it could read 1000 rpm, but i ran a 500 rpm setup and it couldn’t get a correct reading.
If you don’t want to wait for the V2 update, you can now purchase an upgrade from V2 to easyC Pro for $50.00
easyC Pro offers quite a few features over V2. Including a Text IDE, Encoders, Gyro, CMU Camera, Labeling Ports, Improved Online Window and a bunch more.
You can try easyC Pro at easyC PRO - Intelitek
I’d also like to note that when the last version of V2 was released the new encoders had not come out yet.
Wow - that’s a great deal! The last time I checked the upgrade was $195. Just one question though - if I upgrade to EasyC Pro, will it be updated later when the new VEX products are released just like EasyC 2?
All the “future” products are already supported in easyC Pro except the LCD.
I know that we have kind of gotten off the topic, but thanks for the information.
I knew that EasyC Pro had a block for a Gyro, but I didn’t know if it would work with the new VEX one or not. I assume that there would be an update then when the LCD comes out?