How to you JOIN  two grounds, i.e VSS   & GND signals?

Guillaume barrey wrote:

 

Kelvin connection are not really frequent,

How do you know that?

Almost all my projects contain at least one kelvin connection (or starpoint).

Check some random datasheets of ADC-chips, most of them have a separate analog and digital ground that needs to be connected to each other at some point.

This is just one example, there are plenty more.

Cadsoft, is it really that hard to implement a joining via or pad in order to avoid DRC errors?

Best Regards,

Joop

Hi,

Start point connection for ground, start connection is as a Kelvin connection. However, I prefer to make a little difference between a simple Kelvin connection (use a separate line for a measuring the voltage difference on a shunt  for example) and a start connection for ground and supply planes.

This is not a theoretical difference ( you always separate the currents lines), but a practical difference.

The difference is

- on a single kelvin connection you separate a wire (or several wires) from an other wire(s).

- In case of In separate planes with start connection, you have to separate wire or polygon from other polygons.

In the first case,it's often easy easy to do it, without using different net names. You just have route manually a wire and that's it.

Eagle is not aware that there is a difference between branches (or a Kelvin connection), and for ERC/DRC you have no problems.

It's quite rare you have some trouble to do it. Once I had trouble. The problem was that one branch was made with a polygon because it was a dissipation area.

And it was a pain to separate the little measuring branch through the polygon.

That why I said that is 'not really frequent'. I should have said  'Im not frequently have to connects 2 separates nets ( different names) to create a simple kelvin connection'.

In a second case, it's better to use separate names. Because if we don't Eagle will mix all the connection, with planes. Also because It better to show the difference in the schematic too. But that solution

And that happen really often.

If you read carefully what I wrote, I said that

separate plane is quite common

And in that case, It would be great to have a way in Eagle tell Eagle that we want to make a Kelvin, without the DRC errors and all of that troubles.

And I'm sure that if there is a easy, DRC error free, way to do it, I will use it in all cases.

Guillaume Barrey

On 23/08/14 11:29, Guillaume barrey wrote:

However, I prefer to make a little difference between a

simple Kelvin connection (use a separate line for a measuring the

voltage difference on a shunt  for example) and a start connection for

ground and supply planes.

 

In the first case,it's often easy easy to do it, without using different

net names. You just have route manually a wire and that's it.

Actually, for the example you give, of a measurement circuit across a

load sensing resistor/shunt, I would never do it that way. Whenever I've

wanted to do that I've employed a custom component with the footprint of

the shunt resistor but split pads (if SMD) or extra pseudo-pads (if

through hole). The schematic symbol is a resistor with two pins at each

end, the straight ones being the large pads and the side ones being the

sense pads. That way it's explicit what you're doing.

I've employed a custom component with the footprint of

the shunt resistor but split pads (if SMD) or extra pseudo-pads (if

through hole).

This solution creates a DRC-error as wel (when using different nets connected to the pins at the same side and assuming that the pads are overlapping or connected somehow).

On 23/08/14 15:35, Joop14 wrote:

I've employed a custom component with the footprint of

 

the shunt resistor but split pads (if SMD) or extra pseudo-pads (if

 

through hole).

This solution creates a DRC-error as wel (when using different nets

connected to the pins at the same side and assuming that the pads are

overlapping or connected somehow).

 

If you join them on the PCB, yes.

The version attached doesn't generate DRC errors. It also doesn't

connect the sense nets to the high current nets, but instead to the

resistor itself. This means it's measuring the voltage across the

resistor itself rather than the resistor plus the solder (which is a

completely irrelevant consideration in most cases but not when dealing

with very low impedance sense resistors). Of course, it does rely on

accurate part placement and may cause other assembly issues that I'm not

aware of, so I'm happy to be informed of the error of my ways by

somebody more expert.

Attachments:

Hi,

I've employed a custom component with the footprint of

the shunt resistor but split pads (if SMD) or extra pseudo-pads (if

through hole).

This solution creates a DRC-error as wel (when using different nets connected to the pins at the same side and assuming that the pads are overlapping or connected somehow).

Joop14 is perfectly right, and that's the problem of Eagle:

- even if we design a custom component ( 'a special shunt resistor' or fake component that connect to wire) we are stuck this annoying DRC error. You can approve the error, OK . But when you have too much errors to approve, the possibility of approving a real error increase , and at the end DRC is useless . (I'm currently design a board, and believe me, the number of error due to that problem is huge ).

- Making custom made component like your shunt resistor have other limits too: In BOM it will not be group with other component of same size/value.

- If you don't mind create some trouble for the mounting :OK. Else, your solution can generate some trouble (specially with small components).  You could have component displacement during soldering. On large component this could be OK. And it's not applicable for TH components !

As I said, today, I prefer to use the same net (same net) because it's easier, and don't generate DRC errors. But if one day, there is a new 'Kelvin' special component, I will use it for all my Kelvin connection, and I will use separate net names .

A last comment on that possible feature: this feature will make more useful the 'width' parameter in net classes. Today this 'width' only make sense for differential pair. For other signals, it's simply useless.

Guillaume Barrey