WPI Lib Relay class - individual line control

[de_]

I can't quite figure out the WPI Lib description as to whether we can individually control each of the 2 output lines without effecting the other line. Here's an extreme example

On one line have an (12v) Red LED connected and be able to turn it on and off without effecting the state of what is on the other line of the spike. On the other line, we want to have a white 12v led that we flash in software, again, not effecting the Red LED.

The class description seems to hint that we need to declare 2 relays on the SAME channel,
- one with forward only (line 1) control
Relay m_relay1(1, Relay::KForwardOnly);
- and one with reverse only (line 2).
Relay m_relay2(1, RElay::kReverseOnly);

And then we can control each line relay individually.

Or do you declare a single relay and change the direction to access a specific line on the fly like

Relay m_relay(1);

:
m_relay.SetDirection(Relay::kForwardOnly); // access 1 line of the spike
m_relay.Set(Relay::kOn) ; // set On or Off 1st line
m_relay.SetDirection(Relay::kReverseOnly); // access 2nd line
m_relay.Set(Relay::kOn); // set On or Off 2nd line....
:

Sorry last coding I did was on an RC :)

[java4first]

We are doing something similar, and fortunately have a good Controls person to translate the h/w to s/w requirements. I don't have access to the code until we get back to the Verizon today - but we are doing something like this.

One relay has two LEDs, and one relay has one. On the two one, you create it, set the direction to both, and then by setting the value to either forward or backward, it turns one or the other on and the other off (toggle mode). Or you can set it off to turn both off.

For the relay with only one LED, we set the direction to forward(?) and then turn it on or off. Or something like that (I'm not as sure for this one).

Sorry I can't post the code at this point to make it work - but maybe this will help. If you use the output on the dashboard for the relays, you can see the two little lights (one above each other) go green and red as you set the state for which line is on and off.

[Mr. Lim]

http://www.chiefdelphi.com/forums/showpost.php?p=1034452&postcount=5

[Ether]

On one line have an (12v) Red LED connected and be able to turn it on and off without effecting the state of what is on the other line of the spike. On the other line, we want to have a white 12v led that we flash in software, again, not effecting the Red LED.


The two processes will have to cooperate to achieve what you want.

Let the 4 possible states of the Spike outputs be:


White Red
1) OFF OFF
2) OFF ON
3) ON OFF
4) ON ON


Then, to flash the Red LED on/off while the White one is OFF, you would alternate between states 1 & 2.

But to flash the Red LED on/off while the White one is ON, you would alternate between states 3 & 4.

So the process which flashes the Red LED cannot act independently from the process which flashes the White LED, and vice-versa. The processes must share information.

One way to do this would be to have each process just set a boolean flag to indicate whether its LED should be ON or OFF, and let a third process set the proper state of the Spike each time either of these booleans changes. Rather than having the third process chew up resources polling, you could use some sort of messaging supported by the vxworks OS.

[de_]

Thanks everyone. That makes sense now!

[Joe Ross]

Unfortunately, it looks like the Java wpilib code throws an exception if you set both on. You'd have to modify wpilib.

[de_]

Thought I would step back and see if there is any hardware reason I can't individual lines without effecting the other line and there isn't. Right now the class appears to require you to know the state of the other line (H/L) so you can change the the line you are interested in (ie which function code you need) as the code seems to say it will effect BOTH lines. But if this is true, this sure appears to be a software constraint.

I do wonder what would happen if I tried what I suggested in the first post.
Time to get my hands wet in Java....

[Mr. Lim]

int redLight = 0;
int whiteLight = 0;

void updateLights()
{
int combinedLights;

combinedLights = (redLight << 1) + whiteLight;

switch (combinedLights)
{
case 0:
myRelay.set(Relay.Value.kOff); // M+ and M- = 0V (Both Off)
break;

case 1:
myRelay.set(Relay.Value.kForward); // M+ = 12V, M- = 0V (White Only)
break;

case 2:
myRelay.set(Relay.Value.kReverse); // M+ = 0V, M- = 12V (Red Only)
break;

case 3:
myRelay.set(Relay.Value.kOn); // M+ = 12V, M- = 12V (Both On)
break;
}

}

Something like the above will give you two independent variables representing the lights that you can change without knowing the state of the other light. Just call updateLights periodically.

[Joe Ross]

The class description seems to hint that we need to declare 2 relays on the SAME channel,
- one with forward only (line 1) control
Relay m_relay1(1, Relay::KForwardOnly);
- and one with reverse only (line 2).
Relay m_relay2(1, RElay::kReverseOnly);

And then we can control each line relay individually.

This will cause an exception because relay 1 will be allocated twice.

Or do you declare a single relay and change the direction to access a specific line on the fly like

Relay m_relay(1);

:
m_relay.SetDirection(Relay::kForwardOnly); // access 1 line of the spike
m_relay.Set(Relay::kOn) ; // set On or Off 1st line
m_relay.SetDirection(Relay::kReverseOnly); // access 2nd line
m_relay.Set(Relay::kOn); // set On or Off 2nd line....
:

Sorry last coding I did was on an RC :)

With this code, whenever the relay is set to ForwardOnly, the reverse will be off, and vice versa.

[Ether]

Something like the above will give you two independent variables representing the lights that you can change without knowing the state of the other light. Just call updateLights periodically.

The above is essentially what I posted previously (http://www.chiefdelphi.com/forums/showpost.php?p=1034471&postcount=4) in this thread:

One way to do this would be to have each process just set a boolean flag to indicate whether its LED should be ON or OFF, and let a third process set the proper state of the Spike

..except for the suggestion of calling the relay update task periodically.

The problem with calling the update task periodically is that in order to get good flashing "fidelity" it must be called at a fast rate even if the flashing rate of the individual LEDs is quite slow, and this wastes resources.

The fidelity of flashing LEDs is probably not critical but what if it were something which was critical? How should that be coded? You can put the Relay Update code in a separate thread and have it wait for notification that the LED states have changed, and then it updates the relay immediately and waits for another LED state change.

[de_]

Thanks for all the insights. We could certainly manage it in software now that it is clear. Too bad the class doesn't allow independent manipulation of each of the lines when the hardware clearly can do it. I might eventually bring that up with Brad as a possible enhancement.

[de_]

Just to be clear: independent toggling of each of the lines is not supported by the Spike relay. "


As far as I can tell this constraint is NOT in the spike hardware. If you connect 12v to the input on the spike and put 5v on the red control line, one output line follows it and has no effect on the other line controlled by the white wire (which could be on or not). Same for the White. So the concept of Forward (one line switched high, and the other one automatically low) and Reverse is not native to the spike based on my testing. There is a tiny chance the digital side card is not electrically capable of driving just one line but not likely. More likely a historical software constraint where spikes were used for forward reverse motors and then double solenoids.

The students have implemented flashing and boy the spike relay clicking is annoying :)

[Ether]

As far as I can tell this constraint is NOT in the spike hardware. If you connect 12v to the input on the spike and put 5v on the red control line, one output line follows it and has no effect on the other line controlled by the white wire (which could be on or not). Same for the White. So the concept of Forward (one line switched high, and the other one automatically low) and Reverse is not native to the spike based on my testing.

Thanks for this additional detail. I was going from memory from last year. I went back and re-checked the datasheet and it appears you are correct.

I will correct or delete my earlier post(s) to the contrary.