Kelvin connection or different ground connection

On 05/19/2014 07:40 AM, Guillaume barrey wrote:

Hello,

 

I have a suggestion that could help us when we route kelvin connections

or when we have to connect 2 separates ground planes in only one point

("star" connection). For example when we had to connect two ground

GND-logic and GND_ANALOG  in one point only under the ADC....

For this kind of situation, even if all connexions must be connected

together, some of them play different roles and could have different

parameters (minimum width for kelvin connection).

 

Today I only found 2 ways for doing this:

1) On a schematic side,  I use one single net (same name). With this

approach, on the board side, Eagle consider that all must be

electrically connected. That is gread for DRC, but I have to manually

check that the separation is correctly done, and some time I must add

cutoff polygon (specially for GND planes). I also have no possibility to

define different min width (same net = same class), ....

 

2) Or I use 2 different nets, and a "kelvin connection part"  that I

have build in my library. Finally Eagle consider the 2 sides of this

component as 2 different nets. Great, BUT, DRC is not really happy when

I connect, the 2 nets with a manually added copper polygon or wire.

Have you looked at shorts.lbr in the download section?

HTH,

    - Chuck

Hi Chuck,

Thank you for your answer.

Chuck Huber a écrit:

 

Have you looked at shorts.lbr in the download section?

 

HTH,

    - Chuck

 

 

I didn't know this lbr exist, but it's only an example of my solution #2. And it doesn't solve the all the problems:

First problem and major one, DRC will report overlaps and clearance errors. In the case of the SHORT_ALL-50 Pachage (from SHORT.lbr) it's 4 overlaps errors per outer layers and 1 clearance error per inner layer) so 14 errors for a 6 layers. I'm designing a 6 layer board with 12 kelvin connections + one link between 2 GND... I let you do the math... 

Ok it's possible to approve errors... But, each time you move one of these the package, the errors will appear again. So you approve again, again..... If you approve too many errors, one day you approve the wrong one without notice... and Ouch ! it can be very expansive when you work on a 6 layer prototype !

According to me, the point of running DRC is not missing any potential problem, so DRC should report as errors only real errors.

If we had the ability to disable some checking when we create a package (or at least ask to transform errors in to warning), we could found a way to solve this problem. Or maybe, an other elegant way could be to use "@" to name the pin. For example, If in the lbr we name the pins P@1 and P@2, Eagle would consider that these pins are electrically connected, so the DRU will skip clearance check. I already tried... But no...

Second problem, like symbol in a schematic, I don't want to have all these kinds of component in the BOM. But this could be solve by adding an option "include/don't include in bom" for each component we create in library. This could be a great idea and very useful for other kind of components (card-edge connectors, etc... but it's an other subject.).

Last problem, is that we had to build a package for each situation (depending on the wires width, or if the overlap is between 2 wires, 1 wire and a polygon, etc...)

That why I suggest a polygon that we could draw. But this limitation is not really a big issue (for me).

I think, that we already have in Eagle almost all we need to solve the 2 first problems. Just a couple of little things missing.

Guillaume Barrey

Guillaume barrey wrote on Mon, 19 May 2014 12:56

First problem and major one, DRC will report overlaps and clearance

errors. In the case of the SHORT_ALL-50 Pachage (from SHORT.lbr) it's

4

overlaps errors per outer layers and 1 clearance error per inner

layer)

so 14 errors for a 6 layers. I'm designing a 6 layer board with 12

kelvin connections + one link between 2 GND... I let you do the math...

Yup, that's a pain.  There is a long standing request to be able to define

in the package whether the DRC should flag overlap and clearance errors

within a package.

Quote:

Ok it's possible to approve errors... But, each time you move one of

these the package, the errors will appear again.

Right, so don't do that.  Generally the workflow is to do all placement,

then routing.  Occassionaly you do want to move something around as you see

issues in placement, but that should be limited.  If you find yourself

moving things a lot, then you should start by doing a better job of

placement next time.

Quote:

like symbol in a schematic, I don't want to have all

these kinds of component in the BOM.

From the SHORT_ALL-50 name of one of the shorts, this seems to be my shorts

library that someone uploaded to the CadSoft web site.  If so, these

devices will already have a BOM attribute with value "no".  Take a look.

That's how my automatic BOM generation system knows to not include these

shorts in the BOM.  If this attribute isn't set, then either it's someone

else's library or a very old version of mine.  You can get my latest

version at http://www.embedinc.com/pic/dload.htm.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Hi,

thank you for your answers

CadSoft Guest a écrit:

 

Yup, that's a pain.  There is a long standing request to be able to define

in the package whether the DRC should flag overlap and clearance errors

within a package.

 

That would be a great evolution.

