PCB Health Check w Altium Designer – szybki test projektu, który musisz znać

Udostępnij

Pracując w znakomitej większości środowisk EDA, łatwo przyzwyczaić się do dwóch klasycznych etapów kontroli projektu: testu ERC po stronie schematu oraz DRC po stronie PCB. Poprawny wynik obu testów nie zawsze oznacza jednak, że sam dokument płytki jest w dobrej kondycji.

Wielokrotna edycja ścieżek, polygonów i innych obiektów na płytce drukowanej powoduje, że z czasem w pliku mogą gromadzić się błędne lub niepotrzebne fragmenty geometrii, nieaktualne parametry itp. Takie problemy nie muszą wprawdzie od razu spowodować zwarcia czy nawet naruszenia reguł projektowych, ale potrafią ujawnić się podczas generowania dokumentacji produkcyjnej, panelizacji lub eksportu do formatów pośrednich. Aby przeciwdziałać takim iryującym (a często wręcz szkodliwym) sytuacjom, twórcy programu Altium Designer opracowali narzędzie o nazwie PCB Health Check. Pozwala ono na szybką kontrolę „higieny” dokumentu PCB i zdecydowanie warto z niego skorzystać przed finalnym uruchomieniem DRC oraz przygotowaniem paczki plików Gerber.

ERC, DRC i PCB Health Check – podobny cel, inne warstwy problemu

Każdy konstruktor doskonale zdaje sobie sprawę ze znaczenia DRC, czyli Design Rule Check, który weryfikuje poprawność dokumentu PCB i sprawdza projekt względem spełnienia zdefiniowanych przez projektanta reguł. W tej grupie znajdują się wszystkie „twarde” wymagania dotyczące m.in. odstępów izolacyjnych, szerokości ścieżek, rozmiaru otworów, niedokończonych połączeń, zwarć i innych aspektów ważnych z punktu widzenia bezpieczeństwa elektrycznego, niezawodności oraz oczywiście wykonalności w ramach docelowego procesu produkcyjnego. Z kolei ERC, czyli Electrical Rule Check – jak sama nazwa wskazuje – skupia się na analizie błędów (lub potencjalnych błędów) na poziomie schematu. Wykrywa m.in. zwarte ze sobą wyjścia układów, niepodłączone (wiszące) wejścia, konflikty sieci zasilających itp. Obydwa te mechanizmy doskonale się uzupełniają, pełniąc rolę nadzorcy, który „patrzy na ręce” konstruktorowi i wykrywa problemy, które człowiek (zwłaszcza po dłuższym czasie pracy nad danym projektem) może po prostu przeoczyć.

PCB Health Check nie zastępuje żadnego z tych mechanizmów – nie taka jest bowiem jego rola. Narzędzie to pełni raczej funkcję dodatkowego przeglądu jakości danych zapisanych w pliku *.PcbDoc. Wykrywa sytuacje, które mogą pozostać niewidoczne dla użytkownika bądź wyglądać niewinnie podczas zwykłej edycji płytki, ale są niepożądane z punktu widzenia stabilności projektu, eksportu danych, współpracy CADem mechanicznym, panelizacji lub przygotowania dokumentacji produkcyjnej. Innymi słowy: jest to szybki test, który pomaga znaleźć problemy wymykające się narzędziom ERC i DRC oraz umożliwia „wysprzątanie” dokumentu PCB, by usunąć rozmaite wady danych gromadzonych w pliku podczas pracy nad projektem.

Gdzie znaleźć PCB Health Check?

Funkcja jest dostępna w edytorze PCB – i to w miejscu nieszczególnie intuicyjnym, bo… w panelu Properties. Według domyślnych ustawień programu funkcja PCB Health Check jest dostępna, jeżeli w aktywnym dokumencie PCB nie jest zaznaczony żaden obiekt – tylko wtedy bowiem panel przechodzi automatycznie w tryb właściwości samej płytki i pokazuje zakładkę Health Check, zaraz obok zakładek General i Parameters. Jeżeli mimo braku zaznaczenia jakichkolwiek obiektów funkcja nie jest widoczna, należy sprawdzić ustawienia zaawansowane (okno Preferences -> Advanced), a także wersję oprogramowania, gdyż opisywane narzędzie jest relatywnie nowe.

W sekcji Checks widoczna jest lista testów pogrupowanych według kategorii, takich jak Regions, Polygons, Components, Layers, Signals, Holes oraz Rules.

