Nejste přihlášen. Přihlaste se, nebo se zaregistrujte.
Diskusní fórum k návrhovému systému Formica » Příspěvky od Petr Horský
ad 2) Dosud nevím o případu, kdy by po překročení počtu prvků mizely nějaké "staré". Na Vaši desku se podívám trochu blíže, jen co k tomu najdu chvilku. Zatím jsem ani podrobněji nezjišoval, co se vlastně ztratilo.
ad 4) Prosím pošlete mi aktuální signaturu programu (viz menu Help).
Dobrý den, než budu mít čas se na to podívat podrobněji, uvedl bych toto:
1) Jestliže měď na zaslané desce rozliji v rastru 2 mily (0,0508 mm) místo 1 mil, jde to udělat najednou a nepozoruji žádné problémy s kvalitou její hranice. (Výsledek bude mít 92800 prvků.)
2) Během operace rozlévání mědi se nejprve na její hranici vytvářejí segmenty o délce strany či úhlopříčky základního čtverce rastru (jinými slovy, spousta krátkých segmentů, je-li rastr jemný). Jako další krok jsou pak navazující segmenty spojovány, což jejich počet opět redukuje. Z toho důvodu může být pro provedení operace třeba více segmentů (dokonce podstatně více v případě zbytečně jemného rastru), než odpovídá jejímu výsledku.
3) Po chybě vyvolané překročením mezí pochopitelně deska bude v nekonsistentním stavu. Obecně pokládám za vhodnější povolit její zápis na disk (aby mohla být otevřena ve větší verzi nebo třeba odeslána autorovi); dalo by se uvažovat o změně jména souboru podobně jako u chyb, které se projeví hned během jeho čtení.
4) Přejete-li si, mohu Vám vyrobit certifikát, který dovolí pracovat až s 500000 prvků (což stojí nejméně 2,4 MB paměti navíc, ale práci to nezpomaluje, dokud tento počet nevyužijete). Místo toho bych však vždy doporučoval zvažovat, jaký rastr je pro rozlévání mědi opravdu potřeba.
Verze 4.30 měla About Box takovýto
a sériové číslo je v něm uvedeno hned za "S/N".
Dobrý den, zdá se mi, že by pro Vás vhodným upgradem mohl být systém verze 4.40 s omezením 80 / 300. Požádal jsem Ing. Hamáčka, aby Vám napsal na Vaši e-mailovou adresu.
Jinak čísla 730/350/6000, která uvádíte, zřejmě nejsou sériové číslo Vaší instalace, ale právě její současná omezení (70 součástek, 350 vývodů, 6000 prvků).
Bohužel taková možnost neexistuje. Příčinou toho je OR-ování barev, které způsobuje, že cokoliv se (v OR-ovaných vrstvách) přikreslí, může obraz jen zesvětlit. OR-ování je nutné proto, aby nezáleželo na pořadí vykreslování objektů, což je zas potřeba kvůli rychlosti automatické aktualizace.
Zkusil jste pohnout s nově doplněným parametrem Graphics | Thresholds | Highlight v testovací verzi? Idea je zadat nějaké nižší procento, aby highlightované pady nebyly tak světlé a aby tedy zbýval nějaký rozdíl jejich intenzity a bílé, do něhož by se čísla pinů vešla. Také byste mohl výchozí barvu padů ztmavit.
Upgrade z verze 4.30 na "alespoň stejně velkou" 4.40 je ve všech případech placený; ceny byste našel v tabulce na stránce www.formica.cz/cenik.html v předposledním sloupci. Upgrade můžete objednat u Ing. Hamáčka na telefonu (+420) 603 540 067 nebo e-mailem na info@formica.cz .
Z Vašeho dotazu bohužel nepoznám, máte-li klíč HASP. (Můžete mi napsat např. sériové číslo své instalace?) V kladném případě si můžete stáhnout také instalační sady verze 4.40 a i bez licenčního certifikátu je užívat s omezením, jaké měl někdejší tzv. Malý systém. (Můžete v nich dokonce nahradit stejnojmenné soubory podstatně pokročilejší testovací verzí z archivu, zmíněného v tomto fóru.)
Pokud jste měl koupený jen Malý systém, připravujeme také prodej dvou menších verzí, a sice s omezením 80 součástek a 300 vývodů, anebo 120 součástek a 500 vývodů.
... Zásobníková metoda je tak trochu typu pokus-omyl, takže mi to ve výsledku nepřijde rychlejší než ruční nastavení hladin...
Ano, ale zas těch omylů nemůžete udělat více než (počet položek) - 2, to jest počet existujících pohledů minus ten současný minus ten hledaný. Dokud uživatel přepíná dejme tomu mezi kombinacemi vrstva A -- vrstva B -- vrstvy A+B, zdá se mi to ještě jakžtakž přehledné.
Je ale pravda, že současné řešení není příliš intuitivní, pokud člověk nemá zrovna slabost pro zásobníkový model počítače. V každém případě ponechám uložené pohledy v nějaké posloupnosti (např. pod čísly 0 až 9), aby mezi nimi šlo přecházet pomocí kolečka -- to se mi celkem osvědčilo. Ale zároveň půjdou (jednoho dne) tou číslicí vybírat. Spíše než pojmenování bych tam možná u každé položky vykreslil cosi jako čarové spektrum indikující, které vrstvy jsou zapnuté. (Pohledy se samozřejmě mohou lišit i jen v ostatních parametrech, ale odlišnost ve viditelnosti vrstev asi je zdaleka nejčastější případ.)
Zatím stále váhám nad tím, jakým způsobem dovolit ukládat; zda jen insertem, anebo i přepsáním existujícího pohledu. Musí tam být i delete, ostatně už proto, že v menu by měly být jen skutečně uložené pohledy (ne tedy pro ně připravená čísla). Hlavně mi zatím není koncepčně jasné, jaký vztah by měl mít aktuální pohled k těm uloženým. Pro ovládání skrz menu raději žádný, naopak pro ovládání kolečkem je potřeba, aby se mezi ně zapojil. Ale na jaké místo?
Formica není psaná v C / C++, jak tomu asi u návrhových systémů bývá nejčastěji, nýbrž v Object Pascalu. Z toho důvodu je použitelných překladačů (tím spíše v oblasti open source) řádově méně.
Teoreticky by snad zdrojový text Formiky měl umět překládat Free Pascal, ale zatím jsem se s ním o překlad nepokusil.
Myslím si, že všechny ruční výběry, tj. přes menu Edit | Window, Pick and Move, Delete, atd ... a Select | Mark Element, by měly brát v potaz zapnutí/vypnutí vrstvy.
Většinou (zvýraznil PH) chci ručně pracovat s tím, co vidím. Tím by se usnadnilo přesouvání bloků apod. v rámci jedné navrhované strany desky.
Samozřejmě, že součástka se přesouvá celá, pokud má něco na viditelné vrstvě.
Což o to, ve všech případech kromě prvního je tohle myslím splněno, jelikož s jednotlivými objekty nelze pracovat, nejsou-li viditelné a tudíž ani detekované (viz též můj předpředchozí příspěvek). Jedná se tedy pouze o režimy vyvolávané z menu Edit | Window.
Sám jsem si už také párkrát rozbil obrys desky v nepájivé masce (kterou mám obvykle zhasnutou) blokovými operacemi s okénkem blízko okraje. Jak byste se ale vyrovnal s posouváním celé desky? V jistém smyslu je možnost zhasínat vrstvy do programu zabudována proto, aby na ně uživatel mohl zapomenout. Pak je ale sporné, zda má program právo po něm žádat, aby si před určitými operacemi zase vzpomněl.
Mezitím jsem se díval do zdrojového textu -- vyloučit samostatné zhasnuté prvky z operací s blokem by byla změna v rozsahu asi 10 řádků. V tom potíž není. Skutečný problém je v tom, vymyslet chování, které je konsistentní a jednoduché, a proto předvídatelné. Jinak se vždy najdou uživatelé, kteří se budou znovu a znovu divit, co jim zas Formica provedla.
Dovolím si také upozornit, že všechny režimy vyvolané v menu Edit | Window se dají omezit na vrstvu ukazatele (pomocí klávesy Ctrl).
Petr Horský napsal:Bod 1b je zajímavý a technicky proveditelný návrh, problém je jen v tom, že u ostatních množinových operací mohou označené segmenty ležet i mimo zobrazovaný výřez.
Ted nevim, co tim mate na mysli...
Jednoduše řečeno, psal jste také o skupině a poukazoval na to, že může zahrnovat i prvky na zhasnutých vrstvách. Proto jste v bodu 1b navrhoval, aby byly na dobu operace zobrazeny. Jenže prvky skupiny (zvýrazněné třeba jako zapomenutý zbytek nějaké předchozí operace) mohou být také jinde na desce, za okrajem zobrazovaného okna. Tam by tedy toto nepomohlo.
Další problém je, že dočasné zobrazení skrytých prvků se moc nehodí pro příkaz Edit | Group | Erase -- tam prostě neexistuje vhodný okamžik, kdy je ukázat.
jde o "Select Element" v menu: <s> <e>
Jenže příkazem Select | Mark Element (který vyvolá režim Mark (Identify)) lze označit jen objekt, který je detekován ve druhé řádce okna. Aby však objekt mohl být detekován, musí být právě viditelný (snad s teoretickou výjimkou součástky, jejíž veškeré prvky jsou na zhasnutých vrstvách, a možná ještě něčeho).
Neviditelné objekty v tomto režimu detekovány nejsou -- vyzkoušejte si to. (Mimochodem, ručně je však můžete označit např. v režimu Mark Window (2nd).)
Proto se mi zdá, že by zde mohlo jít o nedorozumění.
1) Jaky ma vyznam, ze mohu menit vlastnosti car a padu komponent, aniz bych se prepnul do editace komponenty...
Je tomu tak proto, aby bylo možné globálně (zpravidla množinovými operacemi) měnit celou desku, např. zaměnit jeden typ pájecího bodu za jiný, všechna označení součástek přenést do vrstvy vnitřních obrysů, nastavit velikost znaků a typ čáry pro jména součástek, apod. Takové chování asi nejlépe odpovídá celkové koncepci systému. Naopak kdybych editace tohoto druhu zakázal, vnášel bych tím nekonsistenci -- do součástek by totiž i přesto bylo možno fyzicky zasáhnout skrz změny hodnot v tabulce rozměrů.
... a to dokonce i v pripade ze mam komponentu uzamcenou (chapu ze zamek se tyka pozice, ale proc ne i jakekoliv zmeny komponenty)?
Vlajka Fixed skutečně fixuje jen polohu součástky. V systému je již po několik verzí připravena i vlajka Locked, která by vyloučila také ostatní editační zásahy, ale z různých důvodů (včetně výše zmíněné nekonsistence) jsem ji nikdy nepoužil.
2) Pokud mam komponentu prilis u kraje desky a zacnu ji editovat tak, ze po prikazu Replace se jeji pozice LEFT nebo TOP dostane na minusove hodnoty, tak se proces stornuje a muzu editovat znovu.
Proc neni napriklad nejake upozorneni ze objekt zasahuje mimo pole editoru a proto bude napriklad odsazen o x,y milimetru?
Když jsem program psal, zdál se mi již případ, že se součástka editací výrazněji zvětší, dost netypický. Tím spíše pak případ, kdy přírůstek rozměrů součástky překročí šířku okraje desky. Zároveň jsem si říkal, že v editaci součástky nemůže být tolik neuložené práce jako v editaci desky. Proto jsem situaci, kdy součástku nelze umístit zpět, ošetřil v zásadě jako fatální chybu.
Mohu se podívat, co by se s tím dalo dělat, ale asi až v nějaké příští verzi.
3) S tim souvisi i vec, ze kazda komponenta ma udaj o pozici vztazen k jednomu jejimu elementu (tzv.klicovemu). Pokud tento element odstranim a komponentu ulozim ("Replace This"), souradnice zustavaji, ovsem jiz plati pro jiny element, ktery ale v ramci komponenty lezi jinde. Komponenta jiz tedy neni po provedeni "Replace This" na svem miste.
Reseni: pokud se odstrani klicovy element, staci ke stavajicim souradnicim polohy cele komponenty pripocitat rozdil relativnich vzdalenosti mezi starym a novym klicovym elementem. Pak se po navratu z editace soucastky tato soucastka na desce nehne.
Má-li součástka nějaké vývody, je tím "klíčovým" prvkem vývod nejnižšího čísla. Pokud jste v rámci veškerých editací součástky tento vývod odstranil, užije se opět aktuální vývod nejnižšího čísla. Jenomže se součástkou se mohly stát i daleko složitější změny, a program nemůže uhodnout, co vlastně uživatel považuje za vztažný bod. Vývod (typicky) číslo 1 jsem užil, jelikož mi jeho odstranění připadá jako málo častý editační zásah. (Běžnější situace asi bude, že jej člověk posune, čímž se mu -- proti jeho přání -- na desce změní poloha středu součástky.)
Než zavádět jinou logiku, která by přinesla potíže zase v jiné situaci, by bylo lepší zavést explicitní vztažný bod součástky (např. v počátku relativních souřadnic editoru součástky). Do některé příští verze s tím již dlouho počítám.
Tady asi je trošku nedorozumění. Segment spojové čáry má (abych tak řekl) napřed logický typ a vrstvu, a teprve pak šířku. Šířka je udána v tabulce, přístupné skrz menu Dimensions | Line Widths a indexované právě tím typem a vrstvou.
Jinými slovy, šířka kreslené čáry se může změnit přechodem na jinou vrstvu. (Takhle je to udělané z toho důvodu, že pro vnitřní vodivé vrstvy se občas užívala jiná návrhová pravidla, zahrnující i širší spojové čáry.)
Dotazu asi dost dobře nerozumím. Šířky spojových čar jednotlivých typů lze pro příslušné vrstvy změnit v menu Dimensions | Line Widths (pokud defaultní nastavení nevyhovuje).
Jestliže byly desky převedeny z verze 4.30, na vrstvách, které 4.30 neměla, mají v tabulce rozměrů všechny typy čar nulovou šířku. Tabulka rozměrů se Vám na desku mohla dostat také z knihovny, původně vytvořené ve verzi 4.30. Nejde nakonec o tento případ?
Vnejsi oblouk: kdyz mam vest spoj podel montazniho otvoru, tak nestaci, abych vedl spoj na izolacni vzdalenost od otvoru, ale musim vest mnohem dal od nej, protoze na desku bude tlacit jeste hlavicka sroubu. Takze si nulovou carou kolem padu v medi nakreslim kruh.
Včera jsem odpovídal v rychlosti, takže jsem nezmínil jednu podstatnou vlastnost, kterou jste mi teď připomenul. Jde totiž o to, že objekty, od nichž se izolační vzdálenost počítá, jsou vždy aproximovány (opsaným) osmiúhelníkem. Jedna věc je, jak pevně je tato vlastnost zabudována do algoritmů; to teď neumím posoudit, ale je to jistě řešitelné. Druhou potíž však hezky ilustruje Vámi uvedený příklad:
Předpokládejme, že co nejblíže kolem kružnice chcete vést svislý segment. Jenže smyslem zastavování na isolační vzdálenosti je podpořit práci bez gridu, a proto musíme ještě předpokládat, že i střed kružnice leží mimo rastr. Abyste se dostal do správné vzdálenosti od kružnice, musel by se ukazatel zastavit "ve výši rovníku". To ale není možné, protože jeho svislá souřadnice není v rastru -- program by sice správně nastavil vodorovnou polohu ukazatele na izolační vzdálenost, jenže jakmile by se segment přiblížil ke svislé souřadnici "rovníku", izolační vzdálenost by byla porušena. (Podobně u diagonálních segmentů.)
Z toho důvodu by nestačilo kruhové oblouky zahrnout do výpočtů stejným způsobem jako výše uvedené objekty, které zastavování na izolační vzdálenosti nyní respektuje. Muselo by se hledat nějaké speciální řešení; myslím si však, že pak už by optimální kompromis mezi funkčností a pracností ležel o hodně dále, možná poblíž kontroly izolačních vzdáleností pro celý umísovaný segment.
1) Kopirovani, presuvani, tazeni skupiny nebo okna je fakt problem, kdyz mam skryte vrstvy a ty se prenaseji take. Resenim by bylo:
a) skryte segmenty nezvedat, nebo se dotazat na jejich zahrnuti
b) po zvednuti vsech segmentu se skryte segmenty zobrazi spolu s ostatnimi vybranymi (pripadne se pro jednoduchost muze behem zvednuti zobrazovat cela vrstva). Tak mam alespon kontrolu, ze se vybralo i neco co nechci.
O téhle věci se před časem již diskutovalo -- hlavně v souvislosti s množinovými operacemi --, ale nedošlo se k jasnému závěru, co přesně by bylo žádoucí. Navrhoval jsem (vypínatelný) dotaz, příliš podpory však nezískal. Jen tak vynechat skryté segmenty mi na druhé straně připadá nepřijatelné: představte si, že chcete posunout celou desku, máte zhasnutou nepájivou masku a odmaskovanou měď třeba pod krystalem.
Bod 1b je zajímavý a technicky proveditelný návrh, problém je jen v tom, že u ostatních množinových operací mohou označené segmenty ležet i mimo zobrazovaný výřez.
2) Pokud oznacuji segmenty napriklad rucne, nemel bych mit moznost oznacit skryte segmenty, protoze pak je vyberu ani si toho nemusim vsimnout a maler je na svete.
Který z možných způsobů označování zde máte na mysli?
Ac se to zda nesystemove, bylo by dobre automaticky zrcadlit text, ktery se poklada na spodni stranu desky do medi. Problem nastava v pripade, kdy nastavim lichy pocet vodivych vrstev. Pak prostredni vrstva muze byt sporna.
Při zrcadlení se Formica o nastavení vodivých vrstev nezajímá (takže k vrstvě n je zrcadlová vždy 23 - n).
Ovsem vzhledem k tomu, ze nikdo nebude do prostredni vrstvy vkladat text, ktery pak stejne neni videt, a take nikdo nebude psat na spodni stranu medi zrcadlove, je vice nez jasne ze mirror textu je dobra pomoc. Jsme jen lidi a nekolikrat se nam i pres nekolikanasobne kontroly stalo, ze deska vylezla se zrcadlenym textem. Pro funkci zarizeni je to nepodstatne, vsichni se soustredi na kontrolovani podstatnejsich veci, ovsem pred zakaznikem je to pak trochu trapne :o)
Asi bych to nechtěl dělat zcela napevno. Snad by se dalo uvažovat o tom, že se zrcadlení bude při změně vrstvy nastavovat nějak jinak než dosud nebo že přepínač Place | Text | Mirroring bude navíc mít hodnotu Auto, která by způsobila, že výchozí zrcadlení by záviselo jen na čísle vrstvy.
... Dalo by se to prinejhorsim zjednodusit tak, ze skupinu chytnu za segment nejblizsi k objektu, ke kteremu se chci priblizovat a hlidala by se JEN vzdalenost mezi nevybranymi objekty a segmentem, za ktery skupinu drzim. Tim je ovsem znemoznena indikace vzdalenosti pri pouziti Edit/Window/Move, kdy nelze skupinu vzit za objekt...
Ze systémového pohledu se režim Move Window liší od Move Group mj. v tom, že jednak naláme segmenty na hranici okna, jednak dovolí uchopit skupinu za libovolný bod. Je právě toto lámání segmentů důvod, proč neužijete Move Group? V takovém případě by se do budoucna dalo uvažovat o nějakém přechodu mezi oběma režimy -- např. při umísování druhého rohu okna by nějaká speciální klávesa (můj oblíbený Ctrl-Enter je zde již bohužel obsazen) mohla způsobit přechod do režimu Move Group (Pick).
1) Na kruznice se z neznameho duvodu nevztahuje indikace vzdalenosti pri kresleni, ale kontrola pomoci "Check Violations" to zvyrazni.
Zastavení na izolační vzdálenosti bylo vytvořeno jako jednoduchá pomůcka -- ostatně ne právě běžná v návrhových systémech kategorie Formiky --, která Vám má usnadnit práci při běžné editaci. Z toho důvodu se snaží ošetřit především typické situace, ale má různá omezení, která si zde pro pořádek dovolím připomenout:
1) Stará se pouze o polohu ukazatele, ne o vodič, který do této polohy vede. Ten cestou snadno může být ve zkratu téměř s čímkoliv.
2) Podporuje jen objekty určitých typů, jmenovitě čáry pod úhlem v násobcích 45°, pájecí body a nápisy. Kruhové oblouky a čáry pod obecným úhlem ignoruje.
Omezení 1 přitom je zásadní (abych jej překonal, musel bych to naprogramovat dost jinak, dokonce natolik, že pak už by se vyplatilo zabudovat ještě další podstatnou funkčnost), omezení 2 by se dalo řešit ošetřením příslušných typů ve stávajícím kódu, jen jsem se tím nezabýval -- u oblouků především proto, že (vzdor tomu, co říká bod 1) smyslem zastavení na izolační vzdálenosti není dostat se na ni v jednom bodě, ale právě v izolační vzdálenosti vést celý segment nebo delší část vodiče.
Systémy vyšších kategorií ovšem v tomto ohledu umějí kvalitativně více (např. odtlačovat před sebou objekty). To ale nejsou nijak jednoduché funkce. Když jsem hledal způsob, jak vyhovět přáním uživatelů, vyšlo mi omezení z bodu 1 jako dobrý kompromis mezi složitostí programu a užitnou hodnotou.
1) stale je ve funkci Save ztraceno nejstarsi nastaveni? Nebylo by dobre na to alespon upozornit, ze zasobnik je plny a ze se nejstarsi ulozeni ztrati?
Ano, je to myšlené v zásadě tak, že co je na dně zásobníku, je tak staré, že už to není zajímavé, nebo si přinejmenším už dávno nepamatujete, co tam máte. Takový předpoklad lze sám o sobě vždy snadno splnit prodloužením jeho délky. Bohužel je však zcela v konfliktu s tím rotováním obsahu, kterým se tam může dostat i druhá nejnovější položka.
2) Nevim, asi jsem neco nepochopil, ale nemelo by se Restore jmenovat spise Delete nebo Remove apod.?
Odhlédneme-li od rotací, pak Restore / Pop skutečně obnoví posledně uložený stav, ovšem za tu cenu, že nenávratně zlikviduje současný. Nenapadá mne slovo, které by vyjadřovalo obě funkce; snad Drop, které v zásobníkových výpočetních modelech dělá cosi relativně podobného.
2+3) co je mysleno vrcholem zasobniku? Zacatek, konec, aktualne zvoleny index nebo neco jineho?
Naposled uložená položka.
3) Mam to chapat tak, ze dojde k presunuti aktualne zobrazeneho nastaveni v zasobniku na zacatek zasobniku a vsechny ostatni polozky se posunou o jednu pozici indexu vyse? (tak se to ted podle vseho i chova) Potom by se to melo jmenovat nejak vystizneji ne? "Set as First", "Move to Top" apod.
Spíše je to tak, že zásobník je opravdu zásobník, dokud neuplatníte operace rotace (či swap). Samozřejmě se zavedením ovládání skrz Ctrl-kolečko se chápání dat jako zásobníku dostává do pozadí, což je další problém.
4) kdyz si ulozim nekolik nastaveni a pak mezi nimi roluju, zobrazi se mi posledni ulozene dvakrat za sebou (i po znovuzpusteni programu) - evidentne jde o to, ze jedno je ulozene zobrazeni a druhe je neulozene.
Ano, tady je zjevná koncepční chyba současné pokusné verze. Sice Vám nedovolí si uložit dvakrát to samé, ale když stav uložíte a nezměníte, stejně na zásobníku dva totožné stavy budou. Možná by stačilo zásobník pročistit (viz výše ve vláknu) před každým zarotováním, možná to chce ještě promyslet.
5) kdyz si zobrazim nektere ulozene nastaveni a zapnu nejakou vrstvu, rovnou se to uklada do nastaveni v zasobniku. Toto bych uvital spise jako dalsi funkci "Update" apod., protoze si nastaveni muzu nechtene rozhazet (staci abych zapnul/vypnul nekolik vrstev a pak se rovnou prepnul na jine zobrazeni). pokud bude ulozeni zmen na pozadani, neni pak potreba zobrazovat neulozene nastaveni (viz.bod 4).
Proto jsem o odstavec výše napsal zásobník italikou. Opět, koncepčně není dost jasné, kdy se aktuální nastavení považuje za vrchol zásobníku a kdy ne. Technicky jím není; ale jakmile se začne zásobník rotovat, připadalo mi lepší jej tam přidat, abyste se po určitém počtu rotací znovu dostal do výchozího stavu.
7) zacinam postradat i indikaci indexu prave zobrazeneho nastaveni (mj.ted nejsem i schopen rozlisit, jestli to ci ono zobrazeni je ulozene v zasobniku nebo se jedna o to popisovane v bodu 4)
Něco tam připsat by asi nebyl takový problém (ačkoliv je otázka, zda by z toho čísla něco vyplývalo ještě poté, co by se zásobník automaticky pročistil). Dosavadní řešení je v zásadě založeno na předpokladu, že nepotřebujete vědět, co máte v uloženo zásobníku, protože si jej kdykoliv můžete celý snadno prohlédnout. Je otázka, zda by se po odstranění dosavadních nekonsistencí tento předpoklad potvrdil.
Uvítal bych názory také dalších uživatelů na současné pokusné řešení.
Odkaz mi nějak nefunguje.
Ve verzi P97 ani P98 (zatím) nevím o žádných chybách v generování výstupů; ostatně ani změny tam mezi nimi nebyly velké. Proto bych se úplného přechodu na poslední verzi celkem neobával.
Desku, která dělala problémy, mi také můžete pro zajímavost poslat.
Děkuji za změření. Beru to tedy tak, že zatím asi není důvod kreslení čar zrychlovat. Jednou na ně stejně dojde.
... Ve schematu s tim problem neni...
Když už jsme se do rychlosti vykreslování pustili v takovém rozsahu, že se z problému stalo zde zatím nejdelší vlákno, měl bych s dovolením ještě dotaz:
Někde ve firemním archivu byste jistě našel např. QUIDO USB 60-3.sch . Když si zde vykreslím jeho první list (ten s procesorem) ve zvětšení 25%, zdá se mi, že segmentů dohromady tvořících veškerá písmena nápisů tam je přinejmenším srovnatelně s počtem bodů gridu (o rozteči 40 jednotek). Jakých časů dosáhnete při vykreslování, pokud grid vypnete?
Ptám se proto, že kreslením nápisů užívajícím řádově menší počet volání API jsem se (jak to teď vypadá, možná jaksi v předstihu) zabýval v rámci pokusů s verzí 5.x, ale tehdy se ještě neobjevovaly zásadní problémy s rychlostí.
Ještě bych se vrátil zpět k tomuto:
... Dříve jsem to řešil Select All + Move Group + 6x Tab , ale s možností zamykání komponentů, tato varianta vzala za své...
Asi není obtížné odemknout všechny součástky nějakým makrem, přičemž byste pracoval s nějakou pomocnou kopií souboru.
Na druhé straně mohu tenhle námět využít i jako příklad na nově doplněné Tools | User Flags, do nichž lze příznak uzamčení (prostřednictvím highlightování zafixovaných součástek) odklidit a odkud lze zafixování (opět skrz highlightování) opět obnovit; makra by to byla velmi jednoduchá. Nesmíte jen zapomenout, že User Flags se (zatím) neukládají do PCB souborů.
Diskusní fórum k návrhovému systému Formica » Příspěvky od Petr Horský