![]() |
Re: New C18 3.0+ Compatible FRC Code
We used it. There was one wierd issue with something that used to happen in the initialization routine not happening any more (initializing two variables to values read from the ADC), but that could be connected to me disabling the gyro code, or something else. If I can't find it after I try to look for it harder, I'll let you know.
Overall though, the code worked fantastically well. |
Re: New C18 3.0+ Compatible FRC Code
Quote:
|
Re: New C18 3.0+ Compatible FRC Code
Can anyone confirm that this code works when interfaced to the competition control?
I ran this code, compiled with the 3.0 compiler, with no issues prior to competition. During our first practice match at the Finger Lakes competition, the "code error" light came on and we have encountered a number of very strange issues with our team's RC since. These malfunctions disappear for a short while after reloading the "master code", but keep coming back. Any ideas? It very well might not even be related to Kevin's libraries... but the default .hex file from IFI seems to work, so I'm stumped. I can't even find a 2.4 version of the compiler, so I hope to make this work. Thanks! |
Re: New C18 3.0+ Compatible FRC Code
Quote:
From your description, it sound like you may be using a "While" loop.?? We did this and killed our selves. Once we realized what happened, we dropped the "While" loop and everything returned to normal. |
Re: New C18 3.0+ Compatible FRC Code
It definitely works. We ran it at Portland.
|
Re: New C18 3.0+ Compatible FRC Code
Quote:
|
Re: New C18 3.0+ Compatible FRC Code
Quote:
I just looked for while loops thinking maybe I mistakenly typed it instead of an "if" statement or something, but didn't find anything. Any other ideas on what may cause this? Thanks for the help! |
Re: New C18 3.0+ Compatible FRC Code
Quote:
If you want, you can zip up your code and send it to me for a quick look. -Kevin Edit: Whoops, 1024's master programmer just contacted me to point out that they used some of my other code, but not the 2008 base code. |
Re: New C18 3.0+ Compatible FRC Code
Quote:
If you are using interrupts for things like encoders and have too high resolution encoder (say 256 pulse per rotation) on a shaft that spins too quickly (say > 4 revolutions per second), then that encoder alone can generate >1000 interrupts per second. We use a guideline of no more than 4000 interrupts per second and very small, streamlined interrupt processing. If you've configured a millisecond timer interrupt, then you've got 1000 per second occurring there also. One indication that you're being a bit slow in responding to the master controller is a sluggish response to OI commands like joystick motion. That's the first indication, although you may not see it if the slow response occurs on some other event (like hitting a limit switch or turning on a motor to high speed that is being read by an encoder). All things to think about. I hope you get it figured out! Lynn (D) - Team Voltage 386 Software |
Re: New C18 3.0+ Compatible FRC Code
Quote:
Basically, go through some troubleshooting steps. Go back to what you know should work, and if it doesn't, then call IFI for them to fix your RC. Nothing that you code should mess with the indicator lights on the RC... this is what leaves me to believe that your master code is corrupted. |
Re: New C18 3.0+ Compatible FRC Code
Quote:
I'm still not sure exactly what is going on. Reloading the user program to our RC seems to briefly fix the problem, leading me to believe that this program is somehow becoming corrupt. I no longer believe Kevin's 3.0 compatible code to be contributing in any way (and I'm glad to be using it!) Kevin, I'll still zip and send you our program. Thanks all! Greg |
Re: New C18 3.0+ Compatible FRC Code
Quote:
The problem appeared to happen when we clicked the "set arm position" button, but all that does is change a variable's value, the function that sets it gets called every slow loop regardless of a button press. I couldn't replicate the problem in any way, I just noticed that it coincidentally happened when we pressed one of those buttons. There's nothing too slow in my code (absolutely no for/while loops, only a few printfs, two 8 CPR home-made encoders and two analog channels reading - that's the heaviest section) and most of it is standard Kevin code. My "fix" to the steady code error light was a Master processor reprogramming (and updating the user code with the same code that was running before), and I haven't been able to replicate the problem. I didn't even think it was a big deal, but now that you may have the same problem there could be something wrong (and if there is, it's probably in this sequence: our code -> our RC hardware -> the PIC silicon -> Kevin's code ;) ) Hopefully it went away, but, once again, it was too sporadical to know for sure. Kevin, I can send you my code if you want, but I really don't think there's anything wrong with it. Once again thanks for writing it! |
Re: New C18 3.0+ Compatible FRC Code
Quote:
The fix I've discovered is to re-upload the master and user code (although sometimes just re-uploading the user code works). Not sure if this is relevant to the new 3.0 compatible code, maybe we should move to a different thread? - Greg |
Re: New C18 3.0+ Compatible FRC Code
Quote:
-Kevin |
Re: New C18 3.0+ Compatible FRC Code
Was your battery fully charged at the time of the error?
|
| All times are GMT -5. The time now is 14:27. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi