Altium: Design Rule mit PadClass tut's nicht

Gast #3579231
Lesenswert?

Hallo,

ich habe hier eine Platine, wo ein Befestigungsloch direkt an den Rand 
gesetzt werden muss.
Beim DRC gibts immer eine Violation der Clearence Rule (all-all), so 
dass ich mir überlegt habe, das Befestigungsloch von dieser Regel 
auszunehmen.

Hierzu habe ich eine PAD Class angelegt und die Clearence Regel 
entsprechend abgeändert (not in padclass).
Leider gibt's immer noch eine Violation.

Wo liegt der  (Denk-)Fehler ?

Vielen Dank,

Markus


PS: klar, ich könnte die Geometrie des Befestigungsloches anpassen. 
Trotzdem interessiert mich, warum die Regel nicht funktioniert...
Angehängte Dateien:
Gast #3579272
Lesenswert?

Hallo,

ich nehme an das ist die Linie vom Keeout-layer!

Clearence funktioniert zwischen elektrischen Netzen und nicht zwischen 
Pad und Keepout-Linie.

Alternativ kannst du ja den Linie um die Bohrung herumführen oder bei 
Placement suchen, ob das eine Regel besser zutrifft...
Gast #3579290
Lesenswert?

Ralf schrieb:
> Clearence funktioniert zwischen elektrischen Netzen und nicht zwischen
> Pad und Keepout-Linie.

Sorry, Versteh ich nicht. Das Problem ist ja gerade, dass die Clearence 
Regel zuschlägt (und dabei die Bedingung "not in PadClass" ignoriert).

Wenn ich GND vom Pad wegnehme, gibt's keine Violation. Insofern stimmt 
es, dass Clearence nur bei (zumindest einem) elektrischen Netzen 
funktioniert.

Die Frage ist halt, warum wirkt die Bedingung "not in PadClass" nicht ?
Gast #3579332
Lesenswert?

Du müsstet die Padclass explizit ausschliessen.Also nicht not in 
Padclass (das wäre das Gleiche wie all to all) sondern

inPadclass('Loch') to all
und die Clearances auf 0 setzten dann darf es den KeepOut berühren.
Aber es geht leider nicht mit negativen Werten.

Wenn es nur ein Befestigungsloch ist, dann nimm das GND-Netz weg. So 
sollte der Clearance Check nicht anschlagen.



PS: Die Bohrung ist sehr nah am Rand, könnte ein Anruf vom 
Platinenhersteller geben.

PPS: Im zweiten Screenshot hab ich gesehen, das Du die all to all 
disabled hast das kann ganz schön Ärger für das System bedeuten und 
unvorhergesehene Dinge auslösen (einige Elemente bleiben unbearbeitet). 
Grundsätzlich ist die all to all IMMER die letzte Regel (niedrigste 
Prio).
Gast #3579430
Lesenswert?

Taz schrieb:
> Du müsstet die Padclass explizit ausschliessen.Also nicht not in
> Padclass (das wäre das Gleiche wie all to all) sondern

> PPS: Im zweiten Screenshot hab ich gesehen, das Du die all to all
> disabled hast das kann ganz schön Ärger für das System bedeuten und

Ich habe ja die all-all regel so angepasst (und umbenannt), dass alles 
ausser des Befestigungsloches geprüft werden soll. Die Regel bleibt 
also (mit aussnahme des Loches) erhalten. Zumeíndest war so meine 
Überlegung.

> inPadclass('Loch') to all
> und die Clearances auf 0 setzten dann darf es den KeepOut berühren.

Nee, geht leider nicht. Gibt ne Violation "(collision <0mm)"

>
> Wenn es nur ein Befestigungsloch ist, dann nimm das GND-Netz weg. So
> sollte der Clearance Check nicht anschlagen.
Stimmt, schlägt nicht an. Das ist aber keine Option. Über dieses Loch 
wird GND mit dem Gehäuse verbunden. (Ist also nicht nur ein 
Befestigungsloch).

>
> PS: Die Bohrung ist sehr nah am Rand, könnte ein Anruf vom
> Platinenhersteller geben.

Wurde so schon (in einer älteren Version) produziert. Ist also wohl kein 
Problem. Trotzdem danke für den Hinweis.

>Nur mal so aus Spass, mach das Pad mal:
>X=3mm, Y=1.5mm; Offset from Hole Center 1mm - 0mm
>und Rechteckig

