The Eagle Phantom Connection Menace

Interestingly, I got bitten by this with version 4.16 two weeks ago. Since I do not trust CAD 100% and never will, I tend to do a by-hand netlist check against a printed-out schematic. Sure enough I found a dead short between two large nets. Sometimes the ERC shows this as a warning, sometimes it does not. Beats me why because it would be rather simple for a CAD program to derive from the fact that two nets are not wired together and also have no visibly set net names that something could be amiss. But no ...

With Orcad Windows versions I had it the other way around a lot. Connection on the schematic but not connected in the netlist. The only CAD that never ever made a mistake was DOS-Orcad. Nothing ever reached its level of rubustness in the whole last 20 years.

If you implement a "poor man's ground plane" in Eagle by making ground polygons, then the tool will assume that anything connected to that polygon is ground -- even if it's been completely isolated from 'real' ground by traces cutting through it.

So Eagle can be _induced_ to make the 'cut up netlist' error, even if it won't necessarily do it by itself.

(To solve this you have to autoroute the board, _then_ make the ground polygon, then if you want to increase coverage you have to drop vias all over to connect your top & bottom ground planes. I do this by making my ground polygons and renaming them to "bob" when I do autoroute, then renaming them back to "GND" when it's done).

In my case it was strictly at the schematic-netlist level. I never do my own layouts, it was when I generated the netlist for a layouter that it happened. Or that I discovered the bug. IMHO that ain't supposed to happen.

Tim, please remind me, from time to time, to never get tempted to use Eagle... Well, I've never been, but now I do know why.

Never had such issues with orcad. Whatever the release...

PADS is very good about checking netlists between schematic and PCB, and very good about understanding whether copper is connecting stuff or not. We don't do any manual netlist crosschecking; that would take days on a serious board.

We do have to keep up some discipline during PCB development, so that changes to schematics generate forward ECO files onto PCBs, and that's all kept organized. Plus back ECOs for resequencing and pin swapping and such. It's not unusual to have 30 to 50 ECOs between schematic and PCB before a board is released.

It's ok if you have the time for one or more iterations. On my projects I often don't. But those are typically smaller, 1-4 sheet schematics.

Over the years I have seen beaucoup grief at clients when people fully trusted CAD. Like a whole 32bit bus not connected through by the autorouter and so on. Because the internal netlist was wrong.

Design Rule Check is the magic spell to detect problems.

Same here. What is not in the schematic does not get on the board. And I always used parts from a database so I know the footprints, order numbers, etc, are right so the BOM can be created with a sinlge mouse-click. Creating BOMs manually is tedious work.

Its amazing how people allow themselves to spend so much time on archaic tools. A good CAD package pays for itself. OTOH it may be a case of RTM. One of my former employers used Orcad with the component database integration (CIS). Before I got there they had written a seperate tool to verify whether the netlist had the proper PCB footprints. The tool was quickly abandoned after I showed that the part manager in Orcad did exactly the same (and better).

(...)

Thanks. I was beginning to question my observations there.

I liked Orcad. It could be cranky when creating library parts but otherwise I found it pretty easy to use.

--Winston

(...)

In my case, the errant traces were actual copper, 10 mils wide that entered the pads from +Y to -Y. They *had* been valid connections before my edit, but remained in place improperly after my edit.

The error has a name then. Good! :)

Next time, I'll try that.

--Winston

SDT and 386, yes, that was the ultimate cat's meouw. The windows versions, however, were IMHO mostly horrid. The occasional invisible no-connect wasn't the biggie, the numerous crashes were.

I had the ERC come out clean but ... a netlist bug. A big one, would have caused some smoke.

Beware of invisible identical node names.

(...)

Fred, please try Eagle.

This little two layer board routed very quickly and painlessly. Eagle stayed 'out of my way' for the most part. I find that creating library parts is easier with Eagle than with Orcad, (And I liked Orcad a lot).

The English version of Eagle documentation is not well written but YouTube has many good demos that translate instructions well.

Warts and all, it is a competent package. For free, it is a miracle.

--Winston

(...)

In my case, ERCs and DRCs both passed properly with copper connecting the bottom of this tie-up and associated pins directly to GND.

I had accepted notification about some Vdd pins were instead connected to this mysterious net called Vcc and that some Vdd pins were connected to the equally inscrutable net that I'd called GND. :)

Other than that, Eagle was perfectly happy.

--Winston

(...)

Can net names be 'synonomised' without being logically connected?

I did check that the net names were correct. It was *very* weird because on the same piece of copper, I saw the net named 'GND' and a few mils away, the same piece of copper had the net name of the pull-up resistor, and the net list extracted from the board showed that no such connection existed.

Just Very Strange.

--Winston

No idea.

I had the output rail of a switcher being called "+3.3V" and the 12V input rail was also called "+3.3V". That would have been a nice kablouie :-)

(...)

Oopsy. :)

--Winston

Orcad does tend to crash but when it works, it works fine. I never had problem with invisible connections. I must admit though that I'm a go-with-the-flow person. I don't spend much time customizing software to my preferences. I use the standard page sizes and accept that it doesn't print full page. I've seen several problems when people insist on using metric paper sizes in Orcad. When moving components it sometimes aligns the selection with the border which is off-grid for metric paper sizes. In some cases this produces tiny gaps between wire ends. These may be the source of unconnected nets.

Well, if they can't get the metric switch working properly, why are they offering it in the first place? Why do they not test this?

My last experience (but more with Orcad-integrated PSpice) was when I rented it last year. Major crashes, right off the bat. Support came on, and they are pretty good. After half an hour a manager joined in. Then another guy. At one point one guy exclaimed "I can't believe this is happening!". Really bad stuff such as some internal communication error. The potpourri of captured screen prints of error messages is mind-boggling.

Long story short, I am glad I am back with Eagle. That has never crashed on me.

Also set "Orphans OFF" for your polygons. I draw a polygon covering the whole intended ground plane areas on both sides of the board and name them DGND. This will autoconnect to all dgnd pins placed when you do a Ratsnest. Areas that can not be filled with ground plane will show as blank. If you have Orphans ON, you will get unconnected floating "ground plane".

With Orphans OFF, if you see a blank area, drop a few vias (and designate them dgnd) to connect and do another Ratsnest command. Voila!