Poszczególne kontrole można włączać i wyłączać checkboxami. Pojedynczy test uruchamia się poleceniem Run Check z menu kontekstowego, a cały aktywny zestaw – przyciskiem Check All. Altium wykonuje kontrolę także automatycznie po otwarciu dokumentu PCB. Jeżeli projekt zostanie później zmieniony, wyniki są oznaczane jako nieaktualne, a program sugeruje ponowne uruchomienie sprawdzania.

Wyniki pojawiają się w kolumnie Issues, razem z ikoną określającą wagę problemu:

Na poniższym zrzucie ekranu można zobaczyć przykładowy komunikat: informację o tym, że program znalazł jeden komponent z punktem odniesienia znajdującym się poza footprintem.

Wskazanie konkretnego testu powoduje otwarcie sekcji ze szczegółami jego wystąpień oraz ogólnym opisem. Kliknięcie wpisu zwykle centruje i podświetla problematyczny obiekt na PCB, o ile dany przypadek można powiązać z konkretną geometrią.

W praktyce bardzo przydatny jest przełącznik Show issues only, który ukrywa testy zakończone bez uwag i zostawia na ekranie tylko pozycje wymagające reakcji lub przynajmniej świadomego ich przejrzenia.

Regions – błędy i pozostałości starej geometrii

Pierwsza grupa kontroli dotyczy regionów, czyli obiektów geometrycznych często używanych jako pola miedzi, fragmenty warstw mechanicznych lub elementy importowane z innych źródeł. Self-Intersecting Regions wykrywa regiony, których obrys przecina sam siebie, przez co kształt wyglądający zrozumiale dla projektanta oglądającego płytkę w edytorze może stać się niejednoznaczny dla generatora danych produkcyjnych lub eksportera geometrii.

Micro-Segments (Board) oraz Micro-Segments (Copper) wskazują bardzo krótkie fragmenty geometrii. Mogą powstać po imporcie pliku DXF, ręcznej korekcie obrysu płytki, przybliżeniu łuków odcinkami czy też po wielokrotnym przesuwaniu wierzchołków. Z punktu widzenia projektu najczęściej nie wnoszą niczego świadomego, ale zwiększają bałagan w danych i mogą utrudniać dalszą obróbkę CAM. Wariant Board dotyczy obrysu płytki, a Copper – obiektów na warstwach miedzi.

Zero Area Regions wykrywa regiony o zerowym polu powierzchni. Są to obiekty formalnie zapisane w dokumencie, lecz pozbawione realnej geometrii. Najczęściej stanowią pozostałość po nieudanej edycji albo imporcie i zwykle można je usunąć bez ryzyka, szczególnie po wcześniejszym zapisaniu projektu lub wykonaniu kopii zapasowej.

„Podejrzane” polygony

Druga grupa testów dotyczy polygonów, które w dokumentacji Altium są traktowane jako obiekty grupowe złożone z prostszych elementów geometrycznych. Podczas ich aktualizacji (funkcja Repour) dopasowują się do istniejących obiektów na tej samej warstwie, łączą się z obiektami tej samej sieci i zachowują odstępy wynikające z reguł projektowych.

Shelved/Modified Polygons jest jednym z ważniejszych testów przed wygenerowaniem danych produkcyjnych. Pole miedzi może zostać tymczasowo „odłożone”, czyli dezaktywowane funkcją Shelve, albo zmodyfikowane bez ponownego przegenerowania. Wtedy obraz płytki widoczny w edytorze może nie odpowiadać aktualnemu stanowi połączeń i odstępów izolacyjnych. W niektórych przypadkach nieaktualny polygon może nawet wymknąć się testom DRC. Tak dzieje się w sytuacjach, w których nowa geometria nie koliduje z odstępami izolacyjnymi wymaganymi przez reguły DRC, stąd uruchomienie PCB Health Check pozwala wykryć tego rodzaju problemy.

Zero Area Polygons wskazuje pola miedzi, które istnieją w strukturze projektu, ale nie mają użytecznej powierzchni. Mogą pozostać po zmianie obrysu płytki, usunięciu fragmentu wypełnienia lub zmianie reguł powodującej, że pole nie ma gdzie się rozlać. Warto potraktować taki komunikat nie tylko jako zachętę do usunięcia obiektu, lecz także jako sygnał, że należy sprawdzić, czy w projekcie z jakiegoś względu nie zniknęło oczekiwane pole miedzi.

Problematyczne footprinty