Ok. Das ist auch ne gute Lösung.

Ich habe mich jetzt für dem Workaround von Ralf entschieden, die KeepOut 
Linie um das Loch herumzuführen (bzw. zu unterbrechen).


Vielen Dank für Eure Hilfe,

Markus
Gast #3579543
Lesenswert?

Markus schrieb:
> Ich habe ja die all-all regel so angepasst (und umbenannt), dass alles
> ausser des Befestigungsloches geprüft werden soll. Die Regel bleibt
> also (mit aussnahme des Loches) erhalten. Zumeíndest war so meine
> Überlegung.

ist ja auch richtig, nur sollte generell eine all to all Regel an 
letzter Stelle stehen (wird im AltiumLive Forum dringlichst drauf 
hingewiesen) auch wenn eigentlicht schon alles vorher abgedeckt sein 
sollte - schaden kann es ja nicht .
Für dein Pad z.B. trifft keine Regel zu, hast Du ja ausgeschlossen also 
ist dein Pad quasi 'undefined', was uns zu deinem ursprünglichen 
Denkfehler führt.

Mit 'not in Padclass' machst Du eine Regel für alles AUSSER deinem Pad, 
Du wolltest aber eine Regel, die für dein Pad gilt und die Berührung 
erlaubt.


Markus schrieb:
>> inPadclass('Loch') to all
>> und die Clearances auf 0 setzten dann darf es den KeepOut berühren.
>
> Nee, geht leider nicht. Gibt ne Violation "(collision <0mm)"
Bei mir funktioniert es, ich komme bis fast ganz dran
Gast #3579566
Lesenswert?

Taz schrieb:
> Für dein Pad z.B. trifft keine Regel zu, hast Du ja ausgeschlossen also
> ist dein Pad quasi 'undefined', was uns zu deinem ursprünglichen
> Denkfehler führt.
Genau deshalb verstehe ich nicht, was zu der violation führt. Es gibt ja 
keine Regel, welche auf das Pad zutrifft und diese Violation auslösen 
könnte.

> Mit 'not in Padclass' machst Du eine Regel für alles AUSSER deinem Pad,
> Du wolltest aber eine Regel, die für dein Pad gilt und die Berührung
> erlaubt.
Ich wollte dass die all-all regel das Pad nicht trifft, also eine Regel, 
die für alles ausser dem Pad gilt. Es gibt also keine Regel für das Pad 
also auch keine Violation (dachte ich).

>
> Markus schrieb:
>>> inPadclass('Loch') to all
>>> und die Clearances auf 0 setzten dann darf es den KeepOut berühren.
>>
>> Nee, geht leider nicht. Gibt ne Violation "(collision <0mm)"
> Bei mir funktioniert es, ich komme bis fast ganz dran

Ok. Das war ein Verständigungsproblem: fast ganz dran geht, aber eben 
nicht drüber.

Markus
Gast #3579616
Lesenswert?

So,

ich glaube, ich habe jetzt den Grund gefunden, warum die Regel immer 
noch anschlägt: es müssen beide Object's mit "not in Padclass" 
ausgewählt werden.

Ist aber wohl, wie ich jetzt gelernt habe keine saubere Lösung: die 
all-all Regel, die ja dringend empfohlen wird, würde trotzdem noch 
zuschlagen...

Markus
Gast #3579696
Lesenswert?

Markus schrieb:
> Es gibt also keine Regel für das Pad
> also auch keine Violation (dachte ich).

Ich weiss auch nicht wie Altium das intern verarbeitet, aber ich stell 
mir das so vor als ob man mit einer nicht initialisierten Variable 
arbeitet meist hat man Glück und sie ist Null aber halt nicht immer und 
erst Recht nicht verlässlich. Wenn das Pad durch die Routine vom 
Clearance Check geschickt wird und kein IF trifft zu, was soll dann raus 
kommen?
Gast #3579815
Lesenswert?

Taz schrieb:
> erst Recht nicht verlässlich. Wenn das Pad durch die Routine vom
> Clearance Check geschickt wird und kein IF trifft zu, was soll dann raus
> kommen?

Naja, "keine Violation" halt. Eben das gleiche, als wenn garkeine Regel 
vorhanden wäre...

Aber egal. Ich hab ja einen Workaround der funktioniert.

Markus

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren