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

Tak jsem to samozřejmě myslel.  Je to teď v archivu www.formica.cz/files/Layout-p99-test107.zip , navíc (nejen) z důvodu symetrie i v menu pro výběr typu spojové čáry.  Vedlejší výhody jsou v možnosti využití i při množinových operacích a úpravách rozměrů, kdy člověk zároveň defaultní typ pájecího bodu či spojové čáry změnit zpravidla ani nechce.  (Naopak nežádoucí vedlejší účinek by mohl pocítit ten, kdo má makra nastavující typ nějakého pevného čísla -- což snad není příliš pravděpodobné --, anebo kdo už má zmechanizované po zobrazení menu stisknout klávesu s číslicí.)

V posledních letech pozoruji, že velká část potenciálních nových uživatelů očekává nějaký návrhový systém ovládaný ikonkami, nejlépe velikosti alespoň 64 x 64 pixelů.  Systémem, který se ovládá jinak, se vůbec nezabývají.

Tady asi nemůže být sporu, že právě vytvořená vlastnost je k výše popsanému v naprostém protikladu -- už třeba proto, že podtržené "p" v menu bez podstatného úsilí neuvidíte, nevíte-li, že tam nějaké můžete hledat; musíte zkrátka vědět, že tam nějaké může být.

Zde jsem měl na mysli především pouzdra (nebo obecněji součástky).  Myšlenka je ta, že když už se člověk jednou dobádal toho, který objekt z knihovny vůbec potřebuje a jak ten se vlastně jmenuje, může být užitečné výsledek tohoto úsilí někde uchovat.  Pochopitelně to asi bude i kdesi na desce či ve schematu, ale tam by to zas musel hledat jiným úsilím.  Chache by se mohl ukládat do konfigurace a tak přenášet informace i mezi jednotlivými projekty.  A u pájecích bodů bych to viděl podobně -- cílem by mělo být rozšíření počtu situací, kdy na čísla jejich typů může člověk zapomenout.

Počátek relativních souřadnic se nastaví na hodnoty Origin X, Origin Y.  Při otevření menu se tam dostanou momentální souřadnice ukazatele, ale můžete si tam vložit, co chcete.  Module je příští velikost modulu rastru čili kroku ukazatele (užitá šipkami).  (Je zde držena odděleně od hodnoty v menu Options, aby se tak její hodnota někde uchovala a nebyla přepsána rastrem pro běžnou práci.)

Dáte-li Apply Both, skutečně se to chová zhruba tak, jak jste popsal v poslední větě.  Není mi proto jasné, na jaký problém jste vlastně narazil.

Nevím, kam přesně myslíte.  Menu Place | Pad (jakožto obvyklé menu s nějakými příkazy) vlastně neexistuje a do menu Place bych to dávat nechtěl, stalo by se tím zbytečně detailní (či široké) a hlavně nevyvážené.

Znamenalo by to naprogramovat další režim ukazatele, což by se z technického hlediska bezpochyby provést dalo.  Byl by ovšem už asi tak šedesátý -- v barvitém protikladu k diskusi, která běžela před pár měsíci na www.mcu.cz/forum/ a kde kdosi zastával názor, že návrhový systém by režimů měl mít co nejméně, nejlépe jen jediný (tj. de facto žádný).  Podobně jsem si tuhle říkal, zda bych neměl doplnit režim pro umísování obdélníků (ne jakožto nové entity, nýbrž tvořených pouze čtveřicí segmentů), případně obdélníků se zaoblenými rohy...

Před několika lety se na mne obrátil Ing. Jakimov s požadavkem, který zřejmě vycházel z podobných motivů, totiž prodloužit krok ukazatele až na 10 cm.  (Neříkám, že by na všechny krabičky stačil.)  Parametry a příkazy s tím spojené jsou dnes v menu Place | Rel. Coords, s jehož pomocí si můžete kupříkladu nastavit počátek relativních souřadnic do středu jednoho upevňovacího otvoru, a šipkou pak odtud přeskočit na druhý.  Možná byste si mohl vyzkoušet jejich použitelnost pro zamýšlené funkce dříve, než bychom dále uvažovali o doplnění nového režimu.

Jinak v souvislosti s krabičkami, apod. si dovoluji upozornit na příkazy v testovací verzi, diskutované zde.

Dobrý den, to je způsobeno tím, že jsem si při překladu zmíněné testovací verze v nastavení kompilátoru omylem vypnul přepínač, který povoluje komunikaci se síovým klíčem.  Citovaná chyba znamená, že nebyl nalezen lokální klíč (ten tam sice asi máte, ale skrz WINE není vidět), a takto přeložený program skončí, místo co by začal hledat síový.

