Nastavení hledání (Stránka 2 z 2)

Funkce barevného označovaní nepropojených spojů by byla užitečná - především pro napájecí spoje, kterých je vždy spousta. Tak jste to taky asi myslel vzhledem k výchozímu použití  barev modrá a červená. Má to ale háček. Přiřazení si program nepamatuje, takže bych musel označování provádět při každém spuštění, tedy alespoň jednou za den, což je docela otrava.

Přepínání grafiky jsem pouze odzkoušel, ale popravdě nevím, co si s funkcí v této podobě počít. Možná by se hodilo mít určitá nastavení grafiky předpřipravena, ale to bych je musel umět pojmenovat, abych je posléze rychle rozpoznal. Zásobníková metoda je tak trochu typu pokus-omyl, takže mi to ve výsledku nepřijde rychlejší než ruční nastavení hladin. Makra mi připadají trošku lepší, ovšem celkový počet maker má zase omezení z hlediska mé paměti.

Připojím moji zkušenost s návrhem čtyřplátu. Pomocí padů typu Annulus a Thermal se deska sice snadno navrhuje, problém ale nastává při generování podkladů u výrobce tišáků. Na problém jsem narazil náhodou zrovna u výše zmiňované desky MICEL1, kdy byl při generování filmů omylem jeden průchod spojen s vnitřní vrstvou, ačkoli podle zdrojových podkladů spojen být neměl. Na můj dotaz, jak se to mohlo stát, mi výrobce podkladů (BEKEL, cca před  6-ti lety) odpověděl, že takto generované podklady vnitřích vrstev (pady Annulus a Thermal) zpracovat neumějí, takže je musejí překreslovat ručně, a tím vznikla chyba. Takže v budoucnu, pokud bych navrhoval další čtyřplát, bych už tento způsob asi nepoužíval (i když je jednoduchý, ale nebezpečný), místo toho bych napájecí pady v dané vrstvě spojoval ručně a poté klasický vyplnil plochou mědi. Tento způsob mi navíc dává možnost použít vnitřní vrsty i pro spíše omezený počet jiných spojů.

Logické typy považuji za věc zapeklitou až skoro nebezpečnou. Vytváří ve mně neustálý strach, že se při natažení součástky z knihovny nebo dokonce z jiného souboru něco pokazí, čeho si v první chvíli ani nevšimnu. Naštěstí, tento strach budí velkou opatrnost, díky které dojde k problému jen zcela výjimečně. Ale popsaný problém mi komplikuje práci. Asi největší nebezpečí vidím v samotných knihovnách. Mách jich totiž víc a pokud v jedné z nich vytvořím nový pad, musím tuto změnu přenést i do ostatních. A běda, pokud to zapomenu udělat. Pokud pak někdy později vytvářím další nový pad, ale v jiné knihovně, použiji nejbližší volné číslo této knihovny, které je ale už ve skutečnosti obsazeno. Navíc i pokud nezapomenu aktualizovat všechny ostatní knihovny, čeká na mě ještě jedno riziko. Při natažení nové tabulky se mi automaticky přetahuje i "Basic Grid", takže při přetahování např. z metrické do palcové knihovny může vzniknout zásadní problém, pokud zapomenu "Basic Grid" ručně opravit (i když mě na změnu program naštěstí upozorňuje).

Já osobně bych ze tří navrhovaných variant řešení zvolil variantu čtvtou. Ta by se nejvíce podobala variantě 3) ale byla by poněkud radikálnější (mnohým uživatelům a možná i autorovi asi vstanou vlasy na hlavě):

4) Na začátku by každá deska měla ve své tabulce definovány jen nejzákladnější pady, tedy průchody, případně nějaký speciální upevňovací otvor apaod.. Nic jiného. Teprve při natahování součástek na desku z knihoven (jiných desek) by se do této tabulky přidávaly další pady podle potřeby. ??íslování by klidně mohlo probíhat pouze vzestupně tak, jak se jednotlivé součástky budou umísovat (samozřejmě by šlo i zachovávat původní čísla v případě, že jsou ještě volná). Pokud by program našel již použitou definici padu, využil by ji bez ohledu na číslování (různá čísla jednoho typu padu u dvou různých knihoven by se sjednotila). Pokusím se shrnout vlastnosti takového řešení:

