Kontrola shody prvků při načítání součástek z knihoven

Tohohle problému si jsem již nějaký ten rok dobře vědom.  V jeho plném rozsahu však asi půjde nejen o detekci konfliktů rozměrů, ale především o jejich vyřešení.  Před několika měsíci jsem o tom korespondoval v souvislosti s řazením tabulky rozměrů pájecích bodů v testovací verzi (možná se pokusím vyhledat, co jsem tehdy napsal, a použít znovu tady), ale nedospělo se k jasnému závěru.

Dovolím si připomenout původní koncepci, dnes skoro 15 let starou:  (a) V desce mají pájecí body (číslované) logické typy; jim odpovídající rozměry jsou popsány v tabulce.  (b) V případě změny technologie lze celou tabulku vyměnit, a knihovny přesto zůstanou zachovány.  (c) Uživateli jsou logické typy presentovány pod jejich čísly.  (d) Tato čísla se užijí i pro uživatelské definování clonek a vrtáků.  Na tomhle základě lze zvažovat, co by se dalo nyní dělat.

Při zachování současného formátu souborů, tj. v rámci současné verze 4.x, se mi jeví ještě tak nejlepší takovéto řešení:

1) Knihovny budou čteny do paměti (a pouzdra z nich zobrazována v náhledovém okně) včetně rozměrů padů (které dosud jsou při čtení knihovních souborů zcela ignorovány).

2) Při ručním nebo automatickém (během čtení *.PNL souboru) převzetí pouzdra z knihovny se zkontrolují rozměry padů.  V případě konfliktu se pady čteného pouzdra přečíslují a pod výsledným číslem se přidají jejich rozměry do tabulky rozměrů.  Teď jde o to, jaké číslo zvolit, tzn. kterou položku v tabulce přepsat.  K tomu se nabízejí položky (tj. typy padů) dvou druhů -- jednak prázdné (s nulovými rozměry), jednak nepoužité na desce.
2a) Je možné začít od prázdných a nepoužitých typů, po jejich vyčerpání pokračovat nepoužitými.  Přitom by se začínalo např. od nejvyšších čísel typů.
2b) Zcela jiná možnost je začít od nepoužitých (nestarat se, zda jsou prázdné) a snažit se zachovat číslo.  Důsledkem by bylo např. to, že při čtení *.PNL souboru odkazujícího na pouzdra z jediné knihovny by se de facto převzalo číslování typů z této knihovny (jelikož na počátku čtení je deska prázdná a nepoužité jsou všechny typy).

3) V průběhu času mě také napadla ještě jedna možnost, jak si tabulku dodatečně zorganizovat, a sice vnutit pořadí čtením jiné tabulky rozměrů.  Fungovalo by to docela jednoduše:  Tak, jako nyní lze do desky přečíst tabulku rozměrů z externího souboru, novým příkazem by se přečetlo jen jejich číslování.  Pokud by se v tabulce na desce vyskytovaly typy stejných rozměrů jako v té externí, vnutila by se jim čísla těch externích.  Deska jako taková by se samozřejmě nezměnila, jen by pady na ní mohly přitom dostat jiná čísla typů.

Vrátím-li se k výchozí koncepci, lze nyní začít trochu uvažovat o širších důsledcích:
* Při řešení dle 2a dvě desky se zcela stejnými pouzdry mohou mít dvě různá číslování typů padů následkem (čistě jen) toho, že v příslušných *.PNL souborech se pouzdra objevila v různém pořadí.  Totéž ale může teoreticky nastat i při řešení dle 2b, budou-li užity nejméně dvě knihovny.
* Největší potíž bych asi viděl v bodu (c).  Obávám se, že dělat automatické zásahy do číslování padů může mít na uživatele podobný dopad, jako kdyby se ve městě přečíslovaly tramvaje, či ještě spíše jako kdyby se přečíslovávaly každé ráno.
* Další problém nastává při uživatelském definování nástrojů (clonek a vrtáků), protože to se do konfiguračních souborů příslušných zařízení ukládá pod čísly logických typů.  Není sporu, že toto je nebezpečná věc, která může způsobit zkažené matrice či desky.  Praktická otázka (kterou neumím dobře posoudit) spíše je, jak často se dnes předefinování ještě užívá.  Clonkové fotoplottery už asi jsou historie, půjde tu zřejmě především o vrtačky.
* Co spojové čáry?  Z hlediska symetrie by podobné mechanismy asi měly být zavedeny i pro ně, ale v praxi jistě zdaleka nejsou tak potřebné.
* Dosavadní e-mailová  diskuse vedla víceméně k závěru, že nejlepší možná bude do logiky kolem tabulek rozměrů raději moc nezasahovat, protože na současný stav si každý jednotlivý uživatel v podstatě už nějak zvykl.  Na druhé straně by však úspěšné řešení asi dovolilo kvalitativně lepší využití cizích uživatelských knihoven, které je doposud omezeno zejména odlišnými tabulkami rozměrů.

