encoders

[stephenthe1]

I'm posting this in hope that someone who has actually registered on this site will post something. there are so many people viewing this, but not posting anything. with that said, I thought this would be a nice place for people to discuss encoders. of course, my main motivation is that these things have been my killing me over the past month. I have tried numerous things, and I can never seem to get it to work. Coding, for the most part, I don't think is a problem. I'm using 2004's code written by Mr. Watson that supports encoders and interrupts. I have everything configured, the only thing that could possible be keeping the encoder from working is my code in User_Routines_Fast.c
what the code does is this, when the third joystick is pushed forward, the arm on last year's robot goes up untill the encoder has "clicked" 12 times. then the motor on the arm is set to neutral. it's as simple as that. (for testing purposes).


static long lec = 0; //lec = encoder count
lec = lec + Get_Left_Encoder_Count(); //add previous count
//plus the new count
//the static long is supposed to hold the value every loop
if (lec >= 12)
{
pwm02 = 127; //set it to neutral
}
else
{
pwm02 = p3_y;
}


can you please tell me why this won't work, or if you think it should. please tell me yourself and don't refer me to somewhere. I've spent so much time, and a simple few lines of code would help me to understand this almost completely. (don't forget, Mr. Watson's 2004 encoder code is what I'm using.)

HELP!!!
thanks,
Stephen :yikes:

[seanwitte]

What does the robot do when you move the joystick? Have you tried turning the encoder by hand and printing the value of lec to make sure its being incremented correctly?

Since the call to Get_Left_Encoder_Count() does not reset the internal value, your local variable (lec) will saturate very quickly. Once the encoder moves one tick it will increment lec over 12 almost instantly. You either need to reset the value to 0 or use Get_Left_Encoder_Count() on its own as your counter.

if (Get_Left_Encoder_Count() >= 12)
{
pwm02 = 127;
}
{
pwm02 = p3_y;
}

[stephenthe1]

What does the robot do when you move the joystick? Have you tried turning the encoder by hand and printing the value of lec to make sure its being incremented correctly?

Since the call to Get_Left_Encoder_Count() does not reset the internal value, your local variable (lec) will saturate very quickly. Once the encoder moves one tick it will increment lec over 12 almost instantly. You either need to reset the value to 0 or use Get_Left_Encoder_Count() on its own as your counter.


do you mean set the "Get_Left_Encoder_Count()" function variable to 0? so your saying that Get_Left_Encoder_Count()" function variable holds its value every time it interrupts, even if I call it once and then call it again. that is definitely what Mr. Watson seems to have stated in his code. that makes sense, though I don't see how it holds the total value every time it interrupts without being declared as static.

[seanwitte]

do you mean set the "Get_Left_Encoder_Count()" function variable to 0? so your saying that Get_Left_Encoder_Count()" function variable holds its value every time it interrupts, even if I call it once and then call it again. that is definitely what Mr. Watson seems to have stated in his code. that makes sense, though I don't see how it holds the total value every time it interrupts without being declared as static.

Get_Left_Encoder_Count() is a function that interacts with a static variable in encoder.c named Left_Encoder_Count. Since Left_Encoder_Count is not exposed by encoder.h you can only get the value using the supplied function, Get_Left_Encoder_Count(). To change its value use the function Set_Left_Encoder_Count().

[Tom Bottiglieri]

Since the encoder may have ticked before you hit this block of code, you may want to do something like this.


//define a variable outside the loop called 'temp1'

if(temp1==0)
{
temp1=Get_Left_Encoder_Count();
}

static long lec = Get_Left_Encoder_Count() - temp1;

if (lec >= 12)
{
pwm02 = 127; //set it to neutral
}
else
{
pwm02 = p3_y;
}

[stephenthe1]

how do I turn on the compressor in the 2004 default code? thanks. (though I'll be using it in Mr. Watson's 2004 encoder code).

[Tom Bottiglieri]

Hook up your compressor to a spike, so that the red lead is attached to the M+ output and so that the black lead is connected to your ground junction. In your code, turn that relay on and off.

So, if you used relay1, the code would look something like this..