Testy z grupy Components są szczególnie przydatne w projektach rozwijanych przez dłuższy czas, przenoszonych między wersjami Altium Designera albo opartych na bibliotekach wielokrotnie modyfikowanych w trakcie pracy. 360deg Component wykrywa komponenty z rotacją zapisaną jako 360°. Geometrycznie odpowiada to wartości 0°, ale w nowszych wersjach programu taki zapis jest traktowany jako niepożądany stan danych. Naprawa sprowadza orientację elementu do poprawnej, jednoznacznej postaci.

Components on Non-signal Layers wskazuje komponenty umieszczone na warstwach, które nie są właściwą stroną montażową płytki (Top Layer lub Bottom Layer). Taki błąd może pojawić się po imporcie, kopiowaniu fragmentów projektu albo nietypowej migracji danych.

Components with Mirrored Footprints jest testem domyślnie wyłączonym, ale warto o nim pamiętać przy porządkowaniu starszych projektów. Kontrola dotyczy odbić footprintu względem biblioteki źródłowej. Automatyczna poprawka obejmuje tylko elementy związane z odbiciem, czyli piny, warstwy opisowe i bryły 3D. Inne zmiany footprintu pozostają bez zmian, dlatego tej funkcji nie należy traktować jako pełnej synchronizacji biblioteki z PCB.

Reference Point Outside the Component Area wykrywa komponenty, których punkt odniesienia znajduje się poza rzeczywistym obszarem elementu. Typowy przypadek dotyczy jednopadowych footprintów, np. punktów testowych: pad został przesunięty niezależnie od komponentu, więc wizualnie wszystko wygląda poprawnie, ale wewnętrzna definicja elementu jest niespójna. Taki problem może wpływać na eksporty, dane wyjściowe oraz przypisanie komponentów do konkretnych obszarów płytki. Najlepszym rozwiązaniem jest poprawienie footprintu w bibliotece źródłowej i aktualizacja PCB.

Duplicate Component Designators oznacza powielone oznaczenia komponentów. Dwa elementy opisane takim samym numerem (np.R17) mogą nie rzucać się w oczy podczas szybkiego przeglądu layoutu, ale w przypadku BOM czy plików Pick and Place są jednoznacznym źródłem ryzyka. Warto dodać, że choć przeważnie zduplikowane designatory zostaną podkreślone czerwoną linią na schemacie, to ten rodzaj oznaczenia błędu nie sprawdzi się np. wtedy, gdy z jakiegoś powodu dane PCB nie są zsynchronizowane ze schematem. Po automatycznej naprawie warto jeszcze porównać numerację ze schematem i listą materiałową – do tego celu należy użyć funkcji Project > Show Differences.

Niezgodności w projektach z panelizacją

Non-compatible Stackups in Panel dotyczy panelizacji wykonywanej na poziomie pliku *.PcbDoc z użyciem narzędzia Embedded Board Array. Problem pojawia się wtedy, gdy osadzona płytka i dokument panelu mają niezgodne stosy warstw. Nie jest to w żadnym razie drobiazg kosmetyczny – definicja warstw stanowi przecież podstawę danych produkcyjnych. W takim przypadku należy sprawdzić zgodność stosu warstw i świadomie zsynchronizować definicje, a dopiero potem ponownie wygenerować pliki wyjściowe.

Stare definicje xSignals po zmianach

Grupa Signals dotyczy definicji używanych przy bardziej świadomym prowadzeniu połączeń xSignals, które są stosowane m.in. wtedy, gdy istotna ścieżka sygnału przechodzi przez element szeregowy i nie da się jej opisać prostą nazwą jednej sieci. Broken xSignals oznacza przerwane lub niespójne definicje xSignals – w projektach z pamięciami DDR lub innymi magistralami równoległymi, szybkimi interfejsami szeregowymi, czy wreszcie parami różnicowymi taki problem może zaburzyć analizę długości i dopasowania ścieżek.

Unused xSignals wskazuje definicje xSignals, które nie są już używane. Często są pozostałością po wcześniejszej topologii, usuniętych elementach albo zmianach w strukturze magistrali. I znów – same w sobie nie muszą oznaczać błędu elektrycznego, ale mogą utrudniać interpretację projektu i prowadzić do pomyłek przy kontroli sygnałów krytycznych.

Unused From-Tos dotyczy ręcznych definicji połączeń punkt-punkt. Takie definicje bywają używane do narzucenia kolejności prowadzenia połączeń lub określenia konkretnej topologii. Po zmianach schematu lub netlisty mogą jednak zostać w projekcie jako nieaktualne dane. Usunięcie zbędnych From-Tos porządkuje dokument i zmniejsza ryzyko błędnej interpretacji połączeń.

Problemy w danych wierceń

