toggle switch

[KenWittlief]

usually push buttons are used to turn something on while you hold it, and off when you let it go. In that case, if it goes OnOffOnOffOn for a 100mS when you push it, you probably wont notice (unless you put a scope on the output signal).

The case in this thread, where he wants a single button to act as a toggle, I dont know if Ive seen a team do this before?

[Alan Anderson]

Originally Posted by KenWittlief

The case in this thread, where he wants a single button to act as a toggle, I dont know if Ive seen a team do this before?

People ask about it every year, and they receive pretty much the same programming advice every time. I assume they use it and implement what they asked about.

The TechnoKats have used a toggle function for shifting the drive train between high and low gear for the past few years.

[devicenull]

We did last year, and a couple years before that. We had "feet" on our robot that were pneumatically activated to make the robot unmoveable. The button on the control panel toggled their state. Pressing it while they were down would raise them, or lower them if they were up.

I've never come across the problem where the signal would bounce. I'm not sure if thats something IFI compensated for, or if it just hasn't been a problem yet.


Windward: If you use the code that I gave you, the "char oldstate" has to be defined either globally or staticly. Either put it at the top of the code, above any function, or use "static char oldstate;" instead of "char oldstate". That code should go below the default relay stuff, otherwise they will override it.

[KenWittlief]

I did a little searching on threads from previous years. In the past people have monitored input switches on the operator interface, and seen switch-bounce.

I was thinking perhaps IFI filters the switch inputs, but from what I have been able to find so far, they dont. Unless someone does further testing, or IFI comes up and says they have debounced the switches in the interface, I would design your systems to debounce the switch inputs (user interface and on the robot) if your application requires knowledge of single-push button actions.

from a thread in 2004:

Originally Posted by maxlobovsky
This may or may not be related, but i have found that lots of joystick buttons seem to flicker IE not giving a constant stream of 1's when they are being pressed. Our code now checks the button over the period of 3 or 4 frames to make sure its really pressed. This is probably a good idea for a winch button anyway, you wouldnt want it accidentally pressed.


Originally Posted by KenWittlief
wow! im impressed that you discovered that by yourself!

Its called 'switch bounce' - when you close a switch or pushbutton it takes about a 1/10th of a second for it to make solid contact - the surfaces actually do bounce a tiny bit - so if a fast microprocessor is polling the switch it will see it go 00001101010011110111111011111111111

and your timing is right - 3 frames is about a 100 mS

nice catch!

[iBheat]

If you are having problems with the OI reading multiple clicks with one click due to your reaction time being slower then one loop on the processor you can do this:

static unsigned int loops = 30;

if (p1_sw_trig && loops >= 30)
{
  relay1_fwd = !relay1_fwd;
  relay1_rev = !relay1_fwd;
  loops = 0;
}

if (loops < 30)
loops++;

Basically what this does is checks if the button is pushed every 30 processor cycles which with the default code is 786 ms (26.2 ms/Cycle * 30 Cycles). You can change the number from 30 to whatever you want!

Edit: Fixed a small bug

[KenWittlief]

you have the basic idea, but you need a few more lines of code.

the way its written 'loops' will keep incrementing, eventually it will get to zero and your switches will be ignored for almost a second (till it gets to 30 again, 786mS later)

[iBheat]

Originally Posted by KenWittlief

you have the basic idea, but you need a few more lines of code.

the way its written 'loops' will keep incrementing, eventually it will get to zero and your switches will be ignored for almost a second (till it gets to 30 again, 786mS later)

Small mistake ... I fixed it in the code above!

[Windward]

I am trying to get the code to work with 2 spikes. It works with 1 spike, but I'm still a little confused on how to modify.

if(initVar != 1)
{
	relay2_fwd != relay2_rev;
	initVar = 1;
}

if (p1_sw_trig && !oldstate)
{
	relay1_fwd = !relay1_rev;
	relay1_rev = !relay1_fwd;
	relay2_fwd = !relay2_rev;
	relay2_rev = !relay2_fwd;
}
if (p1_sw_trig != oldstate)
	oldstate = p1_sw_trig;