void TurnOnComp(void)
{
relay1_fwd=1;
}

void TurnOffComp(void)
{
relay1_fwd=0;
}

[stephenthe1]

um, where do I put those functions at? (which file)

[stephenthe1]

ok, our compressor is hooked up to digital 17. from last year's white sheet with the different wires labeled, it says that the sensor for the relay is hooked up to analog 1. I'm new to the compressor stuff. Is this all of what you need to write the code for it? It is hooked up to a spike. unless this is hard, could you show me the code for this, and tell me where to put it. That would allow me to learn from it as I get confused easily when I have to write things on my own without experience. as soon as you can is best, as I'm at a robotics meeting right now.
thank you for your help,
Stephen

[cbolin]

Stephen,
Regarding your first code posting
static long lec = 0; //lec = encoder count

Did someone explain that if you initialize "lec" every time this function is called, it will always be zerod? You could get rid of the 'lec = 0'...that way it would always remember the last value (which is what you were trying to do).

If you already figured this out or I missed this in the above response...just ignore what I said. :-)

Regards,
ChuckB

[Greg Ross]

Stephen,
Regarding your first code posting
static long lec = 0; //lec = encoder count
Did someone explain that if you initialize "lec" every time this function is called, it will always be zerod? You could get rid of the 'lec = 0'...that way it would always remember the last value (which is what you were trying to do).
Actually, Chuck, because lec is declared static, it will only be initialized once, not every time the function is called.

[CJO]

On the compressor, I would do something like this:

"if (p1_wheel => 127)
{
relay1_fwd = 1
)
else
{
relay1_fwd = 0
)
"

The setup should be as follows:

You should have a joystick connected to port 1. You should have a spike sonnected to relay port 1.

When you rotate the throttle (the big wheel) on the joystick away from you all the way the compressor will turn on, otherwise, the compressor will not turn on.

[Greg Ross]

What does the robot do when you move the joystick?
Stephen,

We're still looking for a description of the symptoms. (I asked too in the "What do you think about how easy theyre making programming?" thread.) All you've told us so far is that "the encoder doesn't work."

Have you tried what Sean suggested?:
Have you tried turning the encoder by hand and printing the value of lec to make sure its being incremented correctly?

You mention you're using Kevin's 2004 encoder code. The version I have has a fairly complete read-me file included in the .zip file. Have you read it? If you don't have the read-me, maybe you should get Kevin's latest version, and use it instead of the old one.

[stephenthe1]

thanks guys. actually, I found out in this thread that the Get_Left_Encoder_Count() function sends its returned value to the "Left_Encoder_Count" variable, which IS static. therefore I don't need the (poorly named) "lec" (left encoder count, but left count is being used for the arm this time, with the tick delta set to +1).

however, all I need for the compressor is to turn it on, but thanks for the wheel idea, as I'll try that out. It'll make testing more practical. thanks again!

[seanwitte]

thanks guys. actually, I found out in this thread that the Get_Left_Encoder_Count() function sends its returned value to the "Left_Encoder_Count" variable, which IS static. therefore I don't need the (poorly named) "lec" (left encoder count, but left count is being used for the arm this time, with the tick delta set to +1).
however, all I need for the compressor is to turn it on, but thanks for the wheel idea, as I'll try that out. It'll make testing more practical. thanks again!

Don't use the wheel input to control the compressor! The pressure switch output is open (0) when the pressure drops below a threshold, then closes (1)when it hits 120 psi. It stays closed (1) until the pressure drops below the threshold again. That means there is no logic involved in turning the compressor on and off, just grab the value from the switch. Its right there in Default_Routine(). The compressor is connected to relay 8 and the pressure switch to digital input 18:


relay8_fwd = !rc_dig_in18; /* Power pump only if pressure switch is off. */
relay8_rev = 0;

[stephenthe1]

is that already in the default routine, because our compressor doesn't automatically turn itself on. plus, if you read my above post, are you sure the default settings work with the way my bot is configured? thank you.

[gnormhurst]

I have some vague recollection that you may not pass inspection if you do not have the pressure limit switch controlling the compressor.

