RELAY!!

[Dave Scheck]

I went back and added the spoiler tag to retain my original post but to hide it from the casual reader. As Joe said below, my analysis is incorrect. I'll leave the post here for reference.

Spoiler for Hiding bad info:

You're getting burned by the way you're building up Relay and DigitalInput. The code you have is syntactically valid and each line will run on its own, however, there is some code inside WPILib that is hurting you when they interact.

WPILIb provides the following constructors for Relay and DigitalInput

Relay(UINT32 channel, Direction direction = kBothDirections);
Relay(UINT32 slot, UINT32 channel, Direction direction = kBothDirections);

explicit DigitalInput(UINT32 channel);
DigitalInput(UINT32 slot, UINT32 channel);

With the way that you're calling those, you are only passing in a channel to the construtor, so you're calling the first construtor in for each class. Herein lies the problem.

The Relay constructor is going to call InitRelay with GetDefaultDigitalModule() as the slot number.

The DigitalInput constructor is going to call InitDigitalInput with GetDefaultDigitalModule() as the slot number.

In each of those functions, a Resource is allocated using the slot number passed in (in both cases the output of GetDefaultDigitalModule()) and a channel number (the channel number from your constructor). Inside Resource::Allocate is the code that I referenced in my previous post. You're telling it to create two Resources using the same slot and channel combination. It's at this point that the assertion fails and things break.

Specifically, it's these two lines

ArmRelease = new Relay(1);
Zone1 = new DigitalInput(1);

These both allocate Resources using the default slot with channel 1.

To fix this, you need to use the other constructor for these objects and specifically call out the slot number. I forget what the slot numbers are, but I found this in our 2009 code.

ap_rlyElevatorR  = new Relay(1);
ap_elevatorLimitRightTop = new DigitalInput(4, 1);

So that code creates the right elevator Relay on the default slot, channel 1 and creates the right top elevator limit switch Digital input on slot 4, channel 1.

Change up your constructors and you should be ok

[jhersh]

Originally Posted by Dave Scheck

Specifically, it's these two lines

ArmRelease = new Relay(1);
Zone1 = new DigitalInput(1);

These both allocate Resources using the default slot with channel 1.

That's not correct Dave. The digital modules have 4 distinct resource types... PWM channels, Relay Channels, an I2C bus, and Digital I/O channels. Because they are separate resources, you will not get conflicts from using the same channel "number" in a different set of channels. This is best illustrated by looking at the digital sidecar itself and witnessing different pins for each of those channel types.

Originally Posted by Dave Scheck

To fix this, you need to use the other constructor for these objects and specifically call out the slot number. I forget what the slot numbers are, but I found this in our 2009 code.

ap_rlyElevatorR  = new Relay(1);
ap_elevatorLimitRightTop = new DigitalInput(4, 1);

This has no effect. The default digital module is 4, so explicitly specifying 4 is not any different than not specifying it. In either case, you are allocating the same channel. The reason this works is because the relay channels are separate from the digital I/O channels.

[Alan Anderson]

What do the numbers in this line represent?

myRobot(1, 2),

How does that interact with these two lines?

		pair1 = new Victor(1);
		pair2 = new Victor(2);

[Dave Scheck]

Thanks for the correction Joe. After reading through the WPILib code again, I see how this is being done and agree with what you said about the resources. I also see what you mean about my code example. With the realays and digitial i/o on the same slot, it doesn't make any difference to specify the slot number in this case. I went back and put my original post in a spoiler tag to prevent confusion yet still have my bad analysis still available to learn from.

So, back to the analysis of the original error. The error clearly states that a resource is being allocated that was already allocated. I saw that Alan just posted a good suggestion that I was going to suggest next. My other suggestion (somewhat related) was to make sure there were no other places in the code that create relays, speed controllers, or analog/digital inputs on channels that were already in use for that resource type.

[jhersh]

Originally Posted by Dave Scheck

My other suggestion (somewhat related) was to make sure there were no other places in the code that create relays, speed controllers, or analog/digital inputs on channels that were already in use for that resource type.

Very true. We only saw a small snippet of code and it's quite conceivable that other objects are constructed else where. Wouldn't it be nice if the error told you which allocation cause the reuse?