problems with using switches for autonomous

[ssica_jj]

For our team autonomous, we decided to use switches for autonomous. We connected the Cypress board and the breadboard to wire up the switches. The value from the switches are being displayed on the driver station(classmate) but somehow, the program is not reading the value. The only value that it reads is 0. Even when we flip the switches, the value on the laptop does not change. (However, the value on the driver station is changing without any problems.)
Could anyone please help us on this problem?
Thank you!

EDIT*
The values from the switches are being read by the Classmate Driver Station, but not on the programming laptop (separate from the Classmate). It shows change on the Classmate Driver Station, but not on the programming laptop.

[Alan Anderson]

The value is being displayed, but it isn't being read? It's changing, but it isn't changing? I don't understand what you're saying.

[MrForbes]

Why not put the switches on the robot, connected to the digital IO on the digital sidecar?

[ssica_jj]

the values(boolean) is being displayed on the driver station, under the I/O tab, but not in the program on LabVIEW when you run it. It changes between 1 and 0 on the display on the driver station but not in the program.

I don't know how you would go about putting the switches on the robot. We have always put the switches with the driver station. We would like to keep it this way, however, we are willing to try another way if it is not possible to program the switches with the driver station.

[Alan Anderson]

How are you determining that the value is not being read in LabVIEW? If you show us your code, we might see something that's not doing what you think it is.

[ssica_jj]

We ran the RobotMain.vi in the project containing the code. We connect the laptop to the router which is connected to the driver station.

Attached is a screen shot of our code.

[Acshi]

Might it will only work during disabled mode and once it moves into autonomous mode the correct reading are overridden with incorrect ones? That might make sense since, you only have to read once and they might want to insure no active data is going to the bot in autonomous mode...

[ssica_jj]

Even though it is in the Disabled.vi, it should be reading it, however it doesn't read whether it is enabled or disabled.

[bls0620]

Just to clarify.....

We connected several switches to the Cypress IO board and confirmed that the Classmate is reading the inputs correctly. However, when we tried to program on LabVIEW using Driver Station Get Digital Input.vi, we didn't get any feedback from the Classmate.(we can still see switches working on the Classmate though )

[ligerbots]

would it be possible to just program your own dashboard and have that be your switch?

[bls0620]

Originally Posted by ligerbots

would it be possible to just program your own dashboard and have that be your switch?

It is possible but that would be troublesome. Using customized dashboard means we would have to click on each buttons(using mouse pad, of course) during the matches, which we are not willing to do so.

[Vikesrock]

Are you sure that you are using the correct array indices?

The labeling of the Digital Inputs on the Driver's Station starts with 1, but the array indices likely start at 0 (I haven't checked this).

[Alan Anderson]

Originally Posted by ssica_jj

Attached is a screen shot of our code.

You still haven't said how you are determining that the value isn't being read. Are you probing any of the wires to find out whether the data from the Driver Station digital inputs is making it out of the Get Dig In?

I don't know why you're storing a string of text "1" and "0" characters in something called "Program Num", I am having a hard time understanding why you are doing a Concatenate instead of using the Append T/F String vi to do the appending it is designed for, and I have no idea why you put a Get Dig In there three times. Can you describe what that code is supposed to be doing?

[ssica_jj]

Originally Posted by Alan Anderson

You still haven't said how you are determining that the value isn't being read. Are you probing any of the wires to find out whether the data from the Driver Station digital inputs is making it out of the Get Dig In?

When we ran the code, to check the values, we turned on the 'highlight execution' and saw that the only value being read is 0.

Originally Posted by Alan Anderson

I dont know why you're storing a string of text "1" and "0" characters in something called "Program Num", I am having a hard time understanding why you are doing a Concatenate instead of using the Append T/F String vi to do the appending it is designed for, and I have no idea why you put a Get Dig In there three times. Can you describe what that code is supposed to be doing?

There are 3 Get Dig In because we are using 3 switches. We are converting the value into string then concatenating them in order to create different combination for the case selector in autonomous. That way, we can have multiple autonomous modes and switch between them between matches without re-downloading the code each time. We are using the Append T/F String.vi to convert the digital input value into string.

[Alan Anderson]

Originally Posted by ssica_jj

When we ran the code, to check the values, we turned on the 'highlight execution' and saw that the only value being read is 0.

Try putting an indicator or a probe on the output of Get Dig In and running the code at speed.

There are 3 Get Dig In because we are using 3 switches.

Get Dig In returns all eight switches at the same time. You only need to use it once, and you can get multiple elements from its output with a single Index Array. See the attached code fragment. [edit]...which apparently didn't get attached properly, and which I do not have a copy of at the moment. I'll try to correct that later today.[/edit]

We are using the Append T/F String.vi to convert the digital input value into string.

I understand that, but you're ignoring the "Append" part of it. You can build the string as you go instead of keeping the characters separate and combining them in a separate step.