Pneumatics Programming Problem

VEX V5 General Discussion Technical Discussion
1

Our team is designing two different pneumatic devices, one we need to toggle with two buttons, and on that just needs to be pushed on with continuous hold of a button. We have tested the different programs separately, but when combined, the pneumatic in digital 2 seems to bug out. When the cortex is turned on, the ch2 solenoid quickly switches as so: on, off, on, wait 5 seconds, off, wait two seconds, on, and once the controller and cortex are finally connected (all green), off. This isn’t a problem with the other cortex, or when the two controls are in separate programs. Here is the program:


#pragma config(Sensor, dgtl1,  air,            sensorDigitalOut)
#pragma config(Sensor, dgtl2,  air2,           sensorDigitalOut)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

int toggle1;
task main()
{
	SensorValue[air2] = 0;
	SensorValue[air] = 0;
	while(true)
	{
if(vexRT[Btn8R] && toggle1 == 1){
toggle1 = 0;
}


if(vexRT[Btn8D] && toggle1 == 0) {
toggle1 = 1;
}


if(toggle1 == 1) {
	SensorValue[air] = 1;
}

if(toggle1 == 0) {
	SensorValue[air] = 0;
	
if(vexRT[Btn7D] == 1)
{
	SensorValue[air2] = 1;
}
else(SensorValue[air2] = 0);
}
}

What is happening? I don’t quite understand. I made sure that it was the program by switching the two solenoid connectors, and the problem changed from solenoid to solenoid, with respect to the channel change. Any suggestions are very appreciated!

2

It looks like you forgot a bracket }

I bolded and italicized the missing bracket.

#pragma config(Sensor, dgtl1,  air,            sensorDigitalOut)
#pragma config(Sensor, dgtl2,  air2,           sensorDigitalOut)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

int toggle1;
task main()
{
	SensorValue[air2] = 0;
	SensorValue[air] = 0;
	while(true)
	{
		if(vexRT[Btn8R] && toggle1 == 1){
			toggle1 = 0;
		}


		if(vexRT[Btn8D] && toggle1 == 0) {
			toggle1 = 1;
		}


		if(toggle1 == 1) {
			SensorValue[air] = 1;
		}

		if(toggle1 == 0) {
			SensorValue[air] = 0;
		***}***

		if(vexRT[Btn7D] == 1)
		{
			SensorValue[air2] = 1;
		}
		else(SensorValue[air2] = 0);
	}
}
3

I’m having the same problem let me know if you fix it!!!

4

Classic curly brackets. Always screwing things up. :smiley:

5

I added the curly bracket and unfortunately it didn’t change anything. We do have a temporary solution, just cutting off the air until the crazy cycling is over then switching the air “on”, but would like to fix it either way.

6

Did you say you tried a second cortex and this did not happen ? Are they both the same hardware revision?

7

Figured out the problem!

It seems that our solenoid to 3 wire connector is bad. We put the exact same program (with excluded } ) and only connected the solenoid to of the active ports, with the bad cable. Then we switched to another cable and viola! Problem solved! We just got this kit, with a defective cable… Refund the wire?

8

I have had the same problem for a while. Gone through all the wires and program in debugger window to see what was happening but I still couldn’t figure it out. I know of a few other teams with the same problem (tabor473). Now I have to resort to pumping after it connects so it doesn’t break things in the transmission…

9

Or you could keep the main valve closed until the “glitch” is over. We are fairly certain it’s the wire. That would seem to make sense if the problem was fixed with a different wire on the same solenoid. I honestly think that Vex is sending out some defective wires. The driver on that wire might have gone bad somewhere in the process of shipping or manufacturing.

10

I have tried every combination of solenoid and wires in the classroom and no dice. I am pretty sure it is something with the port because it doesn’t matter what wire is plugged in it always does the same ports. (perhaps conductive aluminum dust from demeling got in there or something).

11

I have this same issue but it happened when I changed cortex from an A4 to an A3 model due to a bad battery port…

I really need to fix this because its wasting tons of air and I have a competition tomorrow

However it only happens on the piston on port 3 the other 4 pistons Y cabled together on port 10 do not rapid fire when connecting…

12

My guess, I will try and verify tomorrow, is that as I explained yesterday, the digital ports are initially configured as inputs and pulled high by a weak pullup resistor. This causes the pneumatics to fire, then the code reconfigures the port as an output and it will be set low, if VEXnet disconnects the user cpu is reset and the whole thing repeats. There is no simple solution if this guess is right, of course if the solenoid driver is designed with reversed logic (as it should be) then this is all wrong.

Edit:
So I tried this today and to be honest I cannot find any problems. The pneumatics did not fire until commanded by the code. I guess my theory is wrong.

13

This was bugging me so I hooked everything up with the scope this morning and did some tests. I’m just running with the cortex and USB cable, no joystick here so the results differ slightly from competition use, however, my cortex does not fire the pneumatics on power up but is right at the limit of doing so.

This first scope screenshot shows the digital output control signal (purple) and the voltage at the solenoid input (yellow and blue). When the cortex is powered on the control signal goes to just under 1.2V, I don’t know what configuration it’s being initialized to but after 360mS it does get pulled low, this is when the ROBOTC code executes, 1 second later my code fires the pneumatics. You can see from the blue trace that the solenoid almost has enough voltage across it to fire but it fact it does not. Tests with an external power supply showed that 1.2V is the threshold to turn on the transistor in the solenoid driver cable. I suspect that due to component differences some combinations or cortex ports and cables will allow the pneumatics to fire as some of you have found.

