cRIO v43 == fail

[rbmj]

Hi everyone,

We've had some problems. We had some drive code on our old robot. After updating to the new firmware and recompiling/deploying the code, we have an issue. We are getting an error:

>>>> ERROR: Allocating module that is out of range or not found: Digital Module 6
...in InitPWM() in C:/WindRiver/workspace/WPILib/pwm.cpp at line 33
WPILib was compiled from SVN revision 2993

Looking at the source for WPILib, this call goes back to SensorBase::CheckDigitalModule(). So this call:

nLoadOut::getModulePresence(nLoadOut::kModuleType_ Digital, 6 - 1)

is returning false, but it should return true. I can confirm that we do have a digital sidecar in slot 6. The cRIO Imaging Tool also says that the module is OK. I can't find the source for getModulePresence either.

Should I report this as a bug to WPILib? Since the source for getModulePresence doesn't appear to be in WPILib, it seems like it would be out of their control (at least, I can't find the definition with a find | xargs grep getModulePresence). I could try commenting the check out and see if that works...

I have quadruple checked the module, and everything looks good. The imaging tool says the module is installed correctly. But the runtime check is failing. Why... all these silly updates- the last version that worked correctly for me was v28... anyway, if anyone has ideas, your help would be MUCH appreciated.

[basicxman]

Due to the attempted compatibility with the cRio-FRC II and the cRio-FRC (the one you're using) you'll need to pass in a module number to your objects. Since your sidecar is in slot 6 you'll have to pass in a 2 (the second group of slots).

For instance,

Servo *pan = new Servo(2, PAN_PWM_PORT);

Relevant links:

http://mmrambotics.ca/wpilib/class_s...a533a54f4b7909

http://www.usfirst.org/sites/default...20System_2.pdf (page 12)

[gr8dragon]

Do you also have a module plugged into port 2? also the new image has changed the numbering for modules. So check if you have it coded correctly. If you have a digital in slot 6 in your program it should be module number 2 not 6. And the digital in slot 2 should be value of 1 in your code.

[Alan Anderson]

Once you recognize that the modules are not addressed by slot number in the 2012 image, it all makes a lot more sense. The first module of any type is number 1; the second one is number 2.

[rbmj]

Originally Posted by Alan Anderson

Once you recognize that the modules are not addressed by slot number in the 2012 image, it all makes a lot more sense. The first module of any type is number 1; the second one is number 2.

I missed that. So it's 1, 2 - not 0, 1? And these will corrospond to the first/second sidecars?

Thanks!

As a side note, I like it better when they're addressed by absolute slot number. Makes coordination between electrical and programming easier, and that way you can keep track of what's on what slot (it'll look like the analog and digitals are on the same slot now). But if that's how it's done now...

[codedr]

Yes, it's a step backwards.

I don't know what FIRST is thinking, but I suspect they are 'making it easier' when they are really making it harder.

I also suspect that FIRST wants to hardcode the slot locations so they don't have to probe the cRIO bus to find the analog and digital modules. The embedded FIRST code wants to address the analog module to get the battery voltage, and the digital module to flash the status indicator.

[Alan Anderson]

Originally Posted by codedr

I don't know what FIRST is thinking, but I suspect they are 'making it easier' when they are really making it harder.

It's a way to make team code consistent between the 8-slot and 4-slot cRIOs.