Automatyzacja generowania plików wyjściowych w Altium Designer

Output generation is not a manual step at the end of a project – it is a configurable, automatable process that should run the same way every time.

System generowania danych wyjściowych w Altium Designer jest zbudowany wokół plików Output Job (OutJobs). OutJob to skonfigurowany zestaw danych wyjściowych – danych produkcyjnych, danych montażowych, dokumentacji, BOM-ów, kontroli walidacyjnych i raportów niestandardowych – w którym ustawienia, format i lokalizacja docelowa każdego wyjścia są definiowane tylko raz. Ten sam OutJob można uruchomić dla dowolnego projektu. Gdy projekt się zmienia, uruchomienie OutJoba ponownie generuje wszystkie dane wyjściowe zgodnie z aktualnym stanem. Gdy zmienią się wymagania dotyczące danych wyjściowych, aktualizujesz OutJob tylko raz.

OutJobi nie są jedynie wygodnym rozwiązaniem dla pojedynczych inżynierów. Na poziomie zespołu stanowią mechanizm standaryzacji tego, co jest generowane, w jakim formacie i dokąd trafia – eliminując różnice wynikające z ręcznego generowania danych wyjściowych przez każdego inżyniera z użyciem własnych ustawień.

Architektura generowania danych wyjściowych – co generują OutJoby

• Fabrication outputs: Pliki Gerber (RS-274X, X2), pliki wierceń NC, ODB++, IPC-2581, raporty stosu warstw płytki.

• Assembly outputs: Pliki pick and place, rysunki montażowe, raporty punktów testowych.

• Documentation outputs: Wydruki schematów, wydruki PCB, modele 3D (STEP), rysunki montażowe.

• BOM outputs: Raporty BOM w standardowych i niestandardowych formatach.

• Validation outputs: Raporty DRC, raporty ERC, raporty różnic, raporty porównania footprintów. Mogą być skonfigurowane tak, aby blokować generowanie danych wyjściowych w przypadku niepowodzenia.

• Netlist outputs: Różne formaty netlist dla narzędzi dalszych etapów procesu.

• Custom outputs: Skrypty osadzone w OutJobach mogą generować dane wyjściowe w dowolnym formacie wymaganym przez Twój przepływ pracy.

Automatyzacja generowania danych wyjściowych poprzez proces wydania

Gdy projekt jest wydawany przez Workspace, wykonanie OutJoba jest zintegrowane z procesem wydania. Najpierw uruchamiane są kontrole walidacyjne – jeśli któraś zakończy się niepowodzeniem, proces wydania zostaje zatrzymany. Dane wyjściowe są generowane na podstawie zwalidowanego stanu projektu i zapisywane w Workspace jako wersjonowane artefakty wydania. Oznacza to, że dane wyjściowe wydania są zawsze możliwe do prześledzenia do konkretnej rewizji projektu, generowane ze znanego, poprawnego stanu i przechowywane w miejscu dostępnym dla całego zespołu.

To zasadniczo różni się od lokalnego generowania danych wyjściowych i udostępniania plików: nie ma wątpliwości, której rewizji projektu odpowiadają dane wyjściowe, nie ma ryzyka ponownego wygenerowania ich z innymi ustawieniami i nie ma zależności od konkretnego komputera lub konfiguracji danego inżyniera.

Niestandardowe generatory danych wyjściowych

Dla formatów wyjściowych, które nie są natywnie obsługiwane przez Altium Designer, SDK udostępnia API Output Generator. Rozszerzenie niestandardowego generatora danych wyjściowych integruje się z systemem OutJob jako pełnoprawny typ wyjścia – pojawia się w edytorze OutJob jak każde wbudowane wyjście, może być konfigurowane za pomocą ustawień, przypisywane do kontenerów wyjściowych i uruchamiane jako część zautomatyzowanego procesu wydania. Z perspektywy użytkownika niestandardowy generator danych wyjściowych jest nie do odróżnienia od natywnego.

To właściwe podejście w przypadku własnościowych formatów produkcyjnych, wewnętrznych szablonów dokumentacji, niestandardowych formatów netlist dla narzędzi wewnętrznych lub dowolnych wymagań dotyczących danych wyjściowych, które nie odpowiadają temu, co Altium dostarcza domyślnie.

Typowe wzorce problemów w zarządzaniu danymi wyjściowymi

• Manual generation with per-engineer settings – każdy inżynier generuje dane wyjściowe na swoim komputerze i z własnymi ustawieniami. Wyniki różnią się subtelnie między inżynierami i między kolejnymi uruchomieniami. Gdy pojawia się problem na produkcji, trudno ustalić, z której rewizji projektu pochodzą dane wyjściowe i czy użyte ustawienia były poprawne.

• Outputs stored outside the Workspace – pliki wyjściowe przechowywane lokalnie lub we współdzielonych folderach sieciowych zostają oderwane od projektów, które je wygenerowały. Przestaje być jasne, która rewizja projektu odpowiada któremu zestawowi danych wyjściowych, zwłaszcza po wprowadzeniu kolejnych zmian. Mechanizm wydania w Workspace rozwiązuje ten problem, łącząc dane wyjściowe z konkretnymi rewizjami projektu jako wersjonowane artefakty.

• Validation and output generation as separate manual steps – gdy inżynierowie uruchamiają DRC i ERC ręcznie przed wygenerowaniem danych wyjściowych, kontrole i samo generowanie nie są formalnie powiązane. Projekt może przejść walidację o jednej godzinie, a dane wyjściowe mogą zostać wygenerowane godzinę później, po tym jak ktoś wprowadzi zmianę. Integracja walidacji z OutJobem zapewnia, że walidacja jest uruchamiana dla tego samego stanu projektu, z którego generowane są dane wyjściowe.

• OutJob configuration drift between projects – gdy OutJobi są kopiowane między projektami i modyfikowane niezależnie, ich konfiguracje z czasem się rozchodzą. Zmiana wymagań dotyczących danych wyjściowych wymaga wtedy aktualizacji wielu OutJobów. Zarządzanie OutJobami jako współdzielonymi szablonami w Workspace i pobieranie aktualizacji do projektów zapobiega temu rozjazdowi.

Kiedy warto inwestować w niestandardowe generatory danych wyjściowych

Niestandardowe generatory danych wyjściowych mają sens wtedy, gdy Twoi partnerzy produkcyjni lub narzędzia dalszych etapów procesu wymagają formatów, których Altium nie generuje natywnie, oraz gdy te dane wyjściowe muszą być tworzone w sposób spójny jako część zarządzanego procesu wydania. Jeśli format można uzyskać przez post-processing natywnego wyjścia Altium – na przykład przekształcenie BOM CSV do określonej struktury – skrypt w OutJobu jest często prostszym rozwiązaniem niż pełne rozszerzenie SDK. Rozszerzenie warto tworzyć wtedy, gdy format wymaga dostępu do obiektów projektu na poziomie niedostępnym dla systemu skryptowego lub gdy typ wyjścia musi integrować się z interfejsem OutJob jako poprawnie konfigurowane wyjście.