View Full Version : Illuminated Switches
01-29-2003, 05:25 PM
I was reading through the IFI Operator Interface Guide just to freshen up and i came across a passage that said "Do Not use illuminated switches". Is this a Rule that we must follow or is this just a recommendation on the part of IFI?
Are the instructions in these manuals the official rules for the controllers and such?
Because as far as switches go in the manual it says we can use any switch in any quantity (i think its any quantity)....so can i use illuminated switches?
Why would using them be frowned upon by IFI?
01-29-2003, 06:21 PM
There is a rule in the rule book that prohibits illuminated switches. I can't get into Hyperrules at the moment or I'd give you the reference (must be that silly firewall they have here at work).
There IS a technical reason for the rule, but you'll have to ask one of the electricals what it is. Hopefully Al S or Rbayer or one of those guys will explain it. This has been a topic of discussion before, but I think it's been a few months or does it just seem that way? I may be suffering the usual "Build Season Time Distortion Syndrome".
01-30-2003, 07:30 AM
well if any other teams want to find out the reason i found an old thread that tells why
01-30-2003, 10:46 AM
Stolen from The_Robot.pdf, page 14
3.3.2 Sensor Inputs on the Operator Interface
The +12 Vdc LEDs may be connected between +5Vdc and Ground or between an LED output
and Ground to serve as a visual indicator to the robot operators. This can be helpful during a
competition match when a robot operator may not have a good view of the Operator Interface.
Connect switches between a switch input and Ground. Do not use lighted switches with
the Operator Interface unless the light is disabled.
You can still use these LED outputs manually, and perhaps with even greater use, than an illuminated switch, because you can trick around with them in the programming, rather than just having them on or off in conjunction with a switch. Each LED output (except for the Basic Run LED) is shared between the LEDs physically inside of the OI and a pin on either one of ports 1 and 3.
'Code exerpt from the 2003 default code, 2.0 and 2.5 versions.
Output 7 'define Basic Run LED on RC => out7
Output 8 'define Robot Feedback LED => out8 => PWM1 Green
Output 9 'define Robot Feedback LED => out9 => PWM1 Red
Output 10 'define Robot Feedback LED => out10 => PWM2 Green
Output 11 'define Robot Feedback LED => out11 => PWM2 Red
Output 12 'define Robot Feedback LED => out12 => Relay1 Red
Output 13 'define Robot Feedback LED => out13 => Relay1 Green
Output 14 'define Robot Feedback LED => out14 => Relay2 Red
Output 15 'define Robot Feedback LED => out15 => Relay2 Green
Say you wanted to have the red PWM1 LED light up whenever you press the port1 trigger. Here's all you'd have to do, if my mind doesn't fail me entirely:
out9 = p1_sw_trig
In the default code for PBASIC 2.0 (2.5 doesn't need it, with the advent of the SELECT CASE statement, but that's very interesting, as well), they do some interesting things with the modulus operator, and MIN and MAX to make the various LEDs light up when the PWM1 or PWM2 values are (close to being) maxed or minned (is that a word?) out.
As a side note, during the WRRF's Programming Workshop, before Kickoff, one of the tasks for people to complete was to make a rate display for a PWM output, both forwards, using the green LEDs, and backwards, using the red LEDs. It was very fun to just watch what people were able to do with these LEDs, seeing as how I was staffing the event (with Ken Krieger (formerly of 192, currently of WRRF) in the lead, and Mark Whitehouse (formerly of 232 and 814) as a fellow assistant.
01-30-2003, 12:55 PM
The main reason is any illuminated switch is expected to be driven by a lamp output on the OI. Those outputs are only able to sink 10 ma (milli amps) which is fine for LEDs but way low for lamps. Additionally, any operator box would receive power through the OI and by making this rule, it will keep teams from blowing fuses or killing the OI. As of yet, FIRST is not allowing separate power for the operator interface. I concur that with all the variables that would result in failures, this is a good general rule for all teams.
See Robot Control System p. 12 @
vBulletin® v3.6.4, Copyright ©2000-2015, Jelsoft Enterprises Ltd.