Automaticke prejmenovani labelu - namet (makra)

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).

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).