1 Naposledy upravil: Tomáš Och (2010-04-14 08:45:14)

Téma: Automaticka aktualizace soucastek ve schematu - namet

Dobry den, kolega pri tvorbe schematu kopiruje bloky schemat z jinych, starsich projektu. Pro takoveto ucely mame vytvoreny referencni soubor s predem nakreslenymi bloky. Ale jednak je kolega tu a tam ignoruje, a take je kolikrat potreba kopirovat blok, ktery v referencnim souboru predpripraveny nemame, protoze je moc specificky na to, aby se pouzival casteji.
Me to ovsem pak trochu pridelava praci v tom smyslu, ze postupem casu se jednotlive soucastky v knihovnach upravuji, setriduji, davaji do kupy, opravuji jejich jmena a pridavaji nove varianty pouzder.
To ma za nasledek, ze
1) se ze starych projektu kopiruji stare verze soucastek ve schematiku,
2) pri nasati netlistu do desky mi vyskakuji soucastky, ktere maji prirazena pro layout jiz neznama jmena pouzder,
3) kolega nevi, ze mame k dane soucastce napr.nadefinovana nova pouzdra,
4) pri dokonceni upravy takove soucastky nesmim zapomenout jit do referencniho souboru s pripravenymi bloky a aktualizovat tam tu soucastku.

Existuje na to moznost Browse/Edit / Remove / Remove All , ovsem to znamena destrukci i pro lokalne upravene soucastky, takze ne vzdy je to pouzitelne. Navic musim mit otevreny jeste druhy soubor, kde budu mit stav pred zasahem, abych mel srovnani prorucni aktualizaci soucastek, ktere pod puvodnim nazvem v knihovne nejsou. Ano, mohu to udelat i tak, ze oznacim vsechny komponenty a vypustim z vyberu rucne upravene. Ale ne vzdy jsou upravene vizualne, takze je nemusim hned poznat a vsimnout si vsech.


Proto mne napadla moznost, kdy bych spustil funkci, ktera jen porovna parametry soucastky ve schematu a tehoz nazvu v knihovne, a zobrazi seznam lisicich se ci nenalezenych soucastek. Je neco takoveho jednoducheho mozne pridat?
Mozna by stalo za uvahu toto implementovat i do Layoutu..

2

Re: Automaticka aktualizace soucastek ve schematu - namet

Dobrý den,

děkuji za námět. Takové funkce v editoru zatím nejsou. Pokud by šlo jen o to jmenovitě vypsat či ve schematu zvýraznit předlohy součástek, které se jakkoli liší od stejnojmenných v knihovně, neměl by to být velký problém. Zkusím se na to výhledově podívat. Nicméně detailní porovnání nalezených dvojic a posouzení, která z nich je "novější", musí zůstat na uživateli. "Automatickou aktualizaci" slíbit s čistým svědomím nemohu.

3

Re: Automaticka aktualizace soucastek ve schematu - namet

Dobry den, cim dal casteji narazime na potrebu udrzovat (nejen) ve schematu aktualni podoby soucastek, protoze casto se nektere casti kopiruji z jinych starsich schemat - nekresli se to vzdy odznovu.
Pisete o urceni, ktera verze je novejsi. To ani neni potreba, knihovna je od toho, aby obsahovala referencni podobu soucastky. Uzivatel by max. mohl zakazat aktualizaci konkretni souc., pokud ji pro potreby konkretniho schematu upravil. Jinak ale jde jen o to, rict, ktere souc. se oproti knihovne lisi, a tyto aktualizovat nikoliv zdlouhavym rucnim zpusobem, ale programove. Nyni lze aktualizovat bud po jednom, nebo vse, coz ne vzdy je pouzitelne prave kvuli moznym (i skrytym) lokalnim upravam soucastky.

4

Re: Automaticka aktualizace soucastek ve schematu - namet

Dobrý den,