Last year we were overweight and removed our compressor, opting instead to charge the air tanks before each match.

[thoughtful]

Sorry if this is a bit off topic.

I was looking through the encoder the Mr.Kevin provides on his website. I did not find the model of the encoder he was using, i am currently wanting to use optical encoder from digikey there a lot of them available. I am trying to decide which one to buy and will the optical encoder just tick when the dark area changed to light?

Thank you in advance

[Anthony Kesich]

I have some vague recollection that you may not pass inspection if you do not have the pressure limit switch controlling the compressor.

Last year we were overweight and removed our compressor, opting instead to charge the air tanks before each match.
I believe it is the pressure blow off valve that cannot be removed, not the pressure sensor. In 2003, we ran without a sensor. That's where CJO got the code from. We used the wheel since we didnt have any more buttons on the controller to map the function to. We controlled it manually since we were having power regulation problems and decided to kill the compressor completely for the last 30-45 seconds of the match.

-Tony K

[Kevin Watson]

...I was looking through the encoder the Mr.Kevin provides on his website. I did not find the model of the encoder he was using...
From the readme.txt: "This software was tested with Grayhill 63R256
and 61K128 quadrature output optical encoders. Data sheets for
these devices are included."

-Kevin

[CJO]

As Anthony points out. If you have power to burn, leave the compressor in full auto, if, on the other hand, you want manual control (for any one of a number of reasons) I think that the wheel is a good choice, as it is convienient, and hard to press by accident.

[stephenthe1]

We're still looking for a description of the symptoms.
actually, our encoder does work, it's just a matter of finding if the code works or not. if not, then there is an encoder problem. however, I checked the wiring. I heard there's a way to see every time it clicks on the laptop. how's this done? also, yes, I've gone over the read me.

[Greg Ross]

actually, our encoder does work, it's just a matter of finding if the code works or not. if not, then there is an encoder problem. however, I checked the wiring. I heard there's a way to see every time it clicks on the laptop. how's this done? also, yes, I've gone over the read me.
Here's what I would do to verify that your encoder is working: In the routine where you are controlling the arm, add the following code:

int tempEncoder;
static int prevEncoder = 0;
...
tempEncoder = Get_Left_Encoder_Count();
if (tempEncoder != prevEncoder) {
printf("%d ", tempEncoder);
prevEncoder = tempEncoder;
}

[stephenthe1]

Here's what I would do to verify that your encoder is working: In the routine where you are controlling the arm, add the following code:

int tempEncoder;
static int prevEncoder = 0;
...
tempEncoder = Get_Left_Encoder_Count();
if (tempEncoder != prevEncoder) {
printf("%d ", tempEncoder);
prevEncoder = tempEncoder;
}


which screen will it print to when running the program? I know in the link cable program thing to download the (ifi loader) program, there's a little screen.
is it in that?
that would be hard to trace, because it prints out hundreds of lines, and there isn't a way to print or save it to a file for viewing. guess I can search it. thanks!

also, I don't know if it matters, but what are the three "..." periods for after the previous static encoder.

[stephenthe1]

also, it says there's an error on this line when I put it in user routines fast.
int tempEncoder;

what's up with that?

[Greg Ross]

which screen will it print to when running the program? I know in the link cable program thing to download the (ifi loader) program, there's a little screen.
is it in that?
Yes. that's where you'll see the output.

that would be hard to trace, because it prints out hundreds of lines, and there isn't a way to print or save it to a file for viewing. guess I can search it. thanks!
That's why my code only prints the encoder value when it changes. It will still move pretty fast when the encoder is turned, but it will stop when the encoder stops. Also in order to keep as much of the data on screen as possible, I intentionally didn't print a newline.

also, I don't know if it matters, but what are the three "..." periods for after the previous static encoder.
Those were just intended to show that there were lines omitted.

also, it says there's an error on this line when I put it in user routines fast.
int tempEncoder;

what's up with that?
Sorry. I guess I could have been a little more specific. The first two lines need to go at the beginning of the function. In C (unlike in C++), data definitions must appear before any executable statements in a function.

Leave out the ellipsis (the "..."), and then put the rest of the code just before the arm control code.

[stephenthe1]

the encoder is working!!! thanks for the help in this thread. I'm still looking at our compressor, though it's not a pain to enable, just that they have it wired oddly. thanks again!

[Greg Ross]

the encoder is working!!! thanks for the help in this thread. I'm still looking at our compressor, though it's not a pain to enable, just that they have it wired oddly. thanks again!
Congratulations! Does that mean the arm is working too?

Earlier, you said
ok, our compressor is hooked up to digital 17. from last year's white sheet with the different wires labeled, it says that the sensor for the relay is hooked up to analog 1. I'm new to the compressor stuff. Is this all of what you need to write the code for it? It is hooked up to a spike. unless this is hard, could you show me the code for this, and tell me where to put it. That would allow me to learn from it as I get confused easily when I have to write things on my own without experience. as soon as you can is best, as I'm at a robotics meeting right now.
thank you for your help,
Stephen
Did you mean the compressor is on relay 17? And did you really mean analog 1 for the pressure switch? If so, is it the pressure transducer (an analog pressure sensor) or the (digital) pressure switch?

The default code expects the compressor to be on relay 8, and the pressure switch on digital 18. If you hook up your compressor and pressure switch this way, you're golden. These lines in Default_Routine() in user_routines.c will take care of the compressor:

relay8_fwd = !rc_dig_in18; /* Power pump only if pressure switch is off. */
relay8_rev = 0;


If you really are using the pressure transducer, and you want to leave the compressor on PWM 17, you will need to add some code that I'm not prepared to help you with right now, since we haven't used any analog inputs on the robot since we have gotten the new controllers.

BTW, I think that last year, the ruling was made that even if you want to use the pressure transducer, you still have to have the digital pressure switch. If this is the case (and you still want to leave your compressor on relay 17), you will need to change the line in Default_Routine() to
relay17_fwd = !rc_dig_in18; /* Power pump only if pressure switch is off. */
relay8_rev = 0;

(Change rc_dig_in18, if necessary, to whatever digital input you connect your pressure switch to.)

[roboticsjenkins]

On getting the Phase A/ Phase B hookup on the encoder. Do i need to splice the wires. Do i have just one pwm for each encoder or two? Please Help....

[Alan Anderson]

On getting the Phase A/ Phase B hookup on the encoder. Do i need to splice the wires. Do i have just one pwm for each encoder or two? Please Help....
Encoder signals go to digital inputs on the RC, not to pwms. Quadrature encoders require power and ground, and they provide two digital signals.

If you're using interrupts, you're pretty much required to use the first two digital inputs for the "A" phase outputs of two encoders, with the "B" phase outputs on two other digital inputs.

[dmurdz]

Im working on my programming, when it comes to my code I do not know how to set up my interrupt handlers, is there demo code some where for this???

[Alan Anderson]

Im working on my programming, when it comes to my code I do not know how to set up my interrupt handlers, is there demo code some where for this???
See http://www.kevin.org/frc/ for lots of example programs, many of which are complete drop-in modules. Scroll down to frc_encoder.zip for interrupt-based encoder code.

[dmurdz]

Sample code from Kevin on www.kevin.org/frc, the interrupts program, in file interrupts.c, there is a spot that says:

/************************************************** *****************************
*
* FUNCTION: Int_3_Handler()
*
* PURPOSE: If enabled, the interrupt 3 handler is called when the
* interrupt 3/digital input 3 pin changes logic level.
*
* CALLED FROM: user_routines_fast.c/InterruptHandlerLow()
*
* PARAMETERS: RB4_State is the current logic level of the
* interrupt 3 pin.
*
* RETURNS: Nothing
*
* COMMENTS: The PIC18F8520's RB4/KBI0 pin on port b is mapped to
* interrupt 3 on the EDU-RC and digital input 3 on the
* FRC-RC [108].
*
************************************************** *****************************/
void Int_3_Handler(unsigned char RB4_State)
{
// this function will be called when an interrupt 3 occurs
}

Is this the final code??? What do I need to add???

