4-slot cRIO and default modules

[mikets]

I am very confused about the new module arrangements. Our team bought the new 4-slot cRIO this year. We followed the new convention and put the Analog module in slot 1, Digital module in slot 2 and the Solenoid module in slot 3. But we are trying to figure out if the WPILib would have the correct modules by default so we don't need to explicitly specify the modules when instantiating sensors and switches. This is to make sure our robotics library still works because the code would call GetDefaultXXXModule() to determine where the modules are. I have downloaded the source code of the WPILib. The more I look at it, the more confused I am. It looks like it is still defaulting to the 8-slot arrangement. For example, SensorBase.cpp has the modulePopulation array initialized to the 8-slot arrangement. SensorBase.h also has the following declaration:

UINT32 SensorBase::m_defaultAnalogModule = 1;
UINT32 SensorBase::m_defaultDigitalModule = 4;
UINT32 SensorBase::m_defaultSolenoidModule = 8;

But when reading threads here, I got an impression that I don't need to explicitly specify the module slot. And I have an impression that even the 8-slot cRIO should have the new module arrangement the same as the 4-slot. If so, why is the code showing the old arrangement?

[mikets]

I loaded a modified version of last year's code to the robot and it gave me:

ERROR: Allocating module that is out of range or not found: Analog Module 2 ...in GetInstance() in C:/WindRiver/workspace/WPILib/AnalogModule.cpp at line 38

ERROR: Allocating module that is out of range or not found: Digital Module 2 ...in GetInstance() in C:/WindRiver/workspace/WPILib/DigitalModule.cpp at line 36

And of course, the lines specified in the above message don't seem to have anything to do with the error.

[aeniug2]

Not sure if this is entirely related, but I know that nowhere in my teams code do we ever reference a specific module. We are using all the latest updates and etc.

If it helps at all, the cRIO imaging tool should show you if you have all the modules in the right slots.

[mikets]

Originally Posted by aeniug2

If it helps at all, the cRIO imaging tool should show you if you have all the modules in the right slots.

They are in the right slots: 9201 in slot 1, 9403 in slot 2 and 9472 in slot 3. In fact, I just re-imaged the cRIO to make sure just in case I screwed up the first time.

[aeniug2]

Originally Posted by mikets

They are in the right slots: 9201 in slot 1, 9403 in slot 2 and 9472 in slot 3. In fact, I just re-imaged the cRIO to make sure just in case I screwed up the first time.

Awesome. Reimageing can solve alot of problems... In fact, it solved all the major problems my team has had so far this year.

Anyways, I'm not sure I can help you much... The only sections of the WPILib.h source code I've ever studied in depth are the ones directly related to driving the robot, and receiving input from joysticks; among some other random stuff.

This might be a dumb suggestion, but have you tried just running the simpletemplate?

[Joe Ross]

I don't think you're looking at this year's code.

[mikets]

That's what I thought, but I got it off the latest from first forge.
http://firstforge.wpi.edu/sf/scm/do/...cts.wpilib/scm

[mikets]

Originally Posted by aeniug2

have you tried just running the simpletemplate?

The simple template is not applicable to our robot. Our robot is using CANJaguar. So it doesn't use the PWMs on the digital sidecar.

[aeniug2]

Originally Posted by mikets

The simple template is not applicable to our robot. Our robot is using CANJaguar. So it doesn't use the PWMs on the digital sidecar.

Ahhh... Interesting. Our team has never tried that out... I think we'll stick to pwms for now.

[RufflesRidge]

Originally Posted by mikets

That's what I thought, but I got it off the latest from first forge.
http://firstforge.wpi.edu/sf/scm/do/...cts.wpilib/scm

I don't think that code is updated any more. Instead the source is installed by the update. Into C:\windriver\wpilib as a zip file if I remember right. I believe the update is just a self-extracting archive so you should be able to dig the source out of it by renaming it to .zip if you're on a Linux machine

[aeniug2]

Originally Posted by RufflesRidge

I don't think that code is updated any more. Instead the source is installed by the update. Into C:\windriver\wpilib as a zip file if I remember right. I believe the update is just a self-extracting archive so you should be able to dig the source out of it by renaming it to .zip if you're on a Linux machine

you do remember right
thats where I get the source code I read to learn more about motor control and joysticks.

[mikets]

Originally Posted by RufflesRidge

I don't think that code is updated any more. Instead the source is installed by the update. Into C:\windriver\wpilib as a zip file if I remember right. I believe the update is just a self-extracting archive so you should be able to dig the source out of it by renaming it to .zip if you're on a Linux machine

Thank you for reminding me. I used to get the source from there but ever since I enlisted to the first forge sources, I thought it would be the latest there but I guess I am wrong. But if the zip'd version is the latest (WPILibC++Source20120108rev2993.zip), then it is even worse because according to sensorbase.h, all modules default to slot 1!

        static UINT32 GetDefaultAnalogModule() { return 1; }
        static UINT32 GetDefaultDigitalModule() { return 1; }
        static UINT32 GetDefaultSolenoidModule() { return 1; }

[RufflesRidge]

That's because it's not a slot number. The whole paradigm for referencing the modules has changed to support the 4-slot cRIO. The 1st of each module (analog, digital, solenoid) in slots 1-3 is module 1 of that type. The 2nd instance (slot 4 on 4-slot, slots 5-7 on 8-slot) is module 2 of each type.

[mikets]

Ah I see. So in other words, all the methods involving modules (previously slots) are incompatible with previous versions. For example, for the gyro module, one of the constructors Gyro(UINT8 moduleNumber, UINT32 channel) is no longer compatible with the previous version Gyro(UINT32 slot, UINT32 channel). If I have old code that instantiate a gyro with a secondary Analog module in slot 3, for example. The code would look like Gyro(3, 1). But for this year, I have to put the secondary analog module in slot 5 (assuming a 8-slot cRIO) and initiate it with Gyro(2, 1). Does it sound about right?

Does it mean that I can no longer put the modules anywhere I want but it has to be "Analog, Digital, Solenoid, ???" in that order? Or the WPILib is smart enough so that I can put, for example, 3 analog modules anywhere, and I can address them by naming them 1 (1st instance of analog), 2 (2nd instance of analog) and 3 (3rd instance of anlog) since it can read the module ID in each slot.

[Joe Ross]

Originally Posted by mikets

Does it mean that I can no longer put the modules anywhere I want but it has to be "Analog, Digital, Solenoid, ???" in that order?

You've never been able to put the modules anywhere you wanted. Analog were slots 1 &2 (rules dictated you had to use slot 1), Digital were slots 4 & 6 (rules dictated you had to use slot 4), Solenoid were 7 & 8.