OK. Here is what I did…
1- Downloaded and ran the latest (update 3) from the WPI code web site.
2- Started Windriver in project that we had been running from week 1, a extension of the simple robot example.
3- Found that the interface to PID Controller had changed, constructor now needed PIDSource and PIDSource and PIDOutput, rather than setting them later. Also added calls to the SetInputRange and SetOutputRange methods in PIDController.
4- With those changes the code we had running now built.
5- Did a clean and a make all
6- Downloaded and had many unresolved references and a robot that would not boot (See terminal output, attached)
Is there anyway to back out this change in the libray or some way to correct what we are building? I don’t understand how the linking of the .a library from WPI is working.
Please, I need help ASAP as we were already running behind before I made this mistake!
[EDIT] I noticed after I posted that the WPI website says it will not work if I don’t have the correct cRio update. How do I know which update I have, and where can I get the update if I am missing it?[/EDIT]
New robot code problems.txt (64.9 KB)
New robot code problems.txt (64.9 KB)
I saw the same thing. Install the latest NI update and use the imaging tool to update the firmware on the cRIO. It is version 12 I think.
HTH
How do I tell what version I have? When did this update come out? We did the update right after kickoff. Is that the most recent one?
With the 3.0 update to C++, there is a similar update that must be applied to the cRIO. Currently, the only way to update the cRIO is to apply the recent LabVIEW update (also came out this week and it numbered 3.x). Then use that updated LabVIEW’s Imaging Tool to re-image the cRIO for C++.
Thanks! After I figured out how to update everything I got it all working again!
Whenever you see that long list of undefined symbols on loading the robot program, that usually indicates a mismatch between the cRIO update and the WPILib libraries. The FPGA symbols are in a namespace that changes with each update and the library symbols are in the same namespace. If you try to load the program where the versions don’t match you get all those undefined symbols because of the mismatched namespaces. This is intentional to make sure that people notice the mismatch.
I understand what is going on. However, I have yet to see a clear explanation of what is changed so that I can fix it reliably.
The situation that I have is this:
We have a central workstation that hosts most of the development. We have individual laptops that also run Workbench.
As far as we can tell, we have installed all the updates on all the systems. Everything seems to be the same across all our systems, as far as we have been able to determine.
However, on some of the laptops, we get the mismatched symbols when we try to load and debug.
What I am looking for is exactly what file needs to match between the cRIO and the Workbench development environment.
This is very frustrating for the student who can’t try out his code because we can’t get his development system in sync with the cRIO.
We are running into this issue again with the 2010 season. We have one development system that we have setup that works. Other development systems that we have setup, work until we attempt to debug and then we get the unresolved symbols.
The unresolved symbols seem to be focused on code that accesses the FPGA.
This leads me to suspect that the problem is in a library version that is installed on some of the systems, but I can’t figure out which one is causing the problem.