Téma: Opustit Opposite Pad Type? A zavést excentricitu?
Z části příspěvku pana Dubeckého jsem si dovolil vytvořit nové vlákno, jelikož se mi zdá, že samostatné problémy, které se s ní pojí, mohou převážit otázky spojené s původním tématem konfliktu v rozměrech pájecích bodů. Na druhé straně by zde každá změna v definici typu padů znamenala zásah do definice formátu *.PCB souborů (což je věcí další verze programu), a proto asi v tomto vláknu spíše než o bezprostředně použitelné náměty půjde o "náměty a úvahy".
(...)
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í.
Zde se stále nabízí jeden nástroj, a sice excentricita plošky oproti (pomyslnému) středu padu. O ní jsem uvažoval již v dobách vzniku verze 4.0, tehdy především ve spojitosti s klasickou THT technologií, kde např. ve 3. konstrukční třídě může být pro pouzdro DIP14 výhodné užít oválné pady, ale vysunout je směrem od osy pouzdra, aby pod ním zůstalo více místa pro spoje. Celkem však o to nebyl zájem a mám podezření, že ani ty Opposite Types nebyly nikdy příliš užívány pro změnu technologie ani u těch SMD součástek, u kterých by to šlo.
V každém případě by zavedení excentricity znamenalo:
1) nový parametr u každé vrstvy v popisu každého logického typu (samozřejmě může být většinou nulový, takže uživateli nemusí tolik vadit);
2) nový bit u každého pájecího bodu (protože by již nestačilo rozlišovat orientaci 0 a 90°, ale bylo by nutno doplnit 180 a 270°);
3) pro uživatele možná navíc trochu zmatku (či nezvyku) při vytváření SMD pouzder, než by si ujasnil, co bude pokládat za pomyslný střed pájecího bodu (mimochodem ve zdrojových textech pro program Genlib jako střed beru konec pájecího bodu dle výkresu v normě, a zavedení excentricity by naopak mohlo uživateli k akceptování takovéhoto pravidla uvolnit ruce, čímž by se vyhnul nutnosti všelijakých přepočtů).
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.
Zde už by šlo o posuv v dalším směru, takže by ani výše zmíněná excentricita nestačila. Na druhé straně se mi však nezdá příliš praktické řešit problém tzv. záchytných pájecích bodů na úrovni knihoven, jelikož pak by musela u každého pouzdra existovat samostatná varianta pro každou jeho přípustnou orientaci vůči pohybu vlny. Spíše bych to asi ošetřil ručním umístěním padu (stejného typu jako pro piny) na příslušný konec pouzdra (i za tu cenu, že bych jej musel připojit fiktivním vodičem, aby mi DRC nehlásilo chyby). To však je jen můj názor -- rád se seznámím i s jinými.
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.
To by vlastně znamenalo, že každý pad (tj. nikoliv pad type) by musel obsahovat další bit, který by udával zrcadlení. (Ve spojení s výše zmíněnou excentricitou by to mohlo vést na stejný popis orientace, jaký se užívá např. u nápisů.) Bylo by však nejprve třeba zvážit, lze-li opravdu vše zrcadlit automaticky: Např. plošky typu Thermal by po zrcadlení připojily pad k jiné inverzní vrstvě.
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ší.
Na tomto místě je možná vhodné připomenout, že s Opposite Type se už nyní pojí všelijaké nedůslednosti. Tak např. má-li je uživatel v tabulce zadány nekonsistentně (k typu A je opačný typ B, ale k B již opačný typ není A), může se dočkat docela překvapivých jevů při čtení pouzdra z knihovny. V takové situaci by se program asi mohl chovat trochu robustněji, aby důsledky nekonsistence minimalizoval. Ale horší by bylo vymýšlet dostatečně robustní chování pro příkaz Files | Read File Sections, který umí přečíst i jen část tabulky pájecích bodů. Co jestli se některý nově přečtený typ odkazuje na opačný pad, který přečten nebyl? To by se třeba ještě dalo ošetřit, ale co když naopak ten přečtený typ přemazal jiný, na který jakožto na opačný odkazoval nějaký typ, který v tabulce zůstává...?
Když už je to takhle, asi by si uživatel, který potřebuje šetřit posice v tabulce a přidává typ padu, o němž ví, že se vyskytne jen na jedné straně desky, mohl dovolit mu zadat odkaz sám na sebe jakožto na opačný. Samozřejmě bude záležet především na uživatelově celkovém stylu zacházení s tabulkou rozměrů, stojí-li mu uspořená čísla typů za další vnesenou nekonsistenci a zejména lze-li se opravdu spolehnout, že se součástka s dotyčným typem nikdy nedostane na spodní stranu desky. Nějakých zákeřných chyb bych se zde už tolik neobával: na opačnou stranu desky se součástka může dostat jen ruční editací a to, že má pady z nesprávné strany desky, je při ní dost nápadné. (To už je spíše nebezpečí, že si člověk součástku během otáčení omylem ozrcadlí, a nevšimne si toho, protože to nebude vidět na jejích pájecích bodech.)
Do budoucna (tj. do verze s jiným formátem *.PCB souborů a s jinou databází) však asi stojí za úvahu, zda dosavadní koncept Opposite Pad Type neopustit zcela a nenahradit jej právě zrcadlením, které se ve většině situací skutečně jeví jako výhodnější řešení. Zde asi mohou k rozhodnutí nejvíce přispět zkušenosti z praxe.