Globalna tabela bibliotek footprintów zawiera listę biblioteki, które są dostępne zawsze, niezależnie od obecnie wczytanego projektu. Tabela ta jest zapisana w pliku fp-lib-table w katalogu domowym użytkownika. Jego rzeczywista lokacja zależy użytego systemu operacyjnego.

Lokalna tabela bibliotek footprintów zależna od projektu zawiera listę bibliotek, które są dostępne wyłącznie w obecnie wczytanym projekcie. Lokalna tabela może być modyfikowana tylko wtedy, gdy zostanie ona załadowana razem z listą sieci tego projektu. Gdy projekt nie został załadowany lub gdy taka lokalna tabela nie istnieje, tworzona jest pusta tabela, którą będzie można wypełnić i później zapisać razem z plikiem przypisań footprintów (z rozszerzeniem .cmp).

Gdy CvPcb lub Pcbnew zostanie uruchomiony i globalna tabela bibliotek fp-lib-table nie zostanie znaleziona w katalogu domowym użytkownika, CvPcb lub Pcbnew będzie próbował skopiować domyślną tabelę bibliotek fp-lib-table zapisaną w folderze template do pliku fp-lib-table w katalogu domowym użytkownika.

Jeśli plik fp-lib-table nie może zostać odnaleziony, to zamiast operacji kopiowania zostanie utworzona pusta tabela. Gdyby taka sytuacja miała miejsce użytkownik ma też możliwość skopiowania pliku fp-lib-table samodzielnie lub ``ręczne'' skonfigurowania tabeli.

Domyślna tabela bibliotek zawiera wszystkie standardowe biblioteki jakie zostały zainstalowane razem z programem KiCad EDA Suite.

Oczywiście, użytkownicy pragnący dostosować konfigurację bibliotek do własnych potrzeb powinni to zrobić tuż po zainstalowaniu programu KiCad.

(Zbyt duża ilość aktywnych bibliotek będzie skutkować dłuższym czasem wyszukiwania footpritntów)

By móc używać biblioteki najpierw należy dodać globalną lub lokalną tabelę. Lokalna tabela ma zastosowanie tylko gdy istnieje otwarta lista sieci projektu.

Każda pozycja tabeli musi posiadać unikalną nazwę skrótową.

Nie musi ona mieć jakiegokolwiek związku z bieżącą nazwą pliku lub ścieżki do niego. Znak dwukropka : nie może być używany w nazwach skrótowych. Każda pozycja musi również odnosić się do prawidłowej ścieżki/nazwy pliku w zależności od typu biblioteki. Ścieżki do plików mogą być bezpośrednie, względne lub pochodzić ze specjalnych zmiennych systemowych - opisanych dalej.

Aby biblioteka została wczytana przez CvPcb musi być także wybrana właściwa wtyczka obsługująca dany format pliku. CvPcb obecnie wspiera następujące formaty plików bibliotek: KiCad Legacy, KiCad Pretty, Eagle oraz gEDA.

Istnieje również pole przeznaczone do wpisania opisu dla danego wpisu w tabeli. Pole z opcjami nie jest w tej chwili używane, zatem umieszczanie jakichkolwiek opcji nie ma znaczenia przy ładowaniu bibliotek.

Jednym z największych zalet tabeli bibliotek footprintów jest możliwość używania odnośników do zmiennych systemowych. Pozwala to na zdefiniowanie własnych ścieżek do bibliotek w zmiennych systemowych i używanie ich w projektach. Odnośniki do zmiennych systemowych można wplatać w treść pól zawierających ścieżkę do pliku używając powszechnie znanego formatu *$\{nazwa_zmiennej\}.

Domyślnie KiCad podczas pracy definiuje dwie zmienne systemowe:

Można re-definiować samodzielnie zmienną KISYSMOD za pomocą okna dialogowego wywoływanego przez Ustawienia → Konfiguracja ścieżek dostępu, co pozwala na zastąpienie standardowych bibliotek ich własnymi odpowiednikami.

