microgeek.eu

W końcu doszło do tej historycznej chwili... zainstalowałem sobie kicada w nowej wersji:

kicad1.png

Najlepsza nauka to skok na głęboką wodę by się zmierzyć z większym problemem. I takich właśnie problemów nie zabrakło i pojawiło się ich kilka. Na początek zaprezentuję jeden z nich, gdyż nie jest wykluczone, że inne problemy nie są konsekwencją wcześniejszych.
Próbuję prowadzić ścieżki dla PCB, elementy (na schemat i na PCB) są ze standardowej biblioteki kicada. Przy ręcznym prowadzeniu ścieżek kicad nie chce „wejść” do pada.

kicad5.png

Dojeżdżam w pobliże pada i dalej już nie chce jechać.
Efekt jest taki, że powstaje brak połączenia.

kicad3.png

Takich przypadków jest więcej.

kicad4.png

Szerokość ścieżki nie wykracza poza szerokość padu.

kicad2.png

Zastawiające jest to, że do innych padów spoko dojeżdżają ścieżki a do określonych (wybranych) nie, tak jakby to były elementy drugiej kategorii.
Powstaje pytanie: co zje...łem i dlaczego tak się dzieje?

gaweł pisze:Powstaje pytanie: co zje...łem i dlaczego tak się dzieje?

Nie jestem ekspertem (@ZbeeGin na pewno skoryguje)... Pady SMD są tylko na jednej stronie PCB. Jeżeli kolor pada nie zgadza się z kolorem ścieżki, to będzie brak połączenia (między nimi jest laminat). Potrzebna jest przelotka.

Element U202 jest po stronie F.

kicad7.png

Zmodyfikowałem sobie kolory dla poszczególnych warstw wg własnego punktu widzenia (siła przyzwyczajenia jest ogromna), także strona F.Cu ma kolor zielony, strona B.Cu ma kolor czerwony.

kicad6.png

gaweł pisze:siła przyzwyczajenia jest ogromna

No to zabłysłem spostrzegawczością...
Niestety nadal nie wiem w czym tkwi problem. Aż chce się poklikać na Twoich screenach...

Dopisane po dłuższej chwili: Włączyłem swój, żeby porównać. Wygląda na to, że masz za szerokie ścieżki w stosunku do rozmiarów padów. W moim ścieżka mieści się między padami...

Wspólnymi siłami można góry przenosić
Układ U202 to obudówka typu MSOP10, więc między nogami nic się nie da.
Zmieniłem szerokość ścieżek na 8 mils i odstęp między ścieżkami na 7 mils i pomogło.

kicad10.png

Niemniej nadal jest dla mnie zagadką, dlaczego wcześniej nie chciało?
Szerokość pada jest prawie 12 mils (11,8), pady są co 20 milsów, więc odstęp między padami jest ciót więcej niż 8 milsów.

No chyba wyjaśnił się problem. Odstęp między padami wynosi 0.5mm i nie jest to 20 mils (jak nie wiadomo dlaczego mi się ubzdurało ).

kicad11.png

Szerokość ścieżki + odstęp między ścieżkami był wyrachowany prawie "na styk" no i niestety nie stykło . No ale nie ma się o co martwić, najbardziej wchodzi do głowy wiedza pochodząca z rozpoznania walką.

gaweł pisze:Niemniej nadal jest dla mnie zagadką, dlaczego wcześniej nie chciało?

Reguły projektowe nie pozwalały. One nie zawężają się do tego pada i tej ścieżki. Przeszkodą były pady sąsiadujące. Spójrz na swój pierwszy zrzut ekranu. Wokół pól masz takie cieniutkie obrysy...

ZbeeGin pisze:Reguły projektowe nie pozwalały. One nie zawężają się do tego pada i tej ścieżki. Przeszkodą były pady sąsiadujące. Spójrz na swój pierwszy zrzut ekranu. Wokół pól masz takie cieniutkie obrysy...

Dzięki, kumam. A wielkość tego obrysu jest modyfikowalna w jakiś sposób?

Tak. W ustawieniach można modyfikować "Lokalny prześwit" który pokryje ustawienia globalne oraz te nadane w regułach.
Z tym, że każdy footprint może mieć swoje własne ustawienia i tyczą się one całego footprintu. Jak i każde pole tego footprintu również może mieć swoje ustawienia, które będą dotyczyły tylko jego samego.

Zatem hierarchia jest taka:
1. Lokalny prześwit pola. Jeśli 0 patrz pkt. 2.
2. Lokalny prześwit footprintu. Jeśli 0 patrz pkt. 3.
3. Prześwit klasy sieci. Jeśli nie ma osobnej klasy patrz pkt. 4.
4. Prześwit nadrzędnej (domyślnej) klasy sieci.

Dzięki, poeksperymentuję