The Eagle autorouter is a decent tool, and I use it a lot. However, like any tool, you have to know how to use it well and understand its limitations. If you are just expecting to throw everything at the autorouter, you will be dissappointed. No current auto router, and probably for a number of years to come, can do that for anything beyond contrived or toy problems.
You say there are settings in the Eagle autorouter you don't understand and never mess with. This is a bad attitude, and probably a good part of your problem. There is no set of control parameters that works on all boards. Even within 2 layer boards there are various tradeoffs. You absolutely have to read the manual and adjust the parameters for your particular situation.
For two layers boards, I often try to keep most of the bottom layer a ground plane. I therefore use the top layer for interconnects as much as possible, and the bottom layer for short "jumpers" to make the routing topology work out. In this case, I set a high cost for routing in the bottom layer.
Before autorouting, you have to look at the board and think about the critical areas that you can't explain to a autorouter. For example, you want to keep the loop currents of a switching power supply local and off the main ground plane. The same holds true for high frequency currents local to a digital chip, like bypass caps and crystal with its caps. If you are using the pseudo ground plane layer as I described above, then you want to manually connect every ground connection immediately to the ground plane with its own via. That leaves maximum room on the top layer for routing everything else.
The process of routing a board even when letting the auto router do most of the grunt work looks like this:
- Manually route the critical paths, as I mentioned above.
- Do basic housekeeping pre-auto routing. This includes connecting all the ground pins directly to the ground plane for example.
- Look for problem areas where you can see the autorouter might get itself into trouble. If there are short connections in dense areas you might want to make some of them. This takes some experience and intuition, so if you're new to the particular autorouter, skip this step for now.
- Save a copy of the board, then run the auto router. If this is the first thru here, just have it do the minimum to find a solution. The purpose of the first few times is to see where the problem areas are so you can adjust the layout and your manual pre-route accordingly.
- Look carefully at the resulting route. See where the problem areas are. Revert back to the saved copy from step 4 and adjust your layout and manual pre-route according to what the auto router did. Repeat back to step 4 until the result looks reasonable. As you do more iterations thru here, you crank up the autorouter optimizations and other parameters to make a more final route. In the beginning you are just trying to see if it can find a solution and what the large problems are. In later passes you converge on a real route. I start out with no optimization passes, and use 8 for final routes. I also configure early passes to find a solution, then later passes to optimize it.
- Do manual cleanup on the route. In the case of a two layer board with mostly ground on the bottom, you want to minimize the maximum dimensions of islands in the ground plane. It is better to have a large number of small islands than fewer large islands. Sometimes you can see ways of rearranging signals locally to minimize the jumpers on the bottom layer. In this stage, the big picture has already been taken care of and you are focusing on manually optimizing small areas. This is similar to a peephole optimizer of compilers.
Here is a Eagle autorouter control file I used on a two layer project with the bottom layer a ground plane to the extent possible:
; EAGLE Autorouter Control File
[Default]
RoutingGrid = 4mil
; Trace Parameters:
tpViaShape = Round
; Preferred Directions:
PrefDir.1 = *
PrefDir.2 = 0
PrefDir.3 = 0
PrefDir.4 = 0
PrefDir.5 = 0
PrefDir.6 = 0
PrefDir.7 = 0
PrefDir.8 = 0
PrefDir.9 = 0
PrefDir.10 = 0
PrefDir.11 = 0
PrefDir.12 = 0
PrefDir.13 = 0
PrefDir.14 = 0
PrefDir.15 = 0
PrefDir.16 = *
Active = 1
; Cost Factors:
cfVia = 50
cfNonPref = 5
cfChangeDir = 2
cfOrthStep = 2
cfDiagStep = 3
cfExtdStep = 0
cfBonusStep = 1
cfMalusStep = 1
cfPadImpact = 4
cfSmdImpact = 4
cfBusImpact = 0
cfHugging = 3
cfAvoid = 4
cfPolygon = 10
cfBase.1 = 0
cfBase.2 = 1
cfBase.3 = 1
cfBase.4 = 1
cfBase.5 = 1
cfBase.6 = 1
cfBase.7 = 1
cfBase.8 = 1
cfBase.9 = 1
cfBase.10 = 1
cfBase.11 = 1
cfBase.12 = 1
cfBase.13 = 1
cfBase.14 = 1
cfBase.15 = 1
cfBase.16 = 5
; Maximum Number of...:
mnVias = 20
mnSegments = 9999
mnExtdSteps = 9999
mnRipupLevel = 50
mnRipupSteps = 300
mnRipupTotal = 500
[Busses]
@Route
Active = 1
cfVia = 10
cfChangeDir = 5
cfBusImpact = 4
cfPolygon = 25
cfBase.16 = 10
mnVias = 0
mnRipupLevel = 10
mnRipupSteps = 100
mnRipupTotal = 100
[Route]
@Default
Active = 1
[Optimize1]
@Route
Active = 1
cfVia = 99
cfNonPref = 4
cfChangeDir = 4
cfExtdStep = 1
cfHugging = 1
cfPolygon = 30
cfBase.16 = 10
mnExtdSteps = 20
mnRipupLevel = 0
mnRipupSteps = 100
mnRipupTotal = 100
[Optimize2]
@Optimize1
Active = 1
cfNonPref = 3
cfChangeDir = 3
cfBonusStep = 2
cfMalusStep = 2
cfPadImpact = 2
cfSmdImpact = 2
cfHugging = 0
cfPolygon = 40
mnExtdSteps = 15
[Optimize3]
@Optimize2
Active = 1
cfVia = 80
cfNonPref = 2
cfChangeDir = 2
cfPadImpact = 0
cfSmdImpact = 0
cfPolygon = 50
mnExtdSteps = 10
[Optimize4]
@Optimize3
Active = 1
cfVia = 60
cfNonPref = 1
cfPolygon = 60
cfBase.16 = 12
[Optimize5]
@Optimize4
Active = 1
cfVia = 40
cfNonPref = 0
cfPolygon = 70
cfBase.16 = 14
mnExtdSteps = 5
[Optimize6]
@Optimize5
Active = 1
cfVia = 20
cfBase.16 = 16
[Optimize7]
@Optimize6
Active = 1
cfBase.16 = 18
[Optimize8]
@Optimize7
Active = 1
cfBase.16 = 20
Yup, that's a issue with Eagle, at least as of version 5. It would be nice if you could tell the DRC check to ignore anything resulting from stuff wholly inside a package, but you can't. There has been talk of changing that, but I don't know where that is at with regard to version 6. It doesn't matter anyway since version 6 isn't ready for any real use yet for a while.
Best Answer
Once you have created the package with the four required pins, and created a symbol with two pins (typical depiction for a switch on schematics).
Go to the device creator and add in the symbol and the package as you would normally for a device. Then click on the connect button which brings up a dialog enabling you to connect the symbol pins to the package pads/pins.
As you may or may not know, there is the "append" button, and this tells eagle that two or more of the package pins are internally connect and appears something like this.
Once you have done this, if you click on the blue pipe/line looking things next to the pin name, the blue line connecting the two green circles will be removed - this tells Eagle that there is no need for a physical connection between these two (or more) on the PCB. This is what is should look like if done correctly.
As an example, see below of how it might look (ignore the very poor design of the package indicating the the two diagonal pins are connected - it was rushed but shows the premise).
You can see that two of the pins think they should be connected together (intentional) and the other two are internally connected but are not required to have a track present.
Basically, if you ratsnest it, it will link to the nearest one of the two pins, I imaging it will do the same for auto-routing. But basically, don't auto-route - it is not good.