[ATTACH]7293[/ATTACH]

In this test I added an external 15k pullup resistor to the output port. This is enough to pull the digital port high when first powered and the pneumatics fire. This again supports the theory that due to component tolerances some ports may allow the pneumatics to fire and some not.

[ATTACH]7294[/ATTACH]
pneumatics_scope_1.jpg
pneumatics_scope_2.jpg

14

Now I have tried about 4 ports on my cortex 3, 10, 12, and 1 and my transmission piston will still rapid fire when it is connecting this wastes so much air and is ruining my bevel gears I have made…
Also I have 4 other piston that do not random fire on connecting these are controlled by 8 solenoids. 2 solenoids each being Y cabled together

Could it be anything else? Code possible? Do I need to set the position in pre auton? Or at the start of driver control mode?

15

I don’t have the schematics for the cortex or the solenoid driver, without those my only conclusion is as I explained in post #13 as I don’t have enough information. I will ask the hardware engineers from VEX at worlds if I have time, but I think it’s a design flaw in the solenoid driver. Some drivers coupled with certain IO ports will have this issue, it probably needed another pullup resistor in the solenoid driver or something like that. There is a deliberate 2 second delay in the ROBOTC competition template before pre-auton is called so not much help there either.

16

Now… may sound silly… but if I was to use another Y cable and put say a LED on the end of it in with the solenoids cable to the other end… would this be bad? I’m trying to prevent this rapid fire… but I can’t think straight no sleep in 2 days now…

17

I think I tried that and it didn’t work. I don’t have any pneumatics and wont have access to any at the school until the end of next week. What it probably needs is a pullup resistor or something like that but it’s not legal. To be honest, because I could not reproduce this problem with the pnuematics the school has I’m not sure what else to suggest. I doubt it can even be fixed with different firmware as the master cpu holds the user cpu in reset until VEXnet is established I think. Let me think about it some more.

18

Check all your wires for broken insulation, and make sure your potentiometer isn’t being “overextended.” I once had a problem with pistons rapid-firing (but it was all digital outs, not just a single piston) because I exceeding the current draw (or something like that) when I overextended the pot…

Just an idea…

19

I have tried 3 cables… and I only have 5 digital ports being used all by pistons… the only difference is this one solenoid is slightly different it has mounting holes and is newer than the other ones I have…

20

So you have 9 solenoid valves? One for the transmission and 8 others (configured as 4 pairs of 2) driven by Y cables?

Is this new solenoid the same part number? It’s printed on the solenoid somewhere.

Can you swap the transmission solenoid for one of the others? Does the problem move with this particular solenoid?

I have an idea but I’m not able to try it and it would require you to follow a specific procedure every time you turned on the robot. It would use a Y cable as you suggested but instead of a LED it would use a jumper to short the digital port to ground. The digital port would be configured as an INPUT in the motors and sensors setup dialog, installing the jumper would hold the input low and also ground the control input to the solenoid driver. You would power up the robot and after connection and the code runs reconfigure the digital port to be an output, I need to check which one exactly but what you need is to configure the port and keep it’s output low (which I think is SensorType dgtl1 ] = sensorDigitalOut; but it may be SensorType dgtl1 ] = sensorLEDtoVCC; one defaults low the other high). At this point you should remove the jumper so you can control the transmission. Normally this would be a bad thing to do, however, there is a serial 1K resistor that’s designed to avoid shorting an output port to ground so SHOULD be safe. I don’t have my scope at home so can not verify, perhaps I would have time tomorrow. As I said before, I also don;t have any pneumatics here so would have to simulate that. I think this should be a last resort and you should try perhaps swapping with one of the other solenoids first.

Code may be like this.

#pragma config(Sensor, dgtl1,  transmission,   sensorDigitalIn)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

#pragma platform(VEX)

//Competition Control and Duration Settings
#pragma competitionControl(Competition)
#pragma autonomousDuration(20)
#pragma userControlDuration(120)

#include "Vex_Competition_Includes.c"   //Main competition background code...do not modify!

/////////////////////////////////////////////////////////////////////////////////////////
//
//                          Pre-Autonomous Functions
//
// You may want to perform some actions before the competition starts. Do them in the
// following function.
//
/////////////////////////////////////////////////////////////////////////////////////////

void pre_auton()
{
    // Allow transmission control
    SensorValue transmission ] = sensorDigitalOut; 
}

Disclaimer, this is just me thinking out loud, if anyone thinks of a good reason not to do this speak up.

EDIT:
Also, don’t test this with an led as this shorts the led to 5V, no series resistor (5v on one side of the led, gnd on the other).

EDIT2:

I should add, if you really have 9 solenoids, you are close to the limit for the 5V power supply. The solenoid spec is as follows.

[ATTACH]7369[/ATTACH]

The power consumption is 0.5W, so about 100mA of current. 9 Solenoids gives 900mA, the 5V regulator is rated at 1A so not much headroom there. You are still within spec but I just wanted to point this out.
solenoid_spec.jpg