Potential bug - trace to polygon

[m3atwad]

Hello,

I've noticed that eagle seems to have a hard time figuring out when a track/trace connects to a polygon pour of the same net.  The DRC flags this as a warning.  This should not be a warning - could this be a bug or am I missing something?

[m3atwad]

forgot to attach my screenshot.

[jorge_garcia]

Hello @m3atwad,

I hope you're doing well. What's the specific error you are seeing? EAGLE normally detects traces that connect to a polygon. In your case it seems like it did because the polygon swallowed the trace. That makes me think that the warning or error is related to something else.

Let me know if there's anything else I can do for you.

Best Regards,

[m3atwad]

Hi Jorge,

Thank you for your time and great job on the webinars recently they have been very good!

I've attached the error in the following screenshots.  It looks like eagle DRC cannot recognize when a trace is connected to a polygon.

[jorge_garcia]

Hi @m3atwad,

I hope you're doing well. Run ratsnest before running the DRC, does the wire stub warning still show up?

Let me know.

Best Regards,

[m3atwad]

It still shows up. Rats nest has no effect.

[one-of-the-robs]

The end of that trace doesn't go anywhere. It may form a connection to the polygon but my eyeball estimation says it does so at both ends of that segment. So I'm not surprised it shows a stub error.

Eagle will not show a stub error if you route all your traces to something. As I find myself frequently saying, you shouldn't expect a polygon to form a connection - make all your connections with the route tool, then use polygons to fill unused space. This keeps you in control of your design, allows you to ensure all connections are proper, and avoids DRC errors.

[havlicek6TH3H]

Your way is one approach (not wrong) but I would prefer if the Eagle could detect that the signal is connected to polygon. When I have to join all traces to one specific point of polygon net there is lot of "not existing" traces and it little bit changes the view on the board. If you shouldn´t expect a polygon to make a connection what makes you expect that the trace create the connection (ad absurdum). 

[m3atwad]

There are two problems here.

#1 - This definitely should not be an error.  In board design all DRC errors need to be fixed before fab because they indicate a fabrication issue or a rule needs to be adjusted.  This issue is not a fabrication issue and works in most other ECAD design tools.  The error is indicating a lack of copper connection which would cause a fab issue.  This is in fact not the case.  What the error indicates is wrong by definition.  The drc check should be accurate and clearly indicate an issue in need of resolution by a layout change or a rule change.  This should not be open to interpretation or involve a work around.

#2 - The second problem is that the work around by connecting to the center of a pad somewhere creates 'N' unnecessary tracks/traces.  These clutter up the artwork and in complex boards create an absolute mess.  This has a serious impact on the user interface and the reliability of the design moving forward.  

This behavior is fine with a hobby tool and I'm sure thats where this came from.  I assume it is a hold over from cadsoft and thats fine.  I'm not knocking the eagle team - they have done some very impressive improvements, but they need to be be aware that hobby behavior like this MUST be removed for this to be a professional product.  This is an example of something that should be a high priority item on the dev's action items as it relates to the accuracy of design rules and their application and has a direct impact on design quality.  I like eagle, but the number of work-arounds has to continue to come down.  

Please capture this action item and properly think through how to move forward.  

I'm still impressed with the progress you guys have made so keep up the good work.

[jorge_garcia]

Hi @m3atwad,

I hope you're doing well. In regards to #1 it's not flagging an error. It's flagging a warning, which is different. EAGLE is just saying check this out and make sure this is what you want to do. We do something similar in the ERC. I hesitate to say it shouldn't flag the warning even if the wire is consumed by the poly, you're not following best practices of terminating the trace at a via or pad. #2 is not a workaround, it how things work in EAGLE. I don't see how that requirement hinders UI or reliability of a design, rather it would improve it. If you describe this a little more I could likely understand your viewpoint better.

With that said the DRC is in need of some serious attention to make it more useful and easier to work with. We'll keep this in mind when it comes time to work on the DRC.

Thanks again for the suggestion.

Best Regards,

[m3atwad]

Hi Jorge!