Omlouvám se, že jsem se tak obšírně rozepsal.  Jde však o podstatný a docela komplikovaný problém, který je třeba důsledně promyslet do všech podrobností před každým pokusem o jeho programátorské řešení.  Uvidíme, jaké názory se teď objeví v diskusi.

No, k tomu systému "pouze varovat" bych asi měl trošku výhrad jakožto programátor: pracnost se mi nezdá úměrná přírůstku užitné hodnoty. 

Jde o to, že v každém případě se musejí načíst a ukládat tabulky rozměrů všech knihovních souborů.  To asi představuje více programování, než manipulace s tabulkou rozměrů.  Na druhé straně dnes uživatel nemá žádný nástroj, kterým by mohl snadno dělat takové transakce s tabulkou rozměrů, jako je odsunutí jednoho typu padu do jiné položky tabulky (ačkoliv na toto existuje příkaz) a zároveň přečíslování typu padu v desce (ačkoliv to pomocí množinových operací také jde).  Tím méně je může dělat hromadně, tj. pro více typů najednou.  Přitom, obecně řečeno, právě tohle je postup odstraňování kolizí, jakmile byly detekovány.  (Kromě toho si nejsem jist, zda mohu kolizi lehce zjistit před začátkem čtení souboru, a v jeho průběhu už deska byla změněna.)  V ideálním případě by mohl být užit systém, kdy po detekci kolize následuje dotaz, a zásahy do tabulky rozměrů až po kladné odpovědi.

Ještě bych teď počkal, zda do diskuse nepřispěje někdo z těch uživatelů, kteří mají tabulku padů zcela zaplněnou.

Děkuji za podrobný příspěvek s hodnotnými náměty, které ostatně vystačí ještě na celé další téma.  V tomto vlákně bych se však rád omezil na takové zásahy, které by šlo udělat v rámci stávajícího formátu *.PCB souborů. 

Možná bych měl zdůraznit, že body 1, 2 a 3 v mém minulém příspěvku nijak nemají povahu vzájemně se vylučujících variant (pouze 2a je alternativou k 2b); bod prostě 1 je nutným předpokladem pro bod 2 a k oběma lze navíc případně přidat bod 3.  (Zde bych ještě snad dovysvětlil, že bod 3 znamená doplnit příkaz, kterým uživatel může kdykoliv, tj. nezávisle na přebírání součástek z knihovny, připodobnit řazení tabulky pájecích bodů libovolnému jím zvolenému souboru.)  Z toho hlediska je návrh pana Dubeckého -- chápu-li jej správně -- alternativou k mému bodu 2.

Když si to zkusím nějak interpretovat, algoritmicky bych zde oproti bodu 2 viděl hlavně tyto rozdíly:
* Určité posice v tabulce by byly zafixovány, takže by je čtení z knihovny nemohlo přepsat, ani kdyby se pájecí body těchto typů na desce nevyskytovaly.  (Pan Dubecký zmiňuje typy 0 a 1; mohly by to být třeba 0 až 9, které mají tu vlastnost, že se dají z tabulky vybírat klávesovými zkratkami.)
* Po konfliktu při čtení padu z knihovny by se prohledávala tabulka rozměrů (na desce), zda se v ní pad stejných rozměrů již nevyskytuje pod jiným číslem typu.  Rozdíl však je spíše důsledkem opomenutí či nedomyšlenosti z mé strany -- asi by se to muselo dělat v každém případě, jinak by se při čtení téhož padu (dokonce i se stejným číslem!) ze dvou různých knihoven mohl do tabulky dostal dvakrát.
* Je-li nutno rozměry přidat do tabulky, hledala by se volná posice od nejnižších čísel (takže by se tabulka vlastně budovala až při čtení knihovny).  Předpokládáme-li však, že čísla typů z knihovny budou pokud možno zachována, vlastně se dostáváme zpět k bodu 2b.

Naopak pouze z hlediska algoritmů pro čtení padů z knihovny nelze tak snadno zahrnout předpoklad, že se začíná s téměř prázdnou knihovnou.  Algoritmy ošetřující konflikty totiž musejí fungovat v každém stádiu návrhu, tedy i s libovolnou podobou tabulky rozměrů.

Pokusím-li se shrnout základní společné vlastnosti všech diskutovaných přístupů, vychází mi:
* Uživatel by ztratil dosavadní záruky, že pájecí bod, který si nadefinoval, najde vždy pod stejným číslem typu.
* Oproti tomu by však měl zaručeno, že rozměry pájecího bodu se budou přenášet spolu s pouzdrem, v němž je užit (až do případného vyčerpání posic v tabulce rozměrů na desce).

Sám bych zde asi zdůraznil jen potřebu najít takové algoritmy, aby se změny v číslování, které jsou pro ošetření konfliktů nevyhnutelné, uživateli jevily co nejmenší.