4-slot cRIO and default modules

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?

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.

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.

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. :stuck_out_tongue:

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?

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

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

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.

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 :slight_smile:
thats where I get the source code I read to learn more about motor control and joysticks.

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; }

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.

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.

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.

That all sounds about right, other than that you could never put the modules wherever you wanted as far as I know. I believe it used to be Analog in 1 and 2 (may have been 1 and 3), Digital in 4 and 6 and solenoid in 7 and 8.

And yes, backward code comparability has not been maintained. All code that specifically referenced slot numbers (other than analog slot 1 which is 1 either way) must be updated to work in order to work with the new libraries and image.

EDIT: Just saw your edit. You must put Analog, Digital, Solenoid in that order in slots 1-3 on either cRIO (solenoid may be omitted). On the 4 slot, the 4th slot can be any module. On the 8 slot the pattern repeats with slots 5-7 with 4 and 8 left empty (any of the “extra” modules may be omitted, but the modules may not be shuffled around).

There’s a description of the new paradigm in the C++ Getting Started Guide: http://firstforge.wpi.edu/sf/go/doc1197?nav=1

I meant “in theory”. I am trying to understand the new paradigm, not that I really want to stick 3 analog modules in the cRIO.:slight_smile:

So again, just to make sure I understand it correctly. In theory, if I put three analog modules in the 8-slot cRIO, the first one in slot 1, the second one in slot 4 and the third one in slot 5 (I suppose this is still legal :)). I can address them by:


Gyro(1, 1);    //Gyro in slot 1, channel 1
Gyro(2, 1);    //Gyro in slot 4, channel 1
Gyro(3, 1);    //Gyro in slot 5, channel 1

Does it sound right? If so, they should have called it “instance” instead of “moduleNumber”.

Not right. No modules are supported in Slots 4 or 8 of an 8-slot FRC-cRIO.

You said no modules are supported in slot 4 or 8. Is it because it’s not allowed by the rules or is it because the code won’t accept anything in slot 4 or 8?