Nastavení hledání (Stránka 24 z 25)

??asto chci vidět jen vodivý obrazec, případně jeho jedinou vrstvu (spousta podivností tak ihned padne do oka, zatímco při zobrazení dvou a více vrstev se na ně bez vynaložení pozornosti a trochy přemýšlení těžko přijde).  Jindy mě také zajímá, kde jsou součástky (takže chci vidět jejich vnější obrysy).  Nakonec potřebuji urovnat popisy součástek, a tak se starám už jen o vrstvu potisku a vrchní vodivou vrstvu.  U běžné dvouvrstvé desky s jednostrannou montáží to představuje asi pět různých kombinací vrstev.

Praktické zkušenosti mi přitom ukázaly, že spíše než individuální nastavování pohledu je pro mne daleko pohodlnější mít těch několik potřebných kombinací někde připravených a, kdykoliv jsem na pochybách, mezi nimi přepínat.  Současné řešení v testovací verzi dovoluje přepnout na další kombinaci jedinou klávesou, aniž bych opustil menu Graphics.  Vůbec si nepotřebuji pamatovat, v jakém pořadí je mám uložené; pokud neuvidím to, co chci, prostě přepnu na další.

Podívám-li se zpět, mohu říci, že to, jak bylo pracné si zobrazování přestavit na jiný pohled (a pak zase vracet zpět) občas ovlivňovalo samotný styl práce.  Teď není přepínání (mezi předem připravenými kombinacemi) o moc složitější než třeba změna měřítka kolečkem myši.  Ostatně pokud se nové příkazy Graphics | Roll Down a Graphics | Roll Up osvědčí, mohu je docela dobře na kolečko přidat (podmíněné Alt nebo jiným přesmykačem).

Před časem jsem dostával také náměty, jak ukládat nastavení pod nějakým jménem (podobně jako to navrhujete Vy ve svém prvním příspěvku).  To mi však stále připadalo zbytečně složité pro uživatele i pro programátora.  Teprve při práci na řadě technologicky stejných desek jsem si ujasnil, že to asi vyžaduje spíše tohle.  (Velmi volnou analogii můžete vidět i u zoomu -- tam také dle potřeby zvětšujete a zmenšujete, aniž byste se staral, jaké konkrétní procento zvětšení tím nastavíte.)

Takovéto značení ve schematu podporuje Formica již od počátku: zatímco "index vývodu" musí být číslo (odpovídající číslu vývodu v Layoutu), "návěští vývodu" může být řetězec.  Způsob zadávání je zřejmý z obrázku.

Indexy je ovšem třeba v dialogu zadávat až po návěštích (jinak by se návěští odvozovala automaticky).  Možná stojí za úvahu nečíslovat zcela průběžně, ale pin B1 očíslovat 21, C1 41 atd., aby byla vzájemná korespondence obou značení lépe patrná.

Po sesbírání prvních zkušeností jsem skutečně přidal příkazy Graphics | Roll Down a Graphics | Roll Up, které rotují obsah zásobníku tak, že se na obrazovku dostane naposled vložené, resp. nejdříve vložené (a dosud nezapomenuté) nastavení.  Rotuje se ovšem "skrz" aktuální nastavení (podobně jako v procesorech fungují instrukce Rotate Left / Right Through Carry).  Pokusný program s těmito příkazy si můžete stáhnout z archivu www.formica.cz/files/Layout-p98-test.zip .

Zároveň tam (zcela provizorně) zobrazuji i hodnotu stack pointeru, aby měl uživatel alespoň trochu představu, co vše je uloženo.  Protože však ukazuje na vrchol zásobníku (který je v poli indexovaném od nuly) a protože aktuální nastavení je mimo zásobník, rotace probíhá mezi  položkami, jejichž počet ve skutečnosti je o dva vyšší.

Pokud toto vše někomu připadá odpudivě programátorské, mohu s ním jedině souhlasit.  Východisko bych však hledal spíše v nalezení intuitivnějších a atraktivnějších jmen příkazů.  Jinými slovy, koncepce, kdy si uživatel ukládá svoje jednotlivá nastavení grafiky anonymně a pak mezi nimi může cyklicky přepínat, mi připadá výhodnější a sympatičtější než nastavení ukládat a vyvolávat např. pod předdefinovanými čísly nebo uživatelem zadanými jmény.  Myslím si, že uživatel jména ani čísla celkem nepotřebuje (vymýšlet si a pak pamatovat...) v situaci, kdy může snadno přepínat z jednoho anonymního nastavení na následující tak dlouho, až před sebou na obrazovce uvidí to, které mu vyhoví.

