boosternowbot

Eagle EPAC Controller There’s not much to it on the outside: a membrane keypad and LCD screen for the interface and the “ABC” cables at the bottom for the inputs and outputs. The “A” cable feeds AC power to the controller, DC 24 volts from the controller to run the load switches, and all the inputs and outputs for a simple 2 phase intersection. The “B” cable adds phases three and four, and the “C” cable add phase five through eight.

• Epac 300 Programming Manual

Each wire has a single fuction; there is no serial communication with the cabinet. To the lower right of the controller are serial connectors for communications equipment, generally to a master controller or a traffic control center. Most newer controllers it’s possible to hook up to a computer with serial connections, and even newer ones may have integrated USB and Ethernet ports, but this is generally only done for initial programming. EPAC stands for Eight Phase Actuated Controller, despite some early units available with only two or four phases, and newer units having 16. NEMA, conceived in simpler times, only had physical inputs and outputs (I/O) for eight phases. To use more than these, it’s necessary to electronically remap some of the I/O used for other marginal to useless features.

NEMA has many features that either were never or are no longer useful; the I/O can be remapped and reused for other things on newer controllers, for instance there is a provision to have a “yellow” light for pedestrian clearance phases. Since instead the “Don’t Walk” is flashed, and these are in the cabinet wired to a the spare center section of the pedestrian load switches, these are normally used to drive things like pre-emption lights and blankout signs. Some controllers also had a proprietary “D” connector for such things.

NEMA controllers can operate by themselves as free-running controllers, or as a master controller that coordinates many of them. The EPAC 300 series is more or less still in production as the M50 and M60, though the Eagle name has been removed and is still owned by Siemens after the Eagle signal head business was sold off to Brown Traffic. Some of the Screens Although there are many screens, these can be broken down into (1) “Status” screens, that show what the controller is doing or logs of what it’s done, and (2) “Programming” screens where you enter what you want it to do. I’m omitting anything having to do with: Density and Time of Day Programming (where cycles change based on traffic volume and time), Coordination, Logging, Communication, Start up Sequence, Preemption, and Flash Mode. These are probably of marginal interest to non-engineers, some of these I don’t understand myself, and skipping them eliminates probably 95% of the complexity. Also omitted is anything having to do with actuation.

Although some collectors will add video detection and pedestrian push-buttons to their setup (and there’s an amazing variety of buttons to collect), I have chosen not to. I have four phases with two associated pedestrian phases that run in sequence without waiting for calls. Here is the main screen: Let’s see what it’s doing first: go to 1-ACTIVE STATUS and then 7-INTERSECTION. The second line shows the phases and then “V-SIG” says they’re all red except phase 4 is green, below that P-SIG pedestrian outputs are “D” for “Don’t Walk” except Phase 4, which “d” means it’s flashing the “Don’t Walk” for the clearance interval.

All the phases with physical outputs (1-8) default to red and “Don’t Walk” all the time unless programmed otherwise. In this case 4-8 are not programmed. If there were any Calls, these would be indicated under V-CALL and/or P-CALL. The Overlaps, with letters instead of numbers are additional outputs for driving such things as a protected/permissive display where you have a green ball and green arrow in the same direction. Not all of the vehicle overlaps have designated physical outputs.

There are also pedestrian overlaps on a different screen (where you might give a “Walk” signal on one side only if there’s a green arrow the same direction; none of these have physical outputs). Now suppose we want to play with things and see where values can be entered and changed. Go back to the main screen, select 3-PHASE DATA, then 1-VEHICLE TIMES. The MIN GRN is the green time in seconds for each vehicle phase.

Phases 5-8 (and 9-16 on the second screen if you page down) have default values except for the zeros for MIN GRN, which disable them. PASS/10, MAX # 1, and MAX # 2 would extend the green if needed vehicle detection was used, since they’re not here they have no effect and the controllers default values are left in place here.

YEL/10 and RED/10 are the yellow and red times in tenths of seconds. Going back a screen and then to 3-PEDEST. Phases 2 and 4 have pedestrian signals hooked up, with WALK time at 30 seconds and PED CLR.

At 20 (5-8 will not activate since there are no associated vehicle phases and the numbers you see are default values). The FL WK will flash the walk light, now a MUTCD no-no, but previously used in DC to indicate a crosswalk where there vehicles might attempt to turn across. EXT PCL will continue flashing the “Don’t Walk” through the red and yellow vehicle phases. ACT RIW will hold the phase at “Walk” until a conflicting call come in. Going back a screen and selecting 5- V&P RECALLS, we see Recall is selected for all four vehicle phases and both associated pedestrian phases (indicated by a “2”) So it will go through the cycle and service all phases without any demand from pedestrian push-buttons or pedestrian sensors.