Podczas wczytywania listy sieci projektu, CvPcb definiuje zmienną KIPRJMOD używając do tego ścieżki dostępu do tego pliku (zwykle jest to ścieżka dostępu do projektu).

Pcbnew także definiuje tą zmienną podczas ładowania pliku z obwodem drukowanym.

To pozwala na zapisanie niektórych bibliotek w folderze projektu bez potrzeby definiowania pełnej ścieżki do niego (która nie zawsze jest znana) i umieszczenie ich w tabeli bibliotek znajdującej się również w folderze projektu.

GitHub to specjalna wtyczka pozwalająca na łączenie się ze zdalnym repozytorium GitHub zawierającym footprinty w formacie Pretty (Pretty to nazwa nowego formatu zapisu footprintów w programie KiCad). Repozytorium to jest tylko do odczytu, ale wtyczka umożliwia dostęp do technologii Copy On Write'' (COW) wspierającej możliwość edycji footpritnów odczytanych z repozytoriów GitHub https://github.com i zapisanie ich modyfikacji na dysku lokalnym tak by zmodyfikowane wersje stały się aktywne. By dodać wpis GitHub do tabeli bibliotek, pole Ścieżka'' musi zostać wypełniona ważnym adresem URL do repozytorium GitHub.

Przykładowo

https://github.com/liftoff-sr/pretty_footprints

lub

https://github.com/KiCad

Zwykle poprawna ścieżka URL jest tworzona wg następującego schematu:

https://github.com/nazwa_użytkownika/nazwa_repozytorium

Pole Typ Wtyczki'' musi być ustawione jako Github''. Aby włączyć funkcję Copy On Write'' należy w polu Opcje'' dodać parametr allow_pretty_writing_to_this_dir który zawierał będzie ścieżkę na dysku lokalnym gdzie zapisywane będą pliki z modyfikacjami. Jeśli ta opcja zostanie pominięta to biblioteka GitHub jest tylko do odczytu. Footprinty tam zapisane są połączeniem części tylko do odczytu repozytorium GitHub i treści lokalnych zmian by utworzyć zmodyfikowaną bibliotekę footprintów. Każda modyfikacja biblioteki GitHub będzie trafiać do tej lokalnej biblioteki hybrydowej COW umieszczonej w odpowiednim folderze *.pretty. Należy w tym miejscu nadmienić, iż część rezydentna COW pochodząca z repozytorium GitHub jest zawsze tylko do odczytu, co oznacza, że nie można niczego samodzielnie usunąć lub zmodyfikować bezpośrednio w samym repozytorium GitHub. Niezależnie czy biblioteka będzie hybrydowa, czyli połączona z lokalnej części tylko do odczytu i zapisu, czy tylko część zdalną przeznaczoną tylko do odczytu, będzie ona dalej zwana biblioteką ``Github'' w dalszych rozważaniach.

Poniższa tabela pokazuje wpis z tabeli bibliotek, której nie została przypisana opcja allow_pretty_writing_to_this_dir:

Następna tabela pokazuje wpis z tabeli bibliotek z opcją dotyczącą COW. Zmienna $\{HOME\} jest tylko przykładowa. Folder github.pretty jest umieszczony w folderze do którego prowadzi ścieżka $\{HOME\}/pretty/. W każdym przypadku użycia opcji allow_pretty_writing_to_this_dir, wymagane jest samodzielne utworzenie tego folderu i musi on posiadać rozszerzenie *.pretty.

Footprinty pobierane z repozytorium mają zawsze pierwszeństwo przed tymi umieszczonymi w folderze na który wskazuje opcja allow_pretty_writing_to_this_dir. Po zapisaniu footprintu do lokalnego folderu przechowującego hybrydowe pliki COW, np. poprzez zapisanie zmian w edytorze footprintów, żadne aktualizacje GitHub nie będą widoczne podczas ładowania footprintów o tej samej nazwie, niż te, które zostały zapisane lokalnie.