Operovat zde s myšlenkou pokroku by mi připadalo trochu nadnesené, tohle je celkem přízemní záležitost.  Označím-li PNLN a PCBN jména příslušných souborů včetně cesty, pak je jasné, že defaultní PNLN mohu měnit jedině na základě nějaké události.  Tou může být např.:
1 start programu
1a start programu bez parametrů
1b start programu s PCBN jako parametrem
1c start programu s PNLN jako parametrem
2a otevření dialogu pro PNLN
2b vložení nového PNLN v dialogu
3 změna PCBN
3a změna PCBN při čtení PCB souboru
3aa - úspěšném
3ab - neúspěšném z důvodu neexistence (tj. otvírání/vytváření nového souboru)
3ac - neúspěšném z jiného důvodu
3b změna PCBN při zápisu PCB souboru (tj. ukládání desky pod novým jménem)
4 čtení PCB souboru bez změny PCBN (tj. aktualizace desky)
5 zápis PCB souboru bez změny PCBN (tj. průběžné ukládání práce na disk)
Změna defaultního PNLN by přitom asi ve všech případech představovala jeho odvození od aktuálního PCBN.

V současnosti se změna provádí jen v případech 1c, 2b.  Možná by mělo smysl uvažovat (jednotlivě) o doplnění případů 1b, 3 (anebo 3aa, 3ab, 3b), snad 4.   

Uvidím, vyvolá-li toto téma nějakou další odezvu.  (Něco z toho asi totiž již kdysi bylo diskutováno, a zřejmě tehdy byly nějaké výhrady, kvůli nimž jsem ponechal dosavadní řešení.)  Naprogramovat požadované chování, nejsou-li o něm žádné pochybnosti, je ostatně daleko méně pracné než sepisovat takovéto příspěvky.

Layout si pamatuje pathname a filename naposled čteného PNL souboru.  Otázka je, co by se mělo udělat, když v okamžiku otvírání dialogu pro zadání jména PNL souboru není zapamatovaná cesta k němu totožná s cestou k PCB souboru.  Když tam totiž vnutím cestu k PCB, musím zahodit i jméno PNL souboru, protože už nemá smysl.  Jak by se to líbilo uživatelům, kteří mají PNL soubory v jiném adresáři než desky?

Abych se přiznal, mě to zas tak strašlivá chyba nepřipadá.  Jde o chování popsané v helpu -- levému tlačítku zde odpovídá Enter, pravému Esc (a střednímu No) -- a je od přechodu pod Windows, tedy již sedm let, stále stejné.  Koneckonců tam máte ještě backup.

Již několikrát jsem měl nutkání nahradit tyto tradiční dialogy windowsovskými (i včetně ošetření maker), ale vždy se mi zdálo, že uživatelé jsou celkem zvyklí na současné chování.  Jednou to jistě udělám, jen co si rozmyslím dostatečně konsistentní chování.

Obecně jistě platí (a nejen pro návrhové systémy), že uživatel může dost snadno udělat něco jiného, než chce.  Podle mého názoru hlavním cílem programu není mu v tom zabránit, nýbrž snížit pravděpodobnost, že něco takového udělá a zároveň si toho nevšimne (tedy dříve, než se mu vrátí osazená série desek z výroby).  To je třeba důvod, proč se program ptá před smazáním jednotlivé součástky:  tu sice lze snadno ihned vrátit z undo bufferu, ale vyskytly se případy, že si uživatel smazal velkou součástku (např. typovou desku s konektorem), aniž by si toho včas všiml.  (Oproti tomu, když uživatel maže okénko, musí být srozuměn s tím, že si tak může smazat i součástky, takže tam dotaz asi není potřeba.)

Odhlédneme-li od otázek kompatibility, věc má podle mého názoru pouze jediné dobré řešení:  Pady identifikovat jmény spíše než dosavadními čísly.  Samozřejmě i ve jménech se mohou vyskytnout konflikty, ale ty lze vždy ošetřit vytvořením nového unikátního jména ve tvaru <jméno typu padu>.<pořadové číslo> nebo <jméno knihovny>.<jméno typu padu> apod. 

??ísla se dosud užívají proto, že jednak by se k zavedení jmen hodila spíše dialogová okna ve stylu exploreru (která ale nejsou dost dobře slučitelná se současným ovládáním makry), jednak (trochu k mému překvapení) o zavedení jmen dosud nebyl příliš velký zájem -- pokročilejší uživatelé si většinou nějak zvykli na číslování a ti ostatní zřejmě tolik nepotřebují typy padů doplňovat, takže na zde diskutované problémy ani nenarazí.