HELP!!!!!!!!!!!!!!!!

[Kevin Watson]

Is this the final code??? What do I need to add???
It's just template code that shows you how to setup the interrupts. Check out some of the other examples that show you what you can do with interrupts.

-Kevin

[dmurdz]

where can I find the other examples for interrupts?

[roboticsjenkins]

How do I hook up th encoders to the RC. I know that they go on Digital I/O, but do I use two PWM CABLES to hook each encoder up or what do I do? Someone please help me.

[stephenthe1]

ok, I'm assuming you have a quadrature encoder (this means there are 4 places to hook up wires on the encoder). 1 is the + power pin. 1 is the - (ground) pin. one is the phase -a pin, and one is the phase b pin. this requires two digital ports on the rc. I'm assuming you are using Kevin watson's encoder template (the only way to do this if your a beginner). hook up the +, -, and phase a wires on the digital io 1. then put the phase b wire on digital io (I think, but check the template read me provided b Mr. Watson) on digital io 6. this is how the "left" motor encoder, or w/e our using it for is hooked up.

don't feel too bad, I had this same problem about a month ago, I started a couple threads before I was able to understand it.

hope this helps,
Stephen

[roboticsjenkins]

Let me see if I have this right I have to hook one encoder to two different Digital I/O ports?...I'm so confused

[stephenthe1]

ok here it is, and yes, one encoder to two digital IO's. did you read what I said carefully? um, check to see if there are four pins on the encoder, if there are, then you need two digital ios. here-

dig. io 1 ------- phase a pin ------- positive power --------negative power

dig. io 6 ------- phase b pin (only, no power or anything here)

if this doesn't make sense, then you really need to go to the white papers section and read up on interrupts a little and on encoders, and read through the comments on mr. Watson's code. questions are fine, but really, after reading this, you shouldn't be having any problems.

[stephenthe1]