I was wrong regarding error vs warning - it is a warning.  The real issue here is a little more complicated with eagle the more I thought about it today.  

The UI/clutter problem I mentioned is due to the requirement to route to a pad/via only and this is is based on the eagle flow.  Because Eagle doesn't support transparency of polygons while poured I have to do a ratsnest to connect all the nets then an "un-ratsnest" to "unpour" all the polygons I have so I can see my routing.  If this isn't done the polygons cover up all layers below and prevent me from seeing a lot of routing/tracks, features etc...because the polygon covers them up.  This has driven me to do the un-ratsnest command to route and when I need to check connectivity I do the ratsnest.   Hopefully this makes more sense.  So long story short all routing (as far as I can tell) realistically must be done while the ploygons are NOT poured - i.e. the hashed outlines of the polygon geometry. 

So with that work flow described above, I don't have an issue with flagging a route connection to a polygon as "not connected" when the un-ratsnest command is executed and the polygon is NOT poured.  Because you can fab hatched, outline etc...this is a good warning as it would indicate the polygons are not poured and because the polygon is not poured the track there fore cannot be connected to the target net.  

The issue I have is that when the polygons are poured and a track connects to it as above - this should be acceptable.  I would push this because of my #2 comment.  Being forced to route a track directly to a pad inside a polygon pour clutters the layout because realistically (as mentioned above) the user must route tracks while polygons are NOT poured.  Now, if I'm required to route directly to a pad inside a polygon pour every time I have extra tracks that really don't add value inside the polygon and become the polygon copper.  When I un-pour the polygons I have extra tracks that pile up and clutter the layout and create confusion.  This is especially common in power supply design where polygon pours are used to cover multiple pads as well as sense signals.  

So long story short, the workflow I've been doing because it is the best I can find is to do all my trace/track routing with polygons unpoured.  If you then have to route individual tracks through the polygon to a pad or via somewhere you get a track running through the polygon that really isn't meaningful.  As you add more of these you get many tracks that aren't meaningful and start to create confusion.  

For now I can just approve all the warnings that pop up, but it would be nice if this was a little more accurate.  Especially if you guys are looking at DRC improvements.

Another DRC improvement (just an FYI) is to allow the DRC to determine connections to pads based on the trace width rather than locking to the exact center of the pad.  I spend a lot of time running down connections that are barely off the center sometimes.  It is hard to see the airwire when there is a very very small offset.

Thanks for the support!

[jorge_garcia · Accepted solution]

Hi @m3atwad,

I hope you're doing well. Thanks for the explanation, there are definitely a few things to unpack here. I'll try to go through them in order. The first thing I want to address is that when you produce gerbers EAGLE will always export them as poured even if you don't currently have them poured on your layout. I think you know that but I want to make sure it's clear. I definitely agree about the lack of transparency on the polygons, we used to have that in older version and I'm a proponent of getting that transparency back.

I get the concern of the extra tracks and I'll talk to our DRC developer about this. He'll be reading your comments and see how we can better address this in the future. Basing the DRC connection off of trace width can be dangerous. If the full thickness of the trace isn't touching the pad, then it may approve a connection that isn't structurally sound. Connecting to the center of a PAD usually isn't an issue since the route command will snap to the center of the pad once you are close enough. Are you using a really fine grid or have you altered the snap settings in Options > Set > Misc?

Let me know if there's anything else I can do for you.

Best Regards,

[m3atwad]

I'll check on my grid - maybe increasing it will help me snap to the center of the pads.  Yea, I agree maybe trace width isn't a great idea.  Either way - thanks for the support and all the hard work.  It is very nice hearing from you and knowing you guys look at these forums for development feedback.  

One side note for you regarding the webinars - a good potential video would be to show how to use eagle to fan out a large bga from library creation to a basic fan out.  Something like a 600+ ball FPGA or something.

[cad.line]

Hallo , 

hello, I have a similar problem, EAGLE has a bug, the drc does not show disconnected signals and neither does the ratsnest,
 but I have a signal disconnected from the polygon.This is only if the polygon has thermals.
Look at pin n. 4