To, co navrhujete Vy (tedy v podstatě anonymní pady), bych považoval za krok zpět.  Je sice pravda, že některé jednodušší systémy to právě takhle mají řešené, jenže pak uživateli v řadě situací chybějí nástroje, jak určit, který typ padu má na mysli.  Na druhé straně je nemyslitelné si každý typ padu vytvářet znovu, kdykoliv jej chce znovu užít, -- SMD pad může snadno mít 2 rozměry (plus případnou excentricitu) na každé ze tří vrstev (měď, maska, pasta) -- takže jej uživatel bude chtít alespoň odněkud okopírovat.  Avšak pokud typ padu nemá žádný identifikátor, půjde na něj nanejvýš ukázat na desce myší, zatímco složitější a efektivnější operace nebudou vůbec padat v úvahu.

Právě proto, že je jen rozpracovaná.  To, že je naprogramovaná nová databáze (dovolující např. otáčení o obecný úhel nebo zrovna ty pojmenované typy pájecích bodů), je málo platné, když nejsou dokončeny editační operace ani systém menu.  Od specifikací bývá k prodejnému programu docela dlouhá cesta.

Něco Vám pošlu e-mailem.

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.

Jak jsem v?era napsal, vystavený program p?evádí formát RS-274D.  (A to v n?m ješt? nesm?jí být ani taková neškodná makra, jako je G54 z Formiky, která by ?lov?k ostatn? mohl zahodit i textovým editorem -- nic podstatného to ned?lá, jen upozor?uje na vým?nu clonky, která se stejn? pozná z následujícího D-kódu.)  Vaše soubory jsou v RS-274X, což je nejsnáze vid?t práv? z t?ch "%".

Edit 25.7.2007: V n??em asi bylo nedorozum?ní -- práv? jsem si konverzi soubor? vygenerovaných Formikou sám zkusil, jen tak bez jakéhokoliv konfigura?ního souboru, a po syntaktické stránce tam problém nebyl v?bec žádný.  G54 ani nic podobného ve skute?nosti nijaké potíže ned?lá, takže celá závorka, kterou jsem o odstavec výše napsal, je bezp?edm?tná.  M?žete se p?esv?d?it na tomto p?íkladu: www.formica.cz/files/forum/r-gerber-zpetne-cteni.zip .  (Konfigura?ní soubor pat?í k Layoutu, byl užit p?i generování gerberovských soubor?.)  Bez konfigura?ního souboru pro R-GERBER.EXE pochopiteln? vycházejí logické typy i vrstvy nesmyslné, to však je jiná otázka.  Pozor, protože jde o DOSovský program, je nutno jména soubor? vždy zadávat ve formátu 8.3 .

Program pro filtraci RS-274X, který jsem také zmínil, ovšem není s vystaveným totožný.  Momentáln? od n?j mám jen zdrojový text.  Snad budu mít ve?er chvilku se na n?j podívat blíže, a s ním i na Vaše soubory.

P?ed více než 10 lety jsem napsal p?evodní program z formátu Gerber RS-274D.  Nebyl myslím nikdy ší?en, ale m?žete si jej stáhnout zde: www.formica.cz/files/forum/R-GERBER.ZIP .  Uživatelský komfort od n?j ne?ekejte, ale kdybyste pot?eboval, možná bych k tomu n?kde našel i zdrojové texty.

Asi neuškodí znovu p?ipomenout, že klasický formát Gerber se odvolává prost?ednictvím tzv. D-kód? na clonky clonkového kotou?e, avšak popis jejich rozm?r? neobsahuje.  Takovéto informace (kup?íkladu že D21 je ?tvere?ek o stran? 1,5 mm, apod.) je proto t?eba p?edat n?jakým paralelním kanálem.  Vedle gerberovských soubor? vystavených na internetu bývají ob?as i n?jaké textové soubory s popisem clonek (?asto tytéž soubory, které provázely ty první k výrobci -- jsou ostatn? obdobou pr?vodních soubor?, které z firmy zasíláte výrobci).  Nejsou-li dostupné, nezbyde, než gerberovské soubory prohlédnout a rozm?ry si domyslet.  U t?ch plošných cívek, které zmi?ujete, by to asi nem?l být velký problém.

Informace o clonkách je samoz?ejm? t?eba n?kudy p?edat i výšezmín?nému programu.  K tomu slouží jeho konfigura?ní soubor, jehož p?íklad zde rad?ji uvádím (v zipu totiž ?áste?n? je ješt? ?eština Kamenických):

{ KONFIGURA?NÍ SOUBOR PROGRAMU R-GERBER.EXE }
{ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ }

{ Soubor R-Gerber.Cfg je konfigura?ní soubor pro program R-Gerber.Exe, který
  p?evádí p?íkazové soubory pro fotoplottery Gerber do formátu desek systemu
  FORMICA 4.0 (*.PCB).                                                       }