Quote:

Ok it's possible to approve errors... But, each time you move one of

these the package, the errors will appear again.

 

Right, so don't do that.  Generally the work-flow is to do all placement,

then routing.  Occasionally you do want to move something around as you see

issues in placement, but that should be limited.  If you find yourself

moving things a lot, then you should start by doing a better job of

placement next time.

You right, the work-flow is to do a good placement first. And if I start some routing before a complete placing, it's only a quick crappy routing , just for checking if there is enough room for routing. And I un-route it...

And the DRC comes later in the work-flow. So for me the "move around" it's not really an issue. It's just that if it's append, you have to approve errors again and be very carrefull when you re-approve errors. And in that case you have 12 errors for one little kelvin connections.

I also always  re-check the my 'approved errors' at the end of the job, but like I says they are too numerous ! (precisely on my current board with 12 Kelvin connections). So Please Mr Cadsoft, We Beg you for this ability to flag errors in lbr packages !!!!

From the SHORT_ALL-50 name of one of the shorts, this seems to be my shorts

library that someone uploaded to the CadSoft web site.  If so, these

devices will already have a BOM attribute with value "no".  Take a look.

That's how my automatic BOM generation system knows to not include these

shorts in the BOM.  If this attribute isn't set, then either it's someone

else's library or a very old version of mine.  You can get my latest

version at http://www.embedinc.com/pic/dload.htm.

I download the library on the CadSoft web site, and the BOM attribute is already set to "no". But the BOM.ulp (eagle-6.5.0) or bom_w_attr_v2.ulp from cadsoft generate a bom with the "SHORT" device. Witch ulp you use ?

Guillaume Barrey

Guillaume barrey wrote on Mon, 19 May 2014 14:47

I download the library on the CadSoft web site, and the BOM attribute

is

already set to "no".

That definitely sounds like my library.  I hope whoever uploaded it to the

CadSoft web site gave me proper attribution.  I distrubute lots of my stuff

for free, so I don't mind there being copies out there, but I do want

people to know where they came from.  If this hasn't been done, CadSoft is

violating my copyright.

Quote:

But the BOM.ulp (eagle-6.5.0) or *bom_w_attr_v2.ulp

(http://www.cadsoftusa.com/downloads/file/bom_w_attr_v2.ulp)* from

cadsoft generate a bom with the "SHORT" device. Witch ulp you use ?

My own, of course, which is also included in my Eagle Tools Release along

with the shorts library and all the other stuff.  I have had a BOM

generation system using the user-definable attributes that were first

available in version 5.  Unfortunately when CadSoft created their own, they

used different conventions.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

I never take time to learn ulp language.... I think it's time for me to look at it.

I will try to adapt the BOM.ulp (eagle-6.5.0) or bom_w_attr_v2.ulp to my need. That will be a good first project to learn ulp !

I hope one day we could have the ability to flag DRC errors for library package...

Thank you again.

On 05/19/2014 03:24 PM, Olin Lathrop wrote:

Guillaume barrey wrote on Mon, 19 May 2014 14:47

I download the library on the CadSoft web site, and the BOM attribute

is

already set to "no".

 

That definitely sounds like my library.  I hope whoever uploaded it to the

CadSoft web site gave me proper attribution.

I uploaded it with several additional packages.  And you're right, I

should have mentioned its origination.

Let it hereby be publicly known that Olin Lathrop is a contributor to

the shorts.lbr library as posted on the Cadsoft web site.

I wonder if Jorge can update the description of the download.

Best regards,

    - Chuck

On 05/19/2014 03:24 PM, Olin Lathrop wrote:

Guillaume barrey wrote on Mon, 19 May 2014 14:47

I download the library on the CadSoft web site, and the BOM attribute

is

already set to "no".

 

That definitely sounds like my library.  I hope whoever uploaded it to the

CadSoft web site gave me proper attribution.

I uploaded it with several additional packages.  And you're right, I

should have mentioned its origination.

Let it hereby be publicly known that Olin Lathrop is a contributor to

the shorts.lbr library as posted on the Cadsoft web site.

I wonder if Jorge can update the description of the download.

Best regards,

    - Chuck

 

I uploaded it with several additional packages.  And you're right, I

should have mentioned its origination.

 

Let it hereby be publicly known that Olin Lathrop is a contributor to

the shorts.lbr library as posted on the Cadsoft web site.

 

I wonder if Jorge can update the description of the download.

 

Best regards,

     - Chuck

 

Hi Chuck,

I don't have rights to alter anything on the site. I believe under you

profile under Cadsoftusa.com you may be able to edit it. If not contact

ric@cadsoft.de and he'll correct it for you.

hth,

Jorge Garcia