heres what i get:
Clean: Deleting intermediary and output files.
Couldn’t locate build tool. Check tool locations.
BUILD FAILED: Fri Nov 09 17:10:01 2007
i looked for the build tool but i cant figure it out. i just got a new laptop and i had mplab on my old laptop that broke. and it was working find i did the programming for 2006 on that computer. could it be that vista is causing the problem. any ideas?
MPLAB works fine for me on Windows Vista Home Premium. Did you install the C18 compiler?
i might not have do you have a link to the c 18 compiler because i got it off of the microchip website. i can reinstall it.
The C18 compiler is the software that your team received in the KOP. You cannot simply download it as it would cost money. I wish I could help you out here, but there isn’t much I can legally do. I’d suggest looking around at your next robotics meeting for the MPLAB disk.
Now if you want, you can send me an instant message and send your code to me through AIM, and I can compile it here. That should be legal to do.
my aim sn is boredouttahell99 i will be on in a few mins
thanks for your help i got it working but i have another quick question.
how would i go about programing in a delay like>
relay 1 turns on for like 1/4 a second and then turns off for like a second and then relay 2 turns on for like 1/4 a second and so on until relay 8.
any ideas because i tried it with for loops and tried to delay it, it compiles and when i run it i get a code error is there any way around the code error?
There is no way (as far as I know) you can just halt execution and wait. There are routines the bot has to run or else it will die (As seen by that Code Error).
The best way (that I know) is to count the loops. There’s two loops you normally put code into. The one in user_routines.c and the one in user_routines_fast.c
Process_Data_From_Master_uP() in user_routines.c is run every 26.2ms. It has to wait for user input (from the Operator Interface) so there is a large delay on it.
Process_Data_From_Local_IO() in user_routines_fast.c is run ever loop. It’s bound by how fast the processor is. It’s not exactly practical to count those. They are not run at a set interval.
The problem with the 26.2ms loop is that it doesn’t often match up to the delay you really want. To get close to a quarter of a second, you’d loop it 10 seconds. (Which is actually .262 seconds.)
Oh, User_Autonomous_Code() in user_routines_fast.c is also bound by the 26.2ms. It gets data from the OI. (You can put an autonomous mode selector on your OI if you wish. =) )
Using a forloop to stop execution is also kind of a programming no-no. It might work, but then you add something that slows (or speeds up) the code, and that changes the delay. Also, if you run it on a different processor, it’ll run way differently (think older DOS games running on modern processors.) Ideally you’d use some sort of timer function with ms resolution. You record the time, loop until the difference between the current time and the recorded time is what you want, and them move on. (Else a sleep function that does that all for you)
Either way, delaying like that won’t work on the Robot Controller. There’s too many functions which need to be called a lot in order to assure its own survival. I -think- one of those functions is called in order to detect an infinite loop. When you delay too long it rips out of your execution (via an interrupt), and displays the nice Code Error. That’s what I’ve always figured, can someone confirm this?
You have to set the tool locations…
This isn’t very efficient, but you could calculate how fast the processor executes your code, and then simply turn on/off the relay depending on how many times the code has been looped (e.g. have a counting variable).
Seanl: You’ll have to count loops. The processor MUST update every 26.5 mSec or will hang-up, “red light of death”. This is mentioned in one of the RC manuals.
You can either use a loop count (Kind of inaccurate) or you can use one of the built-in timers that are part of the RC. I believe there was a good interrupts white-paper released by IFI called “Interrupts for Dummies” that also talked about timers.