Alerty generowane w sekcji Slots Hole Size > Length wskazują niespójne definicje otworów podłużnych. Jeżeli rozmiar narzędzia lub średnica otworu są większe niż długość szczeliny, dane technologiczne przestają mieć sens. Problem należy poprawić w padzie albo w bibliotecznym footprintcie, ponieważ zagadnienie dotyczy bezpośrednio procesów wiercenia lub frezowania.

Vias without Via Types Assigned, jak sama nazwa wskazuje, wykrywa przelotki bez przypisanego typu. W przypadku płytek wielowarstwowych dane przelotki wykraczają poza parametry standardowe, czyli średnice pierścienia i otworu – trzeba bowiem określić również jej zakres w osi Z, czyli w kierunku grubości stosu: część przelotek przebiega przez wszystkie warstwy, inne są ślepe bądź zagrzebane. Brak przypisania typu może znacznie utrudniać poprawną interpretację struktury warstw i technologii wykonania.

Błędne reguły DRC

Invalid PCB Design Rules wykrywa niepoprawne reguły projektowe zapisane w dokumencie PCB. Przykładowo: w projekcie może pozostawać reguła, która daje złudne poczucie kontroli, choć w rzeczywistości nie obejmuje już tego, co miała obejmować. Po otrzymaniu takiego komunikatu warto przejrzeć zakres działania reguły, jej priorytet oraz status w edytorze DRC.

Automatyczna naprawa błędów

Część problemów wykrywanych przez PCB Health Check można naprawić automatycznie przyciskiem Fix Issues. Dotyczy to m.in. regionów i polygonów o zerowym polu powierzchni, mikrosegmentów, odłożonych lub zmodyfikowanych pól miedzi, komponentów z rotacją 360° i innych.

Automatyczna naprawa jest wygodna w czasie intensywnej pracy, jednak w przypadku wystąpienia alertów zawsze warto i tak dokonać ręcznego przeglądu projektu. Przed użyciem funkcji Fix Issues warto zapisać plik, wykonać commit w systemie kontroli wersji albo przynajmniej zachować kopię dokumentu PCB. Po naprawie należy ponownie uruchomić PCB Health Check, a następnie wykonać pełny, wsadowy test DRC. Dopiero po takim zestawie działań projekt można traktować jako gotowy do dalszej edycji lub przygotowania danych produkcyjnych.

Raport z PCB Health Check w Batch DRC

PCB Health Check może być używany nie tylko jako szybki podgląd w panelu Properties. Wyniki kontroli można dołączyć do raportu generowanego podczas Batch DRC. W oknie Design Rule Checker należy zaznaczyć opcję Create Report File, a następnie Report PCB Health Issues. Po wykonaniu wsadowego DRC raport HTML zawiera wtedy także sekcję poświęconą problemom wykrytym przez PCB Health Check.

Ma to praktyczne znaczenie przy przekazywaniu projektu do wewnętrznego przeglądu, archiwizacji wersji produkcyjnej czy też podczas przygotowywania dokumentacji dla klienta. Zamiast oddzielnej, ulotnej listy ostrzeżeń w panelu programu pozostaje raport, który można zachować razem z paczką produkcyjną.

Podsumowanie

Najwięcej sensu ma uruchamianie PCB Health Check w kilku konkretnych momentach:

  • po imporcie projektu,
  • po większej aktualizacji bibliotek,
  • po zmianach footprintów,
  • po modyfikacji stosu warstw,
  • po panelizacji,
  • przed finalnym, wsadowym testem DRC.

W projektach z szybkimi sygnałami warto dodatkowo zwrócić uwagę na grupę Signals, ponieważ nieaktualne definicje xSignals i From-Tos mogą wprowadzać zamieszanie w analizie długości oraz topologii połączeń.

Dobrą praktyką jest potraktowanie PCB Health Check jako krótkiego testu poprzedzającego właściwy przegląd reguł projektowych. Najpierw porządkowany jest sam dokument PCB, później sprawdzane są reguły elektryczne, technologiczne i montażowe. Taka kolejność ogranicza ryzyko, że część czasu zostanie stracona na analizę naruszeń wynikających nie z rzeczywistego błędu projektowego, lecz z nieporządku w danych.

Źródła

Przemysław
Przemysław
Redaktor Naczelny portalu HardwareDesigner.pl. Konstruktor elektronik i programista embedded z ponad 20-letnim doświadczeniem w projektowaniu PCB. Z wykształcenia elektronik medyczny i elektroradiolog, specjalizuje się w projektowaniu i badaniach aparatury medycznej, laboratoryjnej i pomiarowej.

Czytaj więcej

Wybrane dla Ciebie