Zřejmě počet zvýrazněných součástek / počet zvýrazněných prvků; viz též tabulka Information.
Blíže na to během několika dnů odpoví Dr. Křivka.
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ý
Zřejmě počet zvýrazněných součástek / počet zvýrazněných prvků; viz též tabulka Information.
Blíže na to během několika dnů odpoví Dr. Křivka.
Prosím podívejte se na verzi k testování, odkazovanou v sousedním vlákně: http://www.formica.cz/forum/viewtopic.php?id=318
K zobrazování řízenému uživatelskými vlajkami jsem dostal velmi zajímavý námět od pana Ocha: Vlajky nemusejí jen určovat barvu zobrazovaných prvků, ale prvky s nastavenou uživatelskou vlajkou by mohly být zobrazeny v barvě vrstvy i tehdy, když ta je dimována nebo vypnuta. Současná testovací verze má tuto funkci řízenu uživatelem zadávanou maskou určující, které uživatelské vlajky budou fungovat popsaným způsobem. Jako její přirozené rozšíření by se nabízelo mít tam takovéhle masky dvě, z nichž jedna by umožňovala ???překonat??? jen dimování vrstvy a druhá (odpovídající funkci té masky, která je tam teď) také její vypnutí.
Protože si jsem vědom, že z tohoto popisu nemusí být vůbec zřejmé chování ani jeho možné využití, raději opět připojuji nějaké screenshoty. Případným zájemcům mohu poslat odkaz na pokusnou verzi (někteří jej ode mne již dostali).
Zde je opět deska Triton, podobně jako na prvním obrázku prvního příspěvku vlákna. Zvýraznění dvou silových vodičů však bylo přesunuto do uživatelských vlajek A a B (na tenhle screenshot by stačilo do jedné z nich), a pro ně maska povoluje barvy vrstev, které však byly jinde dimovány (na rozdíl od citovaného obrázku s výjimkou vrstvy 21, takže názvy součástek dovolují základní orientaci na desce.) Výsledkem je zřetelné odlišení dvou vodičů, u nichž zároveň zůstává dobře patrné, na kterých jsou vrstvách.
Pomocí uživatelské vlajky C jsou tady selektivně dimovány čáry typu 20, užité k rozlévání mědi na obou vnějších vodivých vrstvách. Výsledné zobrazení dobře ukazuje strukturu měděných ploch (viz též http://www.formica.cz/clanky/copper_tips.pdf).
Podobně pro jinou (čtyřvrstvou) desku: vybrané napájecí spoje...
... a dimování rozlévané mědi na všech čtyřech vrstvách.
Snad by stál za zmínku také on-line prohlížeč http://www.gerber-viewer.com/ s některými zajímavými možnostmi zobrazování; pár ukázek připojuji dole. (Vedle formátu Gerber umí též Excellon.) Pozoruhodná je i možnost vygenerovat (a uložit si) obrázek se zadaným rozlišením (zde byl užit desetinásobek nabízeného):
http://www.formica.cz/files/forum/gerber-viewer-6.png
http://www.formica.cz/files/forum/gerber-viewer-7.png
(K pokusům jsem užil desku Triton z Galerie desek; soubory uploadované (již jako zip) na server prohlížeče jsou zde: http://www.formica.cz/files/forum/Triton-gerber.zip .)
(...) 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.
Diskusní fórum k návrhovému systému Formica » Příspěvky od Petr Horský