Entering a “1” will generate a call to test the controller in case physical test buttons aren’t provided in the cabinet. DELAY allows you to set a time before Recall is activated. Why Can’t Signals Do What We Want?

Quite often the question gets asked “why can’t a traffic signal do this, or why doesn’t it do that”. Now with a bit of understanding of controllers and cabinets, lets go over a couple of broad reasons why things are or are not done a certain way. 1) It’s required or banned. The Minnesota Manual on Uniform Traffic Control Devices (MUTCD) based on the federal one with some very minor changes, has options, strong suggestions, and absolute requirements.

Engineers are not likely to deviate from suggestions, and may not deviate from requirements. Banning creativity might preclude the best response to a specific situation, but on the flip side road users can expect uniformity nationwide.

When traveling, they’re not going to encounter a flashing purple arrow in Peoria or a pink strobe-light in Paducah and then have to try to figure out what those mean. If a city really wants to try something new out, say a red arrow on top of a standard three light signal to emphasize no turns on red (not currently a legal configuration), they can apply for permission to experiment, do a study, and then either remove it if a study shows no benefit, or it may be adopted into the MUTCD if it does. 2) It’s often a zero or negative sum game with intersection capacity a fixed resource, since pedestrians and motorists compete for the same resource, and the needs are completely opposite. Right on red or longer overall cycle times: pro-motorist, anti-pedestrian. Exclusive walk phase or leading pedestrian intervals: anti-motorist, pro pedestrian. Other people may not see it this way, and are surprised when I describe “pedestrian improvements” as “anti-motorist”, but ultimately that’s the effect even though there may have been intent to harm vehicle operations (although sometimes there is).

Additionally since pedestrians move a lot slower, sometimes a very modest benefit for pedestrians can produce an extremely severe impact for motorists, like ped recall across a wide suburban-style road. More details on some of these scenarios will be in the next part.

3) A lot of equipment on the field is very old. Even computerized controllers tend to use 1980s vintage microprocessors like the Motorola 86040, and the need for standardization dampens innovation. This is more true in the cities were demand for pedestrian amenities is greater. Until very recently Minneapolis even had electro-mechanical controllers. Old controllers may not have the capabilities that people want. But it still works and cities are not made of money. In some cases even what seems like a minor change could require a complete cabinet replacement, or even a bigger cabinet requiring a bigger concrete pad and redoing a lot of the wiring, and the cities are not likely to do that just because someone wants a leading pedestrian interval or something.

Old E/M controller Although we’ve come a long ways from a free-running E/M controller in every light, even the newest controllers are nowhere near as powerful as a PC. (You may have noticed the line “16 MHz CPU” and a 2000 firmware date on the main screen of mine.) Even if they were, in most situations the input and output are still limited, with the only input available being vehicle sensors and pedestrian buttons and only output being lights.

They can’t look at a a bunch of cameras focused on the intersection and down the block and make decisions based on it, or sound a fog horn if they see a motorist inching into the crosswalk. Things are getting better with multiple vehicle sensors that can thus measure vehicle speed (one controller even has a “feature” that will turn the light red if an approaching motorist is speeding) and the new Linux based controllers that are more flexible in certain ways. Sometime upgrading the firmware on existing equipment is possible, but besides the expense and need to go out and swap out chips or update the flash memory, engineers like to have known, stable, and consistent firmware. At least once Mn/DOT has had to back out and revert to an earlier firmware version because of bugs. Mine is running 2000 firmware and would require an upgrade to do leading pedestrian intervals. There is also the “SMART” Signal system, which tries to harvest and aggregate data gathered by standard controllers together using industrial PCs and use it to dynamically optimize timing in a way that’s not possible with traditional manual coordination.

The controller is an Econolite ASC series, the Mn/DOT standard and most widely used in Minnesota. 4) Old-Fashioned engineers. To end with the elephant in the room, sometimes it really is engineers that are just set in their ways and not taking the needs of pedestrians seriously or being open to modern ways of doing things. And it’s not just signals; they admitted the trails associated with the St.