Zawsze należy korzystać z odrębnego folderu *.pretty dla poszczególnych bibliotek GitHub i nigdy nie powinno się łączyć folderów przez przypisywanie tego samego folderu do innych bibliotek GitHub.

Także, nie powiino się używać tego samego folderu COW w całej tabeli. Mogłoby to doprowadzić do bałaganu nad którym nie byłoby można zapanować.

Wartości symboliczne w zmiennych systemowych zapisane w notacji ${nazwa_zmiennej} przypisane do opcji allow_pretty_writing_to_this_dir będą rozwijane automatycznie by utworzyć właściwą ścieżkę, tak samo jak to ma miejsce w polu Ścieżka.

Co robić z plikami w COW? System COW to element przyśpieszający współużytkowanie footprintów.

Jeśli zawartość COW będzie regularnie przesyłana do zarządcy repozytorium GitHub, będzie można pomóc w uaktualnianiu kopii znajdujących się w repozytorium zdalnym. Całość jest bardzo prosta. Za pomocą poczty elektronicznej należy wysłać pliki *.kicad_mod znajdujące się w folderach systemu COW do osoby zarządzającej repozytorium. Po otrzymaniu potwierdzenia, że zmiany zostały zaakceptowane i wprowadzone, można skasować wysłane pliki z COW. Nowe wersje plików zostaną pobrane z repozytorium GitHub. Głównym celem jest utrzymywanie jak najmniejszego zestawu plików systemu COW jak tylko jest to możliwe poprzez regularne przesyłanie zawartych w niej plików do repozytorium znajdującego się pod adresem https://github.com.

Biblioteki footprintów mogą być zdefiniowane globalne lub lokalnie dla obecnie wczytanego projektu. Biblioteki umieszczone w globalnej tabeli bibliotek użytkownika są zawsze dostępne i są zapisane w pliku fp-lib-table w katalogu domowym użytkownika.

Globalne biblioteki będą dostępne nawet jeśli nie została otwarta lista sieci danego projektu.

Inaczej sprawa się ma w przypadku lokalnych bibliotek, które są aktywne wyłącznie dla bieżącej listy sieci.

Lokalna tabela bibliotek jest zapisywana w pliku fp-lib-table umieszczonym w tej samej ścieżce co lista sieci. Nie ma przeszkód co do definiowania odnośników do bibliotek w obu tabelach.

Są jednak zalety i wady każdego z rozwiązań, które należy rozważyć. Można zdefiniować wszystkie biblioteki w globalnej tabeli bibliotek, co oznacza, że będą one zawsze dostępne gdy będą potrzebne. Wadą takiego rozwiązania będzie szybkość wyszukiwania w nich odpowiedniego footprintu. Można zdefiniować wszystkie biblioteki w lokalnej tabeli bibliotek.

Zaletą takiego rozwiązania będzie możliwość zdefiniowania tylko tych bibliotek, które będą w danej chwili potrzebne oraz skrócenie czasu ich przeszukiwania.

Wadą tego rozwiązania będzie zaś to, że będzie trzeba zawsze pamiętać, by dodać odpowiednie biblioteki dla każdego nowego projektu. Można zdefiniować biblioteki w obu tabelach jednocześnie.

Sensowne staje się wtedy wpisanie bibliotek, które są wykorzystywane prawie we wszystkich projektach do tabeli globalnej, a w lokalnych tabelach umieścić tylko te, które są przydatne tylko w tym konkretnym projekcie. Będzie to rozwiązanie, które będzie posiadało największą elastyczność kosztem zmniejszenia szybkości wyszukiwania. Oczywiście nie ma żadnych przeszkód by zdefiniować swoje tabele bibliotek w jakikolwiek inny sposób.

Pasek statusu jest umieszczony na dole głónego okna CvPcb i dostarcza użytecznych informacji dla użytkownika. Poniższa tabela opisuje zawartość każdego panelu na pasku statusu.

Wyświetlane jest poprzez kliknięcie prawym klawiszem myszy: