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:
-
Clearence.png
110 KB
Der Vollständigkeit halber hier nochmal die Auflistung aller Clearence-Regel'n. Die ALL-ALL Regel ist noch da, aber deaktiviert. Markus
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...
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 ?
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).
Nur mal so aus Spass, mach das Pad mal: X=3mm, Y=1.5mm; Offset from Hole Center 1mm - 0mm und Rechteckig sieht doch besser aus oder ?
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
Du must die Priorität Deiner Rule ganz nach oben setzen....
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
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
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
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?
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.