Compressor Code causes No Robot Code Error

[sircedric4]

I didn't realize we got error messages on the driver station. I will check that and get back to you.

[sircedric4]

All right, I do get an error message on the computer. Here is what it says:

No change to network configuration "Local Network Connection"
I/O Unit not detected or not installed correctly


I thought this might have meant that I had a wire crossed or a bad PWM cable, but I have completely replaced the PWM cable and checked it to make sure it didn't have a short. The robot works perfectly fine if I don't call the Compressor code.

I am running the switch to the white and black cables in the PWM bundle just like last year. I am installing it in the digitial input on my digital sidecar, in address 1.

For the Spike I am running it to Relay 1 on the digital sidecar.

I believe I got it all wired right, but yet I still get the No Robot Code error and it appears it is "crashing".

Help please, I don't have the slightest clue what's going on here.

[jhersh]

Can you post a console log of the crash?

[sircedric4]

Originally Posted by jhersh

Can you post a console log of the crash?

I will look up how to do this and see if I can't get a console log tomorrow evening. Does someone have a cliff notes version of how to get that console log?

I did some searching this morning and found the NetConsole thing which I will try first, but since everything I try this year has been an abject failure from the beginning I also want to have the serial cable console procedure on hand as a backup. The problem is that I can't find directions for it. I've searched Chief Delphi and found some stuff about last years documents with instructions, but that link to last year's control system documentation has been convienently broken by FIRST.

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.

I really want to solve this problem soon, so I want to have every tool at my disposal tonight when I try to get this error message from the console so I can get some help.

[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]

Originally Posted by 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.

Well... I'm glad something is working for you!

Originally Posted by sircedric4

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

[sircedric4]

Originally Posted by jhersh

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]

Originally Posted by sircedric4

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]

Originally Posted by gvarndell

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]

Originally Posted by sircedric4

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.

Originally Posted by sircedric4

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.

Originally Posted by sircedric4

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]

Originally Posted by jhersh

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]

Originally Posted by 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.

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\target\src\demo directory and then install the C++ update.

Originally Posted by sircedric4

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]

Originally Posted by jhersh

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\target\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.