a) Dojde k přečíslování padů
- obava, že to vytvoří jakýsi optický zmatek, je v z mého pohledu zcela lichá, protože si čísla padů při jejich množství stejně nepamatuju. Teda kromě čísel 0 a 1, které používám na průchody, ale průchodové pady by stejně musely být definovány jako první, ještě před natažením součástek, protože jsou potřeba vždy, takže jejich čísla by zůstala zachována.
- stejně jako pan Horský se domnívám, že pevný clonkový systém je už dávno minulostí. Já používám pro generování formát RS274X, který si clonky přiřazuje sám, takže nemůže vzniknout problém.
- nevidím problém ani ve vrtačce. Používám driver Excellon, který nehledí na číslování padů ale na jejich skutečné rozměry. Žádné další následné předefinování jsem v životě nepoužil, protože tyto dodatečné (většinou ruční) operace jsou podle mého jen zdrojem problémů.

b) Zásadní výhodu vidím v tom, že metoda odstraňuje problém možné redefinice padů při nesouladu tabulek. Metoda problém sama řeší, aniž by uživatel něco tušil.

c) A vidím ještě jednu novou výhodu. Od počátku používání SMD součástek narážím na zásadní problém. Rozměrů padů dle doporučení výrobců je snad nekonečné množství. Pokud bych se měl striktně držet doporučených rozměrů, měl bych tabulku už dávno plnou. Takže vždy hledám raději něco podobného, nebo dokonce i použiji na misto jednoho pady dva, abych tabulku hned nezaplnil. Popsaná metoda by mi dovolovala celkové množství typů padů razatně rozšířit. Pokud bych totiž v jedné knihovně zaplnil tabulku, založil bych si klidně novou knihovnu, kde bych začal zase od začátku. Takže mohu mít klidně mraky knihoven s rozdílně definovanými tabulkami, takže téměř neomezené celkové množství typů padů. Na desku by se pak natahovaly jen použité pady (256 typů pro jednu desku mi určitě stačí). Výhoda rozšíření se samozřejmě netýká jen SMD padů, ale i klasických, kterých není také nikdy dost - vrtáky jsou ostupňovány po 0,1 mm, navíc může mít pad různé měďěné okolí v závislosti na technologii nebo použití padu (upevňovací otvor bez mědi nebo naopak se širokou mědí)

d) Nemusím se moc trápit s tím, zda pad u nově vytvářené součástky již mám definovaný nebo ne (hledání stejného padu může být docela zdlouhavé). Klidně si ho nadefinuji znovu, aniž bych tím omezil celkový počet typů na vytvářené desce - stejné pady se totiž sloučí pod jediné nové číslo.

A ještě mám jeden návrh ohledně padůí. Souvisí to s tím, co jsem již napsal : s množstvím různých tupů SMD padů. Škoda je, že se tento počet ještě násobí 2 x, protože musím pro obě strany definovat dva různé pady. To je velká škoda, protože obě definice jsou téměř stejné, jen vrstvy jsou zrcadlené. Původní záměr pana Horského měnit velikost padu nahoře a dole v závislosti na technologii se bohužel nedá využít ze dvou důvodů:
i) při pájení vlnou je nutné rožšířit pady oproti pájení pastou pouze směrem od středu pouzdra. Naopak vnitřní strana padů se většinou může zkrátit. V každém případě to vede nejen ke změně rozměru padu, ale také k jeho posunutí. Navíc některá pouzdra, třeba běžná SO s roztečí 1,27 mm, by navíc měla mít na jedné straně (kde vlna končí) širší poslední pady pro odtržení vlny. Zkrátka - jiná technologie vede automaticky k jiné definici pouzdra, takže měnit rozměry padu při otáčení nemá smysl.
ii) navíc spodní strana nemusí být vždy pájena vlnou, někdy je pasta na obou stranách.

Takže bych narhoval - pokud má pad nastaven "Opposite Type" sám na sebe, zrcadlit při přesunu SMD padu na opačnou stranu vždy všechny vrstvy. Případ, kdy bych chtěl u součástky při jejím zrcadlení ponechat pady na původní straně (tedy na opačné, než zbytek součástky), si opravdu nedovedu ani teoreticky představit (v nejhorším by se tento nadmíru podivný případ dal řešit právě jiným oposite typem) . Ono se to vlastně týká i klasických padů - tam by zrcadlení také mělo automatický probíhat. Pokud by náhodou nějaký pad byl definován asymetricky tak asi není důvod, proč se součástkou nepřetáčet i tento pad, jinak se součástka ve skutečnosti změní. Možnost jiného  "Opposite Type" bych ponechal beze změny.

Tímto řešením by se jednak  rozšířil prostor pro další definice padů (a to výrazně, protože SMD plošek je ve srovnání s klasickými podstatně více typů), jednak by definovaní nového padu bylo rychlejší.