4-slot cRIO and default modules

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

[mikets]

Originally Posted by Joe Ross

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.

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.

[RufflesRidge]

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

[mikets]

Originally Posted by RufflesRidge

EDIT: Just saw your edit. You must put Analog, Digital, Solenoid in slots 1-3 on either cRIO. On the 4 slot, the 4th slot can be any module. On the 8 slot the pattern repeats with slots 507 with 4 and 8 left empty.

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".

[Alan Anderson]

Originally Posted by mikets

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.

[mikets]

Originally Posted by Alan Anderson

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?

[Joe Ross]

Originally Posted by mikets

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?

The code doesn't support it because the hardware (FPGA) doesn't support it.

[mikets]

Sorry about beating the dead horse but I am just curious about why the cRIO has the extra slot and the FPGA does not support it. It seems to me the extra slot is very useful especially in the 4-slot cRIO. For example, it is quite easy to run out of digital I/O channels with encoders taking 2 channels each, teams may want to stick another digital module in slot 4, for example.
Also RufflesRidge mentioned slot 4 of the 4-slot cRIO can take any modules.

[Mark McLeod]

You can stick whichever module you need in slot-4 of the cRIO FRC II.
The older cRIO FRC I, was just given the 3+0+3+0 pattern as a design choice. We are unlikely to mix the two up.

The FPGA is really full with all it's been given to do.
Excess capacity got sucked up to benefit us in other much more potentially useful ways.

All resources are limited in one way or another.
Engineering is designing and choosing between the optimal tradeoffs for our application.

[Bryscus]

Originally Posted by mikets

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".

You must have grown up only on a Windows machine. Windows only supports (without weird hacks) absolute paths for shortcuts. If you had grown up with Linux you would have used the symbolic links method (relative paths - module numbers not slot numbers). Then the code wouldn't have to be changed .

Speaking of dead horses...this is just wrong. LOL

- Bryce