Shodou okolností jsem si toho (po upozornění) všiml až ve středu a shodou okolností jsem to řešil právě tak, jak navrhujete.  Testovací instalační sadu si můžete stáhnout zde: http://www.formica.cz/files/Layout440p99p-test.exe .

Vedle toho byste si mohl zkusit instalovat i prohlížeč pouzder: http://www.formica.cz/forum/viewtopic.php?id=75 .  Ten v oficiálních verzích zatím není a pod WINE jej myslím nikdo dosud nezkoušel, ale pokud by fungoval, snad by Vám byl k užitku.

Než o námětu z Vašeho prvního odstavce uvažovat je možná jednodušší vyzkoušet, jak by to vypadalo.  Pro ten účel jsem si trochu upravil driver a jednu Vaši desku (bylo nutno se zbavit rohového razítka, jakkoliv je pěkné, a asi tři nápisy kousek vtlačit dovnitř desky, třebaže nebyly na zobrazovaných vrstvách).  Výsledek vidíte zde: www.formica.cz/files/forum/KOBRA-A_B-pokusy.pdf .

Pokusný driver si můžete stáhnout tady: www.formica.cz/files/forum/PDF098B.zip včetně konfiguračního souboru, jímž byla výšeuvedená ukázka vygenerována.  Driver využívá toho, že mu jsou předány souřadnice obdélníku opsaného motivu, takže pro obdélníkovou desku není potřeba zavádět samostatnou vrstvu.

Pro dosažení zamýšleného efektu asi budete chtít povypínat vrstvy 1, 2, 21, 22 a místo nich zapnout 0, 23.  To už ale souvisí s ovládáním driveru (podobně jako přesná volba barev).  Nejprve by bylo třeba spíše posoudit, zda takovéto zobrazení může skutečně být někomu k užitku.

O černé součástky jsem se ani nepokoušel, ale můžete si zkusit upravit konfigurační soubor, vyrobit nějakou vlastní ukázku PDF a vystavit ji zde.

Váš dotaz bych si dovolil trošku přeformulovat:  Jak dostanu objekty z vrstvy 23 na vrstvu 21 ?

Postup může být tento:
  0) Ubezpečím se, že nemám nic označeného (např. užitím makra Ctrl-U).
  1) Označím všechny objekty na vrstvě 23 příkazem Select | Select | One Layer ... (23).
  2) Přesunu je na vrstvu 21 příkazem Edit | Change | Layer ... (21).

To vše.  Pro úplnost bych ale ještě poznamenal:
  * Takhle jednoduše to jde též proto, že na uvedených vrstvách nemáte pájecí body, jinak byste musel nějak ošetřit i přesun jejich plošek.
  * Také byste mohl nechat obě vrstvy oddělené až do generování technologických souborů, a teprve tehdy byste zapsal vrstvu 21 i 23 společně do jednoho souboru (stačí nastavit stejnou příponu).

Dobrý den,

Ing. Hamáček by Vás měl kontaktovat na Vašem e-mailu, případně na adrese, kterou jste mu zadal při registraci výše uvedeného S/N.

Kdyby se v čemkoliv vyskytl problém (doba dovolených apod.), prosím spojte se přímo se mnou (horsky@formica.cz nebo +420+272762440).

Jako řešení problému uvedeného na počátku tohoto vlákna, které by co nejlépe vyhovovalo koncepci systému Formica, se mi spíše než samostatný příkaz jeví makro.  Důvodem je asi hlavně to, že v případě příkazu by různé detaily (na něž je upozorněno výše) musely být ošetřeny např. dalšími přepínači, což je těžkopádné a nepřehledné.  Naopak makro si uživatel může modifikovat sám, jakmile si ujasní, co přesně požaduje, anebo si od něj může odvodit makra další.

Makro může vypadat například takto:

Macros (
  <Ctrl-F11> "změň označené texty" (
    <Alt-E> <o> <a> <t> <t> <*> <Enter> {vztahuje se na všechny označené}
    <n> <Ctrl-Alt-A>                    {čeká na vložení textu}
    <i> <Ctrl-Home> )
  <Shift-F11> "označ a přejmenuj vodič" (
    <Ctrl-U>                            {odznačí, aby nezasáhl jiné vodiče}
    <Alt-E> <o> <n> <Enter>             {označí vodič pod ukazatelem}
    <Alt-O> <e> <n>                     {aktivuje průběžnou kontrolu netlistu}
    <End> <UArr> <UArr> <UArr>
    <Ctrl-PgDn>                         {... zde jí nastaví hodnotu On}
    <Ctrl-F11> )                        {zavolá připravené makro}
)