I initialized the relay2 fwd & rev so it was opposite. Otherwise the code was pretty much the same.

I am not sure where to procede from here.

[KenWittlief]

what do you want the 2nd spike to do? trigger the same as the first one?

trigger the opposite direction?

[devicenull]

Originally Posted by Windward

I am trying to get the code to work with 2 spikes. It works with 1 spike, but I'm still a little confused on how to modify.

if(initVar != 1)
{
	relay2_fwd != relay2_rev;
	initVar = 1;
}

if (p1_sw_trig && !oldstate)
{
	relay1_fwd = !relay1_rev;
	relay1_rev = !relay1_fwd;
	relay2_fwd = !relay2_rev;
	relay2_rev = !relay2_fwd;
}
if (p1_sw_trig != oldstate)
	oldstate = p1_sw_trig;

I initialized the relay2 fwd & rev so it was opposite. Otherwise the code was pretty much the same.

I am not sure where to procede from here.

While that may work, It's a bit different then what I had..

if(initVar != 1)
{
	relay2_fwd != relay2_rev;
	initVar = 1;
}

if (p1_sw_trig && !oldstate)
{
	relay1_fwd = !relay1_fwd;
	relay1_rev = !relay1_rev;
	relay2_fwd = !relay2_fwd;
	relay2_rev = !relay2_rev;
}
if (p1_sw_trig != oldstate)
	oldstate = p1_sw_trig;

The NOT (!) operator basically toggles the state of it. If it was 0, it becomes 1. If it was 1, it becomes 0.

If thats confusing consider this:

char A = 0;
printf("%i",A);
A = !A;
printf("%i",A);
A = !A;
printf("%i",A);

Will result in this output:
0
1
0

I'm not sure if this post will help, or just confuse you more. Let me know if you still don't understand.

[Windward]

I want to use the 2 spikes to activate and retract a piston.

I understand how you take the opposite of the present state I didn't realize that I switched the forward and reverse. I will try to fix that next.

[KenWittlief]

check the electrical section of the pneumatics manual. You only need one spike per cylinder. The two valves can be controlled by the FWD and REV outputs off the spike, using battery ground for the return.

or you can use two diodes, so that FWD powers one valve, and REV (reversed voltage) powers the other valve.

remember the spike has three output states: forward, reverse, and off.

[Windward]

Originally Posted by KenWittlief

check the electrical section of the pneumatics manual. You only need one spike per cylinder. The two valves can be controlled by the FWD and REV outputs off the spike, using battery ground for the return.

or you can use two diodes, so that FWD powers one valve, and REV (reversed voltage) powers the other valve.

remember the spike has three output states: forward, reverse, and off.

I tried writing some code to get make it so when I press p1 trigger the piston will close, then wait a little then open, then allow it to be "fired" again.

But when the second wait() comes up the computer either crashes, and with it commented it, it doesn't work. What's wrong.

void wait(void)
{
time = 0;
count = 0;
for (count=0; count <10000; count++)
{
for (time=0; time < 50; time++)
{
prev = 1;
}
time = 0;
}
count = 0;
time = 0;
}
void fire(void)
{
printf("Piston Forward\r");
relay1_rev = 0;
relay1_fwd = 1;
wait();
printf("Piston Back\r");
relay1_fwd = 0;
relay1_rev = 1;
// wait();
printf("Firing done!\r");
prev = 0;
}
if (p1_sw_trig == 1 && prev == 0)
{
prev =1;
fire();
}

[KenWittlief]

you cant do wait loops like that on robot controller code.

you need a counter than increments on each 'pass through' of the code.

your wait loop is making all the code in the RC wait until the loop is done. The other uC in the RC thinks the code has gone out to lunch, so it shuts the controller down.

[Windward]

Originally Posted by KenWittlief

you cant do wait loops like that on robot controller code.

you need a counter than increments on each 'pass through' of the code.

your wait loop is making all the code in the RC wait until the loop is done. The other uC in the RC thinks the code has gone out to lunch, so it shuts the controller down.

So, what would that code look like?