{ Z hlediska syntaxe tento konfigura?ní soubor obsahuje (vedle libovolných
  komentá??, uzav?ených ve složených závorkách) pouze celá ?ísla se znaménkem.
  Soubor sestává ze dvou (tri) ?ástí: první definuje transformaci sou?adnic
  z jednotek fotoplotteru do vnitrnich jednotek programu (0,001" ci 0,025 mm)
  druhá korespondenci mezi clonkami fotoplotteru a logickými typy základních
  prvk? v systému FORMICA 4.0.                                               }


{ 1. P?EVOD SOU?ADNIC }
{ ~~~~~~~~~~~~~~~~~~~ }

     1000   { hodnota Px,                                                    }
     1000   { hodnota Qx; koeficienty pro p?epo?et sou?adnic   (Qx > 0)      }
      000   { hodnota Dx; vodorovný offset, udaný v jednotkách fotoplotteru  }

     1000   { hodnota Py,                                                    }
     1000   { hodnota Qy; koeficienty pro p?epo?et sou?adnic   (Qy > 0)      }
      000   { hodnota Dy; svislý offset, udaný v jednotkách fotoplotteru     }

{ Výše definované hodnoty jsou použity k p?epo?tu sou?adnic podle vztah?

  GridX := Round (Px * Int (GerberX - Dx) / Qx)

  GridY := Round (Py * Int (GerberY - Dy) / Qy)                              }


{ 2. CISLO VRSTVY }
{ ~~~~~~~~~~~~~~~ }

      14 { cislo vrstvy, na kterou budou umisteny segmenty                }


{ 3. P?EVOD CLONEK }
{ ~~~~~~~~~~~~~~~~ }

{ P?evod kód? clonek na logické typy základních prvk? je definován tabulkou,
  obsahující libovolný po?et trojic celých ?ísel.   První ?íslo z trojice
  vždy ur?uje kód clonky na clonkovém kotu?i, druhé, resp. t?etí ?íslo udává
  logický typ spojové ?áry, resp. pájecího bodu, který bude generován,
  jestliže je clonka s tímto kódem použita pro kreslení spojové ?áry, resp.
  expozici pájecího bodu.                                                    }

{ P?ípustné rozsahy hodnot jsou 10 až 99 pro kód clonky, 0 až 15 pro logický
  typ spojové ?áry a 0 až 63 typ pájecího bodu.   Clonky, jejichž kódy se
  v tabulce nevyskytují, jsou prevedeny na (logicke typy)-10 nebo potlaceny. }

{ kód clonky   typ spojové ?áry   typ pájecího bodu                          }
     10               1                  -1
     11               3                  -1 {potlaceno}
     12               4                  -1
     13               5                  -1
     14              10                  -1
     15              11                  -1
     70              -1 {potlaceno}       3
     71              -1 {potlaceno}       3 {R 15 ???}
     20              -1 {potlaceno}       4
     21              -1 {potlaceno}      16 {R}
     22              -1 {potlaceno}       7 {???}
     23              -1 {potlaceno}       7 {R}
     24              -1 {potlaceno}       8
     25              -1 {potlaceno}       8 {R}
     26              -1 {potlaceno}      12
     30              -1 {potlaceno}       4
     31              -1 {potlaceno}      16 {R}
     32              -1 {potlaceno}       7 {???}
     33              -1 {potlaceno}       7 {R}


{ POZNAMKY                                                                   }
{ ========

  1) Program a zejmena jeho popis je ve zcela provizornim stavu.
  2) Je-li k dispozici puvodni navrhovy system, je treba mu zabranit
     v rozkreslovani pajecich bodu, samozrejme i za cenu, ze se k prevodu
     pouziji "smluvene" D-kody.   Jinak by totiz nebyl program R-Gerber
     schopen odlisit pajeci body od spojovych car.
  3) Je vhodne mit dva konfiguracni soubory, pro kazdou stranu desky jeden.
     V jednom z nich je pak mozno potlacit vrtane (vicevrstve) pajeci body,
     ktere by se jinak ve vysledne desce objevovaly na temze miste dvakrat.  }

Program je t?eba opakovan? užít na jednotlivé vrstvy (tj. gerberovské soubory) a vygenerované PCB soubory se?íst dohromady v editoru Layout.  Nebude-li Vám n?co jasné (a prostoru pro nejasnosti tu asi je víc než dost), zeptejte se nebo pošlete výchozí soubory.

Jiná v?c však jsou soubory ve formátu RS-274X, které mj. obsahují definice clonek (mezi znaky "%" -- podle toho je poznáte).  Na to jsem si provizorn? také napsal kus programu (který jsem užil nap?. k p?evodu té desky SBC6120).  Definice sice ne?te, alespo? je však zahazuje, takže lze v zásad? užít výše popsaný postup.

P?evod z Eaglu je zcela odlišné téma a založím tudíž pro n?j další vlákno.