??lohu se vyplatí rozdělit do dvou maker, a také do dvou hlavních kroků:
  1) označit vodič, jehož labely se mají přejmenovat, pochopitelně včetně těch labelů;
  2) změnit označené texty na řetězec zadaný uživatelem;
Makro Ctrl-F11 provede jen druhý krok (který se může hodit i samostatně, a nejen na labely -- proto je v odděleném makru).  Makro Shift-F11 označí vodič pod ukazatelem a pak vyvolá Ctrl-F11.  Mezitím však udělá dvě akce navíc:
  * odznačí dříve označené objekty, aby makro mimovolně nezměnilo ještě další labely či texty;
  * aktivuje průběžnou kontrolu netlistu, která varuje v případě výskytu problémů diskutovaných výše (indikace přitom bude kumulativní, takže pokud se netlist lišil od referenčního již před vyvoláním makra, informace o tom se tím neztratí).

Nic ovšem není dokonalé, a tak si i zde lze představit (asi ne zcela běžný) případ, kdy makro Shift-F11 nebude fungovat tak, jak je zamýšleno:  různé labely na jednom vodiči (sloužící např. k propojení napájecích napětí), přičemž uživatel je nechce přejmenovat všechny.  Kdybychom toto chtěli ošetřit, stačí však mít variantu makra, která místo automaticky zapsané hvězdičky počká na uživatelem vloženou masku (rozlišující měněné labely od ostatních).

Pokusil bych se na to s dovolením podívat o kousek obecněji.  Zřejmě lze rozlišit dva druhy situací:
  1) Uživatel si přeje přejmenovat nějaký objekt (neb mu nové jméno připadá výstižnější, staré chce užít pro něco jiného, apod.) aniž by tím chtěl zapojení elektricky změnit.
  2) Cílem přejmenování je změna zapojení (např. daný pin MCU připojit na jiný signál, atd.).
U kterých objektů by takovéto rozlišování dávalo smysl?  Napadají mne jen součástky s více sekcemi a již zmíněné labely.  U součástek program nabízí celkem propracovaný výběr (ačkoliv explicitně neříká, která položka vede ke změně zapojení a která ne).

U labelů asi přicházejí v úvahu možnosti (a) přejmenovat tento -- (b) přejmenovat všechny -- (c) přejmenovat právě vybrané.  Přitom v závislosti na okolnostech kterákoliv z nich může, ale nemusí vést ke změně zapojení (např. z důvodu vazby na napájecí piny, jak zmiňuje Dr. Křivka, anebo proto, že nové jméno je ve schematu již užito). 

Jest vskutku otázkou, zda by šlo po programu spravedlivě požadovat, aby uhodl, zda uživatel zapojení měnit chce, či naopak nechce.  Podobně by bylo trochu absurdní, aby pro stejnou akci existovaly dva příkazy, z nichž jeden by skončil chybou, pokud by měl zapojení změnit.  Příkaz by také mohl předem hlásit, zda změna zapojení nastane; v porovnání s dosaženým výsledkem mi ale jeho naprogramování připadá obtížné (a to bych to programovat ani nemusel já).

Do některé z příštích verzí by se mi proto více líbilo navázat na průběžnou kontrolu netlistu.  Teoreticky totiž existují možnosti, jak ji zjemnit rozlišením např. na
  1) změny netlistu (což je mj. případ přejmenování součástky, protože to nezachová vazbu na desku);
  2) změny zapojení;
  3) změny jmen;
  4) změny hodnot (zachovávají topologii zapojení i obrazec desky);
  5) změny pouzder (zachovávají topologii zapojení), atd.

Opět je otázka, jestli by to stálo za programátorskou práci.  (V bodu 2 by navíc asi nemohlo jít o zobecnění stávajícího řešení, které porovnává dva netlisty.  Isomorfismus grafů je problém z třídy NP, takže pochybuji, zda by u složitějších schemat šel počítat v reálném čase.)  Odpověď na tuto otázku by proto měla vycházet z toho, jak často je dnes průběžná kontrola netlistu vůbec využívána.

Pro zajímavost, přejmenujete-li label stávajícím způsobem (tj. množinovou operací), průběžná kontrola pozná, zda to vedlo ke změně zapojení (by i jen "díky" tomu, že labely se do netlistu nedostanou, takže jejich přejmenování jej ještě nemusí nutně změnit).