předpokládejme tedy, že v menu Browse/Edit existuje příkaz, který porovná všechny předlohy v lokální knihovně schematu (i ty, které nejsou použity) se stenojmennými v knihovně (pokud knihovna obsahuje několik různých předloh stejného jména, použije se pro porovnání jen ta s nejvyšší prioritou) a vytvoří seznam/menu obsahující jména předloh, které se liší od referenčních (knihovních). Seznam tak obsahuje všechny kandidáty na aktualizaci.

Pak by pro popisované účely měla postačit možnost označit v tomto seznamu předlohy, které se mají vyměnit. Prováděcí příkaz by mohl zahrnovat vymazání (obdoba Remove) označených předloh (přesněji synonym) a volání procedury Reload. Tak nějak byste si to představoval?

Seznam předloh, jejichž referenční podoby v knihovně neexistují, je také možno vytvořit. To jsou ale kandidáti na přejmenování nebo uložení do knihovny, takže ty dva seznamy není vhodné směšovat.

5

Re: Automaticka aktualizace soucastek ve schematu - namet

Je otazka, jestli to ma zahrnovat i nepouzite predlohy (ty by nebylo od veci take kontrolovat na aktualnost), kdyz funkce nezobrazi seznam predloh, ale jen oznaci ty, ktere jsou pouzite. Na druhou stranu, pokud mam knihovnu soucastek, pak mi prepinac pro ukladani/neukladani nepouzitych predloh prijde (dnes jiz) zbytecny. V pripade, ze by se nepouzite predlohy neukladaly, pak by se nemusely kontrolovat na aktualnost.

Jak by vypadal takovy postup prace? Vzhledem k tomu, ze uzivatel ma potrebu vyloucit lokalne upravene komponenty (typicky napajeni u IO), pak by musel prikaz pracovat na dve casti.
Pokud by se ale zobrazil seznam neaktualnich ci v knihovne neexistujicich predloh, byla by moznost u kazde polozky treba zrusit fajfku zatrzitka a pak klepnout na Execute. Ty neexistujici by byly razeny na konci seznamu, treba s jiz zrusenym zatrzitkem. Myslim si, ze to nejsou tak uplne rozdilne veci.. Navrhar tam vidi tri veci: lisici se soucastky (stare, jim pozmenene) a neexistujici (jim nove vytvorene). Tak hned vi, ktere ma stare, ktere zmenene a ktere musi do knihovny teprve nakopirovat.

6

Re: Automaticka aktualizace soucastek ve schematu - namet

Předpokládejme, že seznam obsahuje lokálně změněné předlohy. U každého jména změněné předlohy je možno nastavit, zda se má aktualizovat (výchozí hodnota) nebo ne. Pak se stiskem Execute předlohy aktualizují.

A ty v knihovně neexistující předlohy by v seznamu byly zobrazeny jen jako přídavná informace? Nepovažuji za vhodné provádět s nimi v rámci téhož Execute jakoukoli smysluplnou akci. Takovou akcí by přitom mohlo být jejich uložení do nového knihovního souboru. (Ten by zrovna mohl posloužit jako příklad souboru obsahujícího jen předlohy.) Proto bych s nimi raději zacházel odděleně.

7

Re: Automaticka aktualizace soucastek ve schematu - namet

S v knihovne neexistujicimi predlohami bych asi radeji nic neprovadel, uzivatel si spise chce do knihovny predlohu vlozit sam, protoze kazdy si tam precijen udrzuje nejaky poradek. Podle mne by bylo vhodne zobrazit jen jednu tabulku se vsemi nesrovnalostmi, i kdyz uznavam, ze by bylo pro uzivatele matouci to, ze Execute by z knihovny nahralo predlohy, ale neexistujici by do knihovny nepridalo.
V takovem pripade necht se "Execute" prejmenuje na "Update From Library".
Pokud chcete radeji pracovat se dvema tabulkami, tak konec koncu, proc ne. Jen mi prijde, ze se zas rozvetvuje menu a program se stava o maly kousek slozitejsim. Takhle by to bylo v jednom vypisu pod spolecnym pojmenovanim podstaty tabulky - rozdily mezi knihovnou a schematem.