Compressor Code causes No Robot Code Error

[sircedric4]

Ok, you’ve got my code up above and we got NetConsole to work right off the bat today which was a pleasant surprise. We did have an interesting glitch today. When we turned on the robot we got the same No Robot Code as usual with the new code, but after the computer went to standby and we tried it a little later it started to run. It did not give me encoder data, but it got past the crash. We tried it a little later and it was back to No Code. I don’t like intermittent stuff.

Here’s the error stuff from our console: I couldn’t find a way to actually cut and paste the actual text so had to take screenshots. It is in the attachment.

Hopefully this is enough info to help us, we are spinning our wheels here.

[Alan_Anderson]

See this thread and look for the information on using mlongcall.

[jhersh]

Ok, you’ve got my code up above and we got NetConsole to work right off the bat today which was a pleasant surprise.

Well… I’m glad something is working for you!

Here’s the error stuff from our console: I couldn’t find a way to actually cut and paste the actual text so had to take screenshots. It is in the attachment.

To copy text from NetConsole client, just select it. When you let go of the left mouse button, it is copied to the clip board. To paste, just click the middle mouse button in the window. You can also resize the window to make it show more text or even maximize it.

And like Alan said… you need to build with the mlongcall option. Any project you create from the examples should already have this option set for you. Did you create a new project from scratch or based on an example? If an example, which one… I’d like to fix the example if one is not configured to use mlongcall.

-Joe

[jhersh]

I do know I need a null-modem adapter which I will pick up on the way to the school and to use HyperTerminal but I don’t know much more about how to setup the program to chat with the cRio. I looked in all the documents for this year with no luck. Could someone point me to the Hyperterminal instructions for the cRIO and also let me know if you’ve had any trouble with NetConsole I should be aware of.

You need to configure HyperTerminal (I prefer PuTTY for serial terminal) for 9600 baud, 8bit, no parity, 1 stop bit, no flow control. You need to flip the CONSOLE OUT dip switch on the cRIO to ON (push down away from the outside edge) and reboot the cRIO. Connect with a null modem cable, and you should be up and running with serial console. Remember that you need to disable NetConsole (remove it from the ni-rt.ini startup) if you want the global stdio to show up on the serial port.

-Joe

[sircedric4]

Well… I’m glad something is working for you!

To copy text from NetConsole client, just select it. When you let go of the left mouse button, it is copied to the clip board. To paste, just click the middle mouse button in the window. You can also resize the window to make it show more text or even maximize it.

And like Alan said… you need to build with the mlongcall option. Any project you create from the examples should already have this option set for you. Did you create a new project from scratch or based on an example? If an example, which one… I’d like to fix the example if one is not configured to use mlongcall.

-Joe

We built it off the IterativeRobot example. But when I was copying that and pasting it and changing the name to our version control it wasn’t taking information from the new directory so I was deleting the old build targets and creating new build targets. Could that have removed the magic “mlongcall” thing?

I swear I am starting to feel like a caveman looking at magic. Any sufficiently advance technology being indistiguishable from magic. I feel like I am learning a specific chant to get specific outcomes. I’m glad we got wizards here that I can at least get answers on which magic chant to do for any given outcome. Thanks guys. I’ll setup the project like outlined above and let you know if that solves our problems.

[gvarndell]

We built it off the IterativeRobot example. But when I was copying that and pasting it and changing the name to our version control it wasn’t taking information from the new directory so I was deleting the old build targets and creating new build targets. Could that have removed the magic “mlongcall” thing?

Could be, but I doubt it.
I’m pretty sure I created that same sample project and, with no tinkering or mucking around, there was no -mlongcall in the compiler switches.
Easy enough to create a new one, you can create as many projects as you want from the samples, and have a look.
Why did you create new build targets? Just curious.

[sircedric4]

Could be, but I doubt it.
I’m pretty sure I created that same sample project and, with no tinkering or mucking around, there was no -mlongcall in the compiler switches.
Easy enough to create a new one, you can create as many projects as you want from the samples, and have a look.
Why did you create new build targets? Just curious.

Everything started fine. We would create the initial template and then before we added code to it, I would copy the project and repaste it to the explorer and rename it and would create me a new folder to change the code in. This was working great up to Code 5, when we then copied it to move on to Code 6, whenever it would do the linking for the newly compiled 6 code, it kept pulling the data from the old 5 code and the code on the robot wasn’t changing right.

So now we copy the project, and then remove the build target and build a new target and the code always links and runs correctly. I guess I could just move the appropriate .cpp files over to a new created template project each time but the procedure I highlighted seemed easier. I wasn’t sure that it might not be causing the mlongcall problem which is why I mentioned it.

Hopefully we’ll be up and running again tonight when I get the mlongcall in.

[jhersh]

We built it off the IterativeRobot example.

Just to be clear, you are referring to the “FRC Default Program” (as listed in the examples) aka “BuiltinDefaultCode” (as listed in the Project Explorer)? I double checked this project and it definitely includes the -mlongcall option.

But when I was copying that and pasting it and changing the name to our version control it wasn’t taking information from the new directory so I was deleting the old build targets and creating new build targets. Could that have removed the magic “mlongcall” thing?

I tried removing the build targets and creating a new one and it still had the -mlongcall setting there.

I swear I am starting to feel like a caveman looking at magic. Any sufficiently advance technology being indistinguishable from magic. I feel like I am learning a specific chant to get specific outcomes. I’m glad we got wizards here that I can at least get answers on which magic chant to do for any given outcome. Thanks guys. I’ll setup the project like outlined above and let you know if that solves our problems.

I know it seems like witchcraft, but it really is just an option for the PowerPC platform that can save space if your code is not huge. WPILib is huge… well… huge enough to need longcalls. We anticipated this issue and made it use the whole memory space by default. Really what we need to track down is how you lost that option in your project.

-Joe

[gvarndell]

Just to be clear, you are referring to the “FRC Default Program” (as listed in the examples) aka “BuiltinDefaultCode” (as listed in the Project Explorer)? I double checked this project and it definitely includes the -mlongcall option.

Can you speculate what update we might be missing that would cause us not to have it?
I actually did a dump of the relocation data from the elf file after building it and there were a bunch of RELOC_24 in it.
After I added -mlongcall and rebuilt, they were gone – replaced by pairs of RELOC_16 as you would expect.
The only thing I’m not 100% certain is what sample project I used.
I’ll have to check my ‘robotics’ computer when I get a chance and see which sample it was.

[sircedric4]

The example I used was Iterative Robot Demo Main Program. We just performed the magic -mlongcall chant and did the appropriate ritual and the robot now functions as expected.

We are trying to figure out why our encoders themselves don’t give us data, but we’re just starting that. We are checking our wiring first again, and checking the forums, and then checking the code that’s already posted above. The good news is that the Compressor code performed flawlessly after we got the Reallocation error gone.

Thanks, and any suggestions on encoders would be appreciated though I may start a new post for that after we give it a good effort tonight.

[jhersh]

Can you speculate what update we might be missing that would cause us not to have it?
…
The only thing I’m not 100% certain is what sample project I used.
I’ll have to check my ‘robotics’ computer when I get a chance and see which sample it was.

Really the only thing I can think of off hand would be if either one of the projects doesn’t have that option set by default and that’s that you started with… or that you created the project from scratch. That option should have been set in all examples since last year.

[jhersh]

The example I used was Iterative Robot Demo Main Program. We just performed the magic -mlongcall chant and did the appropriate ritual and the robot now functions as expected.

I don’t even see that one. Perhaps that’s the problem. If there are really old examples left laying around since last year, it’s possible the example had a bug in the project from back then.

This is the list of projects that I see in source control today:

2010ImageDemo
BuiltinDefaultCode
CameraDemo
CSimpleTemplate
DashboardDataExample
DefaultRobot
DriverStationLCDText
GyroSample
SimpleTemplate
SimpleTracker
TwoColorTrackDemo

Anything you have in addition to these is probably very obsolete.

If I had a recommendation, it would be to remove all of the projects in the C:\WindRiver\workspace\WorkbenchUpdate\vxworks-6.3 arget\src\demo directory and then install the C++ update.

We are trying to figure out why our encoders themselves don’t give us data, but we’re just starting that. We are checking our wiring first again, and checking the forums, and then checking the code that’s already posted above. The good news is that the Compressor code performed flawlessly after we got the Reallocation error gone.