(didn't mean to sound mad ;) ) came out that way I guess

[dmurdz]

Is it possible to change these pins if you adjust the code???

[Kevin Watson]

Is it possible to change these pins if you adjust the code???The phase-A signals must be tied to an interrupt. The phase-B signals can be tied to any digital input. See encoder.h for directions.

-Kevin

[dmurdz]

The phase-A signals must be tied to an interrupt. The phase-B signals can be tied to any digital input. See encoder.h for directions.

-Kevin


What do you mean " phase-A signals must be tied to an interrupt", can i hook them up to digital i/o pins 3-6???

[Alan Anderson]

What do you mean " phase-A signals must be tied to an interrupt", can i hook them up to digital i/o pins 3-6???
One of the two phases of the encoder needs to be able to interrupt the processor. Putting it on pin 1 or pin 2 makes that easy, with each pin causing its own interrupt upon the desired edge of the connected signal. Using pins 3-6 complicates the software quite a bit, because those pins all cause the same physical interrupt no matter which pin changed, and no matter which direction the signal transition went. You can still do it (in fact, you have to do it if you're using more than two encoders), but you need to know which bits of PortB mean what, and you need to do your own software filtering of signal transition direction. It takes a lot more work to do it that way rather than letting the RC hardware do it for you.

[stephenthe1]

I would suggest, especially Mr. Watson has it set up this way, putting the phase a's on 1-6, and b's on any other pins. Unless you can't already figure the direction your going, it won't be important to inerrupt the phase b's.

[Workaphobia]

I've got a few encoder questions. I'm trying to decide whether or not to spend $100 of my team's money on Greyhill optical quadrature encoders, when the kit already includes HAL-effect sensors. Things are beginning to look bleak in terms of the amount of time we have until ship-date, and it'll be hard enough finding someone in the construction section of the team to mount any sensor as it is.

First, I understand that quadrature encoders can detect direction, and that in addition optical encoders are more reliable, but would this high-end technology really be useful for a team that just needs to reliably determine how far the bot has traveled (or turned)?

Second, will Kevin's code work with non-quadrature encoders? I assume it wouldn't - in that case, is it difficult to write my own code to interface with them, or is it as simple as reading an input?

Third, is it possible to use encoders without interrupts, and just poll how many clicks have elapsed, or would polling only return whether or not it is currently clicked?

Thanks.

[stephenthe1]

well, it shouldn't be too much a pain to change his code to use the regular encoders. polling would only tell whether it's currenlty clicked or not. I've tried doing that and I always got messed up measurements, because it's random when it records a tick. therefore, no matter the speed of the shaft, I would suggest using interrupts always.

[stephenthe1]

if anyone has time, I would greatly appreciate it if you could upload the new compiler that Microchip temporarily released for free for me. I had it, but it's walked off to magical places. just let me know where you uploaded it to. or try Emailing it to me. idk what the max. file size limit is for my Email. or if Microchip hasn't taken the ftp link away yet, tell me the link, cause I couldn't find it. thank you a bunch.

[Joe Ross]

Second, will Kevin's code work with non-quadrature encoders? I assume it wouldn't - in that case, is it difficult to write my own code to interface with them, or is it as simple as reading an input?

Third, is it possible to use encoders without interrupts, and just poll how many clicks have elapsed, or would polling only return whether or not it is currently clicked?

Kevin's code will work with non-quadrature encoders, as long as you don't hook anything else up to digital inputs 6 or 8. It will only count in one direction, though. You could remove the parts of his code that deal with quadrature fairly easily.

You can handle encoders without interrupts, as long as they tick slowly. If you can guarantee that you poll the pin at twice the rate it transitions, you would be able to poll it reliably.

[stephenthe1]

You can handle encoders without interrupts, as long as they tick slowly. If you can guarantee that you poll the pin at twice the rate it transitions, you would be able to poll it reliably.

just thinking, if you poll it at twice the rate it transitions, chances are you will get more ticks than actually occur with the encoder.

[Ssbfalcon]

Based on what I see, interupts would be more reliable. However, assuming that the reliability of each method are equal, what are the pros and cons of polling and interupts, besides code complexity?

[stephenthe1]

Based on what I see, interupts would be more reliable. However, assuming that the reliability of each method are equal, what are the pros and cons of polling and interupts, besides code complexity?

polling= slow roation only, less reliability overall, I'm not sure, but possibly unnecessary strain on the processor (but I doubt it), won't be prepared for using encoders in the future with interrupts on drive shafts, etc. adv. easy coding like you said.

interrupts=every advantage you could imagine, except tough coding. this is why Mr. Watson wrote code to handle encoders with interrupts, it's truly a wonderful thing he has made. go to www.kevin.org and scroll down to the robotics link, and look for frc encoders template. It's what I used to learn about encoders and interrupts, and it is so easy to use because all the work is already done pretty much. though I wish he would consider setting up a third encoder interrupt as well, but what he has is awesome.

[Greg Ross]

if you poll it at twice the rate it transitions, chances are you will get more ticks than actually occur with the encoder.
No. You don't count a tick if the pin state hasn't changed since the last time you polled it.

[stephenthe1]

if the pin state hasn't changed, how does it know to not make another tick count? is there a flag, kind of like interrupts that must be cleared before you can register another tick? if so, that's pretty neat.

[stephenthe1]

can somebody please send me a copy of the new compiler? ( stephen51@safe-t.net ) thanks in advance.

[Kevin Watson]

if the pin state hasn't changed, how does it know to not make another tick count? is there a flag, kind of like interrupts that must be cleared before you can register another tick? if so, that's pretty neat.
This is what state variables are for. As an example:


// assumptions:
// left encoder phase-A signal goes to rc_dig_in01
// left encoder phase-B signal goes to rc_dig_in06
// right encoder phase-A signal goes to rc_dig_in02
// right encoder phase-B signal goes to rc_dig_in08

static long left_encoder_count = 0;
static long right_encoder_count = 0;
static unsigned char prior_left_phase_a_state = 0;
static unsigned char prior_right_phase_a_state = 0;

// look for a rising edge on left phase A
if(rc_dig_in01 != prior_left_phase_a_state && rc_dig_in01 != 0)
{
// get direction information from left phase B
if(rc_dig_in06 != 0)
{
left_encoder_count++;
}
else
{
left_encoder_count--;
}
}

// look for a rising edge on right phase A
if(rc_dig_in02 != prior_right_phase_a_state && rc_dig_in02 != 0)
{
// get direction information from right phase B
if(rc_dig_in08 != 0)
{
right_encoder_count++;
}
else
{
right_encoder_count--;
}
}

// update state variables
prior_left_phase_a_state = rc_dig_in01;
prior_right_phase_a_state = rc_dig_in02;


Placed in the fast loop, this code will emulate the interrupt-driven code.

-Kevin

[Mike Betts]

can somebody please send me a copy of the new compiler? ( stephen51@safe-t.net ) thanks in advance.
Stephen,

That would be illegal (copyright laws and all of that...). As they had announced at the kickoff, the V2.4 download was available for 2 weeks only and you had to link to it via the FIRST site. Now they have shut it down, as promised.

Please have your main team contact phone FIRST and they will send you a CD.

Mike

[Workaphobia]

It suddenly occurred to me that the encoders can be reused for next year's competition, so I told my adviser to go ahead with the order. I guess I'll take another look through the readme for the encoder module and prepare to implement some autonomous driving functionality.

[stephenthe1]

I think I found our copy. and I would have to say that I disagree about it being illegal. if I purchased (or in this case got it free) a cd, and simply broke it somehow, I wouldn't be cheating the business by getting a copy from someone else, because I already paid for thir product. anyway, is the newest compiler on the disk that came with the kit this year? just to be sure. thanks

[Mark McLeod]

anyway, is the newest compiler on the disk that came with the kit this year? just to be sure. thanks
No it is not. The new compiler wasn't available until after the KOP CD was made.

[Mike Betts]

I think I found our copy. and I would have to say that I disagree about it being illegal. if I purchased (or in this case got it free) a cd, and simply broke it somehow, I wouldn't be cheating the business by getting a copy from someone else, because I already paid for thir product. anyway, is the newest compiler on the disk that came with the kit this year? just to be sure. thanks
Stephen,

To echo what Mark just posted, the CD you got in the kit is V2.2

V2.4 has not been released yet. You can not buy it or download it. Microchip has graciously offered to let FIRST team members use a beta version. I would imagine that, if their trust in us is broken and they find these beta versions being used for anything other than FIRST robots, they would think twice about future donations.

What this means is that future teams would have to spend $495.00 per seat of software to participate in FIRST.

Bottom line, please do not treat this topic lightly. Our actions always have consequences.

Please have your main team contact phone FIRST to get a CD.

Regards,

Mike

[about_abot]

[I would imagine that, if their trust in us is broken and they find these beta versions being used for anything other than FIRST robots, they would think twice about future donations.]

Folks, everything is okay. Wow, this thread got way off topic. :)

Having worked very closely with Stephen over the last month, I have gotten to know him very well. His inquiry over the C compiler is quite innocent and justly asked. If someone believes it to be a malicous act to inquire about a tool that is supplied by a vendor in an agreement with FIRST, then please direct your admonition to the team's teacher/leader. The students are here to learn the science of robotics. They do not need to feel someone's fire for something they do not have experience handling.

This forum is to provide technical knowledge and stimulate interest for the students. I believe we still are under the gracious professionalism invoked by the FIRST rules of the game articulated at the kickoff.

I will give Stephen a copy of the C 18 2.4 compiler. His compiler got destroyed by an erratic computer believing it was an all consuming shark, not as a friendly programming tool. I have kept a copy of the download on another unit believing that something like this would happen.

[Bottom line, please do not treat this topic lightly. Our actions always have consequences.]

Mike I do appreciate your input, but please do not judge Stephen too harshly. He is a hardworking student with a tenacious talent. When he left our lab last night, I did not get a chance to supply him with a fresh copy of the compiler. He will, though, receive it within the next couple of days.

If anyone feels the need to continue discussing the ramifications of violating a vendor or FIRST rule, please start a new thread. I really like the discussion about encoders on this one. :-)

Respectfully,

Gary Dettmers
1008 Engineering/Programming Mentor