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ý
(...) a přes jejich stránky si data prohlédnout.
Tam ale narážím na problém, že jejich náhled bohužel neumím správně vyzoomovat. Vypadá to, že matrice jednorázově vygenerují do poměrně hrubé bitmapy, a pak jen zoomují tu, spíše než by pro požadované zvětšení (a výřez) generovali novou.
Děkuji za zprávu. (Jakási předzvěst toho se objevila možná již v době, kdy se novější verze GC Prevue odmítaly spustit jakožto zastaralé.) Verze 25.3.6 mi zatím běží, jen vypisuje Support Plan Expiration: 18-oct-2017.
Rád bych zde také upozornil na Reference Gerber Viewer společnosti Ucamco, která dnes je správcem formátu Gerber, resp. RS-274X. Prohlížeč pracuje on-line na adrese https://gerber.ucamco.com/ . Jednou z jeho výhod je, že (díky svému původu) zobrazuje kruhové oblouky správně, což pro všechny on-line prohlížeče bohužel neplatí; nevýhodou naopak nemožnost vykreslit vrtací program, tj. data pro Excellon. (Vypadá to, že ignoruje "METRIC" v hlavičce vrtacích souborů.)
S kreslením meandrů trochu souvisejí i plošné cívky. Tam je interaktivity ještě daleko méně, účelem je jen ušetřit práci, kterou by představovalo ruční kreslení kvadrant po kvadrantu. Doplněním dvou parametrů (určujících délku vkládaných vodorovných a svislých segmentů) lze také získat vinutí pro transformátory s jádrem, jejichž sloupek má obdélníkový průřez.
Ovládání je (snad) zřejmé z následujících obrázků. Uvítám případné připomínky.
Do pokusné verze teď postupně přidávám kreslení meandrů, jak je vidět z obrázku. Meandry půjde kreslit vodorovně a svisle (jiné směry by šly obtížněji kvůli kvadrantovým obloukům); jejich parametry jsou v zásadě dány jen zadaným poloměrem oblouku a polohou cursoru vůči výchozímu bodu. Během kreslení je průběžně zobrazována celková délka meandru a (v závorce) prodloužení oproti přímému spoji.
Než budu pokračovat, rád bych nejprve shromáždil požadavky uživatelů. Ty jsou zatím dva:
1) Meandr volitelně kreslit i pro diferenciální pár.
2) Meandry by mohly také být symetrické, tj. vlnící se od osy spoje na obě strany o stejnou amplitudu.
Další otázkou bude ovládání. To by mohlo být řešeno třeba takhle:
Tab přepíná vrstvy, podobně jako při kreslení kružnic;
Shift překlápí mezi vodorovnými a svislými meandry, přičemž výchozí směr je určen směrem segmentu, na němž meandr začíná (existuje-li a je-li vodorovný nebo svislý);
Ctrl překlápí mezi jednostranným a symetrickým meandrem.
Cílem však zůstává ušetřit návrháři většinu práce s kreslením a počítáním meandrů, ne je plně integrovat do kreslení a editace spojů. (Meandr tak mj. není novou primitivou, a jakmile je umístěn, již se ničím neliší od meandru nakresleného po jednotlivých segmentech a kvadrantech ručně.)
Možné řešení by asi záviselo na tom, co (všechno) byste od PNG souborů očekával a k jakým účelům je chtěl užívat. Relativně přímočaré implementace bych přitom viděl zhruba tyto tři:
1) Výstup podobný jako pro systémovou tiskárnu, jen by se navíc zadalo rozlišení souboru (a jeho jméno).
2) Výstupní generátor podobný tomu pro formát TIFF. (Komplikace je v tom, že bitmapový generátor od aplikace nedostává standardní windowsovskou bitmapu, nýbrž jakýsi náš vlastní formát — vývoj Formiky totiž začal v době, kdy ještě neexistovaly Windows 3.1.)
3) Jakýsi ad hoc výstup, který vygeneruje bitmapu stejným způsobem jako pro obrazovku, jen její rozměry vypočte např. z aktuálního zoomu a skutečných rozměrů desky, a zapíše ji jako PNG soubor. Zde je malá ukázka, jen bez těch výpočtů:
(Do testovací verze jsem si před chvilkou pokusně připsal pár řádek, které bitmapu vygenerovanou příkazem Zoom / Zoom All zároveň uloží do souboru.) Zde by se také dalo s výhodou užít (relativně) nových příkazů Graphics / Save View & Zoom a Restore Zoom, jimiž by se nastavení vhodné pro PNG soubory dalo ukládat do konfigurace progamu.
Ano, tohle je základ rozumného řešení. (Tím spíše, když správné rozměry už jsou načtené v programu spolu s příslušnou knihovnou.) Ve skutečnosti však lze čekat, že konflikty nastanou poměrně rychle, a pak by bylo potřeba přesunout pad z knihovny do logického typu nového čísla. (Ta by mohla běžet např. od konce tabulky dolů.)
Vedle té řady testovaných programů 4.41... tady udržuji ještě další, 4.42..., a ta by měla brzy umět i toto. Potřebuje k tomu však také nový formát souborů, v nichž jsou pady jednotlivých čísel typů už navzájem nezávislé, tedy nikoliv svázané skrz Opposite Type.
Aha, nenapadlo mne, že Ctrl-+ a Ctrl-??? by mohly být nevhodné už z čistě ergonomických důvodů. Nebylo by pak nejjednodušším řešením jejich funkci přidat ještě jinam, např. na Ctrl-kolečko?
To sice v některých programech zoomuje (zatímco kolečko posouvá výřez svisle a Shift-kolečko vodorovně, viz též http://formica.cz/forum/viewtopic.php?pid=1531#p1531), ale momentálně je neobsazené. (Ovšem podívám-li se do zdrojového textu, má tam vykomentovanou funkci přepínání mezi pohledy na desku uloženými v předchůdci Graphics / Restore View; k tomu se však pravděpodobně již nevrátím.)
Dimovanými vrstvami bych to asi nekomplikoval, problém by dělaly hlavně v případech, kdy jsou mezi vodivými; jenže mám dojem, že tehdy by zas stačilo přepínání vrstev pomocí Tab. (Protipříkladem k tomu je situace, kdy pracujete na dejme tomu osmivrstvé desce, polovina vrstev, třeba těch s rozlitou zemí, je dimovaná, a Vy chcete co nejrychleji přecházet mezi těmi zbývajícími; ale ta mi připadá trošku teoretická.)
??? ??? ???
Jinak ale (což by mohlo být tématem pro samostatné vlákno) těch funkcí na klávesách vůčihledně přibývá, představy se různí, styly práce jednotlivých uživatelů nejspíš také. Východiskem by též bylo přidání tabulky, v níž by si je každý mohl namapovat dle svých preferencí.
Zde je verze s diskutovanými změnami: http://www.formica.cz/files/Layout-441-p109-1117.zip . Změny týkající se kolečka je možno povolit v menu Options / Menu System & Sound; kvůli symetrii je tam odděleno nastavení pro menu, výčtové parametry a numerické parametry. Chování kolečka lze tedy nastavit i tak, aby přesně odpovídalo dosavadnímu; oproti tomu šipky teď vždy běží ???kolem dokola???.
Ony v tom jsou nejméně tři problémy:
1) Ctrl-Tab už má svoji funkci, přepíná mezi zrcadlově sdruženými vrstvami, tj. např. z vrstvy 2 na 21 a zpět. (Tab přesně vzato přepíná na vrstvu A, pokud již není aktivní, jinak na vrstvu B.)
2) Je-li vrstev více než dvě, asi by se hodilo přepínání v obou směrech; kdyby tedy šlo užít např. Ctrl-Tab, pak by asi měl Shift-Ctrl-Tab postupovat opačným směrem.
3) Je také otázka, jak to zkombinovat s Graphics / Autodimming = All but Active Layer.
Navíc, má-li se to omezit jen na vodivé vrstvy, ty zpravidla bývají u sebe. Z praktického hlediska tedy téměř stejnou funkci, jako je požadována, již mají klávesy Ctrl-+ a Ctrl-???, které postupují po jednotlivých vrstvách, přičemž přeskakují ty vypnuté. (Prosím vyzkoušejte si.)
Tedy, z příspěvku mi není zcela jasné, oč Vám jde primárně: zda o to, aby chování bylo symetrické pro změnu hodnoty parametru přímo na řádce i v jeho podmenu, anebo o to, aby hodnoty šlo ve všech případech měnit ???kolem dokola???. V každém případě kód pro změnu hodnot momentálně vypadá takto:
K_CtrlWheelUp,
K_CtrlUArr: if CurrentItemPtr^.Accessible then
CurrentItemPtr^.DecVal
else
BadKeyBell;
K_CtrlWheelDn,
K_CtrlDArr: if CurrentItemPtr^.Accessible then
CurrentItemPtr^.IncVal
else
BadKeyBell;
K_CtrlPgUp: if CurrentItemPtr^.Accessible then
CurrentItemPtr^.SetMinVal
else
BadKeyBell;
K_CtrlPgDn: if CurrentItemPtr^.Accessible then
CurrentItemPtr^.SetMaxVal
else
BadKeyBell;Ctrl-šipky tedy mají zcela stejnou funkci jako Ctrl-kolečko.
Matně si vzpomínám, že kdysi byla funkce šipek a kolečka oddělena; vycházelo se z toho, že když uživatel vidí, že je např. na poslední položce v menu, a stiskne šipku dolů, zřejmě ví, co chce, tj. dostat se na první položku ??? zatímco kolečkem myši prostě některým směrem zatočí (často i o několik položek, aniž by je počítal) a dívá se, co to udělá. Kdyby pro kolečko myši neexistovala ???zarážka??? v krajních polohách a uživatel by přeskakoval na opačný konec menu, působilo by to zmatek.
Pak se ukázalo, že zmatek není tak hrozný, a chování kolečka jsem sjednotil se šipkami. Zůstalo ale v kódu pro přímou změnu hodnoty; tam přitom navíc lze krajních hodnot dosáhnout i explicitně, klávesami Ctrl-PgUp a Ctrl-PgDn. Změnit tam chování na ???kolem dokola??? (v metodách IncVal a DecVal) by nijak obtížné nebylo, jen by bylo nutno rozmyslet a ověřit, zda někdo něčím třeba i implicitně nespoléhá na to dosavadní. Koneckonců by pro nové chování mohl také existovat přepínač.
Omlouvám se, že reaguji až s takovýmto zpožděním. Protože se tady smíchalo hned několik nedorozumění dohromady, bylo ale asi nevyhnutelné si napřed vyrobit obrázek. Zkusím napsat věci, které jsou pro diskutovanou látku podstatné, aniž bych se však vracel ke konkrétním místům textu ve vlákně výše (to můžeme pro odstranění zbývajících nejasností případně udělat v dalších příspěvcích).
1) Režim Move Window je zcela nezávislý na označení. To na jednu stranu nijak neovlivňuje, které objekty budou posouvány, na druhou stranu není posuvem nijak změněno (a označené objekty zůstanou označené i po posunutí).
2) Režim Move Window (a od něj odvozený Move Layer) posouvá jen součástky, které leží celé v okénku; přitom se však vůči poloze okénka netestují nápisy obsahující jména (ani hodnoty a pouzdra) součástek. (Tak se to pochopitelně dělá právě z toho důvodu, že tyto nápisy běžně bývají od součástek dost daleko.)
3) V režimu Move Layer (kam se dostanete přidržením Ctrl při umisování druhého rohu okénka) se posouvají jen ty objekty, které (navíc oproti výše uvedenému) mají některý prvek na právě aktivní vrstvě. Proto se na obrázku neposouvá Q18, ač leží (až na název součástky) v okénku celý; kdyby naopak aktivní vrstva byla např. 14, posouvaly by se Q18 a K6.
Bylo by uz dnes, pri dnesnim beznem vykonu pocitacu realne nejak podstatneji zvetsit maximalni rozmer okenka pro vylevani?
Tady teď jsou meze gridu pro router (a tedy také pro rozlévání) zvýšeny na 20000 ?? 20000 uzlů: http://www.formica.cz/files/Layout-441-p109-1115.zip
(...) soucastku (nebo skupinu soucastek) oznacim pomoci Place - Window (pri kliku drzim ctrl) (...)
Tady ještě záleží na tom, která vrstva je právě aktivní (Default Layer) a na kterých všech vrstvách se součástka vyskytuje. Režim Move Window s Ctrl byl vytvořen proto, aby šlo pracovat s SMD součástkami a spojovým obrazcem na jedné straně desky, aniž by druhá strana (a vnitřní vrstvy) byly ovlivněny.
Obecně pro řadu operací (včetně Edit / Group / ...) hraje roli, zda je označena i součástka jako taková. (Může být, aniž by měla označen jediný svůj prvek, a naopak.) Označení samotné součástky sice není ukázáno žádným jejím zvýrazněním, ale je vidět ve stavovém řádku (Flags: H...) nebo v tabulce Information.
Rozumím tomu správně, že předchozí operace v režimu Move Window ovlivnila následující v režimu Drag (Pick), resp. Drag Component? Při zběžném pokusu se mi to nepodařilo nasimulovat.
No, ony ty .hlp helpy ve spojení s verzí 4.41 stejně už jen dožívají, např. zde momentálně nemám prostředí, v němž bych je mohl aktualizovat. Jejich nová verze zřejmě už bude HTMLHelp.
Mezitím snad mohou v některých situacích posloužit i manuály (http://www.formica.cz/manualy.html).
Zpět k těm záměnám textu, jakožto takovým:
Pokusně jsem to dnes naprogramoval, s následujícími omezeními:
1) pracuje to jen na označených nápisech;
2) z nich však jsou všechny názvy součástek ignorovány;
3) lze buď nahradit všechny nápisy (pattern to replace = "*"),
4) anebo doslovně zadaný podřetězec (pattern to replace = cokoliv jiného), je-li nalezen, nahradit jiným.
Jinými slovy, nelze užívat wildcards (vyjma té samostatné hvězdičky). (Díky tomu stačila knihovní funkce StringReplace, a nemusel jsem programovat vlastní.) Bylo třeba ošetřit nějaké chybové stavy; výsledný řetězec totiž nesmí být delší než povolených 72 znaků, ale nesmí být ani prázdný.
Pravděpodobně Vám pošlu odkaz na verzi k vyzkoušení, popřípadě jej pak přidám i sem.
??? ??? ???
Zde je odkaz: http://www.formica.cz/files/Layout-441-p109-1115.zip
Tohle bych asi nebral jako změnu textu, nýbrž jako přečíslování; už před začátkem operace totiž ty součástky musely mít nějaká unikátní jména.
Budu rád, když se případní další zájemci o podobné operace přihlásí v tomto fóru.
Odkaz je zde: www.formica.cz/files/Layout-441-p109-1111.zip
V nastavení driveru je mj.i přepínač pro zahrnutí otvorů zašedlý.
Myslíte přepínač Files / Artwork / Options / Hole in Pads ? Ten byl míněn pro ???vyříznutí??? otvorů do pájecích bodů. V DXF by něco takového šlo obecně těžko, vymyká se to z těch základních primitiv, které v generátoru užívám; představte si třeba obdélník pájecího bodu, z nějž se má vyjmout kruh o průměru větším, než je kratší strana toho obdélníku...
Zkusil jste si prosím generování těch otvorů po připojení DXF.dll skrz menu NC Drill ? Problém byl v tom, že jste tak získal dva DXF soubory místo jednoho společného, anebo v něčem jiném?
Reference bych pro začátek opravdu vynechal zcela.
(...) Vzhledem k tomu, ze se tam na obteceni pouzivaji spoje v obecnych uhlech; (...)
Ty tam právě nejsou, vše je v násobcích 45°. Kdyby se kolem kruhových padů vytvářel dle jejich rostoucího průměru pravidelný osmiúhelník (osmiúhelník tam je už teď, ale ne dost pravidelný), dvanáctiúhelník, šestnáctiúhelník..., vypadalo by to dobře také. Ale při povaze rastrového algoritmu pro rozlévání (majícího výpočet překážek společný s autorouterem) není jednoduché to takto udělat.
Od příštího buildu tedy max. rastr pro rozlévání může být 20000 × 20000 uzlů; to nic nestojí, dokud meze nejsou využity.
Ano, přesně tak. Přitom, kdyby se to mělo naprogramovat opravdu komfortně, musela by se celá záměna provést nejprve „nanečisto“, pak zkontrolovat, zda nevznikly duplicity, a pouze pokud ne, změnit texty doopravdy.
To zatím byly jen jakési předběžné úvahy mezi minimálním a maximálním řešením: První může vnucovat nový text bez ohledu na předchozí, a názvy součástek prostě přeskakovat, protože stejně nemá smysl je takovýmto způsobem měnit. Naopak u druhého existují důvody i pro práci s názvy součástek (např. změna XTAL* na X*), bylo by tedy třeba kontrolovat vznik duplicit, podobně záměna podřetězce (která by mimochodem mohla být i opakovaná, např. ABC za A by z ABRAKA udělalo ABCBRABCKABC) obecně může řetězec prodloužit, takže by se musela hlídat i max. výsledná délka. Minimální řešení by ovšem vycházelo programátorsky o dost jednodušší.
Mimochodem, také byli uživatelé, kteří podobné operace dělávali textovým editorem v .pcb souboru. (To mělo, technicky vzato, určité výhody, např. duplicitní názvy součástek se našly při otvírání souboru, podobně se v té chvíli přepočetla okénka nápisů a případně i okénka součástek je vlastnících...)
Formica 4.40 mívala meze 6000 x 3000 uzlů rastru, ve verzi 4.41 jsem je už zdvojnásobil na 12000 x 6000. Pokud by tedy byl pro rozlévání užit rastr dejme tomu 0,1 mm, dovolovalo by to zalít mědí plochu až 120 × 60 cm.
Na počítači s 8 GB paměti jsem si teď zkoušel tyto meze rozšířit ještě dál, na 20000 × 12000. To by dovolovalo plochu 50 × 30 cm i při rastru 1 mil. Rozlévání se všemi výpočty isolačních vzdáleností pak pochopitelně trvá dost dlouho, ale funkce undo / redo, které loni byly zásadně přepracovány, s rozlitou mědí pracují ještě velmi rychle.
Hlavní otázkou ovšem je, je-li opravdu vhodné užívat nějaký takto jemný rastr. Rozlévání na něj původně stavěno nebylo; pro takovéto požadavky by lépe vyhovovalo definovat polygonální plochu jakožto novou primitivu, což by však byla zásadní změna.
Teď odpovídám, aniž bych to vyzkoušel nebo se podíval do zdrojových textů. Ale myslím, že je to tak, že DXF.dll negeneruje otvory jako 25. vrstvu v souboru (podobně tomu, co dělá generátor PDF), že si jej však můžete také připojit příkazem Files / NC Drill / Load Driver v roli generátoru ???vrtacího programu???. ??daje o otvorech se tak dostanou do samostatného DXF souboru; každý se tam objeví jako CIRCLE.
nehledě na to, že když mám např. 30 LED diod, a ručně přepisuji každý název, mohu udělat chybu.
No, ona by taková chyba (typicky v čísle) asi vedla k duplicitnímu názvu, a tomu by se program bránil.
Chápu, že na to někdo není tak zvyklý, ale přepínač by to určitě vyřešil.
Pokud něco fungovalo dříve, tak přece nemůže být taková práce to ponechat s přepínačem.
Matně si vzpomínám, že jsme o tom již komunikovali, a výsledkem bylo, že původní kód ve zdrojovém textu dosud je, jen je vykomentovaný. Jde tedy pouze o přepínač, přičemž se mi příliš nechce přidávat (nejspíš do menu Options) položky jen ad hoc; lépe by možná bylo, kdyby existoval .ini soubor, do nějž by se běžný uživatel nedíval, ale ten zasvěcený by v něm našel klíč, jehož hodnotu by si změnil. Zkusím se na to příležitostně podívat znovu.
Naopak vytvořit verzi s nějakou změnou na přání je sice možné, ale nemá to praktický význam, protože údržba takovýchto speciálních verzí by se nutně velmi brzy stala nezvladatelná.
Diskusní fórum k návrhovému systému Formica » Příspěvky od Petr Horský