Glad it worked for you. As for encoders… first things first make sure that, as the wheel spins, both lines change by adding a Get() on each of the two DigitalInput objects. Then pass those DigitalImput objects into the Encoder constructor.

[sircedric4]

I don’t even see that one. Perhaps that’s the problem. If there are really old examples left laying around since last year, it’s possible the example had a bug in the project from back then.

This is the list of projects that I see in source control today:

2010ImageDemo
BuiltinDefaultCode
CameraDemo
CSimpleTemplate
DashboardDataExample
DefaultRobot
DriverStationLCDText
GyroSample
SimpleTemplate
SimpleTracker
TwoColorTrackDemo

Anything you have in addition to these is probably very obsolete.

If I had a recommendation, it would be to remove all of the projects in the C:\WindRiver\workspace\WorkbenchUpdate\vxworks-6.3 arget\src\demo directory and then install the C++ update.

Glad it worked for you. As for encoders… first things first make sure that, as the wheel spins, both lines change by adding a Get() on each of the two DigitalInput objects. Then pass those DigitalImput objects into the Encoder constructor.

It turns out its extremely helpful if you actually tell the encoders to Start() in your code. Like I said we hadn’t gone through the code yet and seen what our errors might be. Once we dug into the encoder header it became pretty obvious what to do. They give us numbers now when we call the Get() method. In the WPI User’s manual they don’t mention anything beyond setting them up. I guess they leave the using them up to the user. Not sure what we’ll do with them yet but having the number there to deal with was the important bit right now.

As for the code, I moved my entire last years Windriver directory over to a new directory named Windriver 2009 when I installed the new Windriver for this year. I wouldn’t have expected it to add sample projects across directories like that. I know my project is up to date, but I will check it out tomorrow. I had a problem with my updater not installing correctly and had to move the files from it by hand after extracting the data manually, is it possible that a correctly running updater deletes projects that are installed by Windriver by default and since all I did was add due to installer error that it left the IterativeRobot Demo I was using?

I would like to thank everyone for all their help. Tonight was a good night, one that we needed as we were getting quite distressed.

[MamaSpoldi]

jhersh, We are getting this same relocation error, but only when the code has been deployed; we are able to debug the code without an apparent issues. Does this make any sense to you? Is there more than one place where this needs to be set (ie. are there separate settings used for the build or dynamic linking when it is debugged vs. when it is downloaded)?

[jhersh]

jhersh, We are getting this same relocation error, but only when the code has been deployed; we are able to debug the code without an apparent issues. Does this make any sense to you? Is there more than one place where this needs to be set (ie. are there separate settings used for the build or dynamic linking when it is debugged vs. when it is downloaded)?

Are you maybe deploying the NonDebug version of your application?

[MamaSpoldi]

I believe that we are deploying the debug version of the code… the path to the .out file is in the debug subdirectory under the project directory.

Is it likely that the dynamic linking is handled differently on the cRIO during debug vs. when the code is deployed?

Regardless, I plan to try this build option tonight and I will let you know how it works out.

Thanks for your help.

[jhersh]

I believe that we are deploying the debug version of the code… the path to the .out file is in the debug subdirectory under the project directory.

That would be the same debug build, then.

Is it likely that the dynamic linking is handled differently on the cRIO during debug vs. when the code is deployed?

Nope… in fact, the deployment happens by simply picking up that file, renaming it to FRC_UserProgram.out and FTPing it to the cRIO. It doesn’t even get relinked between the two methods of running.

Chances are you are just getting lucky when it works in debug and happens to align in a 24-bit window. Triple check that the -mlongcall flag is getting used. You should see it in the Build Console on each line (for compiling each file) as an option to “ccppc”.

-Joe

[MamaSpoldi]

Thank you for your help… this fix worked!!!

[gvarndell]

Is it likely that the dynamic linking is handled differently on the cRIO during debug vs. when the code is deployed?

Sorry, I’ve been ignoring this thread for a while and didn’t see this until just now.
The answer is yes.
When your DKM is loaded by the debugger, it will almost certainly be loaded into a different memory region than if it is loaded by the in-kernel facilities.

Edit: of course, if the module is compiled long call, it won’t matter. If it’s not, you have luck-of-the-draw.