Croix Crossing are only worked on “as we have time”. And closed down the sidewalk on the Hastings Bridge for the entire duration of the project even when there was no work being done anywhere close to it. However the point I’m trying to make is there usually more too it than some “dumb engineer sitting in a chair in Medina” not wanting to put down his donut in order to click an icon on the computer in front of him. Overall, the idea isn’t to pass value judgments or state my opinions on what is or is not a worthwhile change, even though perhaps the fact that 95% of the time I’m a motorist shows through. Rather, what I’m trying to do is lay out the reason things are the way they are. Part Three will go into specific scenarios about why things are (or aren’t) done so I would suggest holding off specific questions on “why can’t/don’t signals do this” until then.

Thanks for continuing this series. Question: Why do newer signal controllers take up more space, not less? I see replacement of E/M or other old control boxes in Mpls, replaced with one or more modern cabinets (graffiti canvases) when Mpls upgrades lights. Granted, there’s more complexity now. But given the fact that we all have devices in our pockets that are many many times more powerful than a 1990-vintage 68040 processor or even the Space Shuttle’s onboard computers, shouldn’t it be possible to miniaturize the format of these physical signal controllers?

There’s a couple of reasons: Chicken and Egg. Agencies buy NEMA cabinets because they have NEMA controllers they want to use. They buy NEMA controllers to fit in NEMA cabinets. Until recently there’s not been a push for anything different. Different physical configuration: With electronic controllers the controller is mounted on a shelf above the backpanel (due to the need to plug load switches into the panel).

A E/M controller the controller fits in front of the backpanel, and swings away for access. No strong need, since you don’t need to appeal to consumers, fit it in your pocket, etc. Redundancy: There’s a certain level of redundancy built into cabinets. The conflict monitor, flasher, and flash transfer relays all need to be seperate units from the controller so the cabinet will fall into red flash if something happens to the controller. Feature Creep: Besides redundancy, cabinets are increasingly getting detection, communications equipment, battery backup, and such. Standard Sizes: There’s only a couple of standard sizes for traffic cabinets.

Furthermore agencies may just choose one or two sizes to standardize on rather than use the smallest cabinet possible for a given configuration. The cost is not that much greater and it makes it easier to work on, allows stocking fewer items in the shop, and allows for some expansion without changing out the cabinet. With the newer form factors there has been some effort towards miniaturizations. New controllers may include communications equipement, and there’s a new form factor for load switches now that there’s no need to drive an intersection full of 150 watt bulbs (a traditional load switch can put out 20 amps at 120 volts on each channel).

Also, regarding test calls in the EPAC software. In the intersection menu press A then 1, 2, 3 and/or 4 to place test calls to ring 1. B 5, 6, 7, 8 for ring 2 vehicle. Peds 1-4 with C 1, 2, 3, 4 and Peds 5-8 with D 5, 6, 7, 8.

Press again to cancel calls from the group. Tests calls are shown with a lower case “c” Also, your minimum green times are longer than your MAX 1 time. MAX 1 is the standard maximum time a phase can be green. Then set your V RECALL to “3” for appropriate phases for MAX timing. Peds are correct with a “2” for PED. The other options for peds are for coordination and recycle a non-actuated walk in coordination for the main phase. Trackbacks/Pingbacks. Repair manual impala 2015 ls.

July 13, 2015 Three in a series on traffic signal controllers. Part One covered an overview of a hardware, and Part Two continued with general issues of why they don’t always have features we’d like. As of WORDPRESS HASHCASH The comment’s server IP (23.253.79.32) doesn’t match the comment’s URL host IP (23.253.121.1) and so is spam. Note on Comments streets.mn welcomes opinions from many perspectives.

Epac 300 Programming Manual

Please refrain from attacking or disparaging others in your comments. Streets.mn sees debate as a learning opportunity.

Please share your perspective in a respectful manner. To learn more. Thanks for commenting on streets.mn!

This guide is intended for traffic signal collectors that are new to the EPAC 300 traffic controller or any controller unit operating SE-PAC software. It does not include all the features available on the controller unit, nor does it provide any information on NEMA cabinet hardware other than TS1 operation of the controller unit.

The purpose of the guide is to get the collector programming a pre- timed intersection of up to 4 sequential phases plus 2 leading overlaps. It will also include how to set up night flash as well as choosing a second time plan. Further more advanced programming would be covered in a later version of this guide.

Starting Out with a Used Controller Unit- 4 Programming Start Up Operation - 6 Timing Vehicle Phases-7 Timing Pedestrian Phases- 8 Initializing the Phases-9 Pretimed Cycling or Actuated? -10 Leading Overlaps-11 Time of Day Operation-12 Programming MAX 2 -14 Programming Remote Flash-15 Viewing Active Status- 16 Conclusion.