Nejste přihlášen. Přihlaste se, nebo se zaregistrujte.
Diskusní fórum k návrhovému systému Formica » Příspěvky od Tomáš Och
Dobry den,
jakym zpusobem mohu prenastavit obecně vychozi Dimensions (konkretne potrebuji napriklad pady, ale tyka se to celkove vsech rozmeru) v pripade, kdy zacinam uplne novou desku, tedy nevychazim z zadne predchozi? Dosud se to u nas delalo zpusobem Files | Read File Sections | <nastavit On pouze u Dimensions> Read File a nacetla se knihovna lib.pcb, kde jsou referencni rozmery. Ale delat to timto stylem mi prijde velice pochybne a zvlastni...
Existuje tedy nejaky zpusob?
Jestli se nemylim a problem chapu dobre, tak muzete mit implementovany oba zpusoby, a podle nadetekovane verze Windows se rozhodnout, kterou variantu pro komunikaci zvolite...
Dekuji, bod 1 je presne to co potrebuji.
Tak ani druhe zarizeni neuspelo. Tentokrat byla hlaska o tom, ze neni odezva od klice, ale co se tyce funkcnosti ruznych verzi layoutu, bylo to stejne.
Pro zajimavost uvedu oba prevodniky: Prvni byl MP-CS180 firmy MP Craft, druhy a o rad drazsi byl SPP-100 G firmy Quatech.
Pokud byste se tim chtel zabyvat, myslim ze by po novem roce nebyl problem oba tyto prevodniky ve firme zapujcit.
Pokud neexistuje (me zatim skryta) moznost aktualizace soucastek z knihovny, nebylo by spatne tuto moznost mit, nejlepe jako prikaz, nebo alespon v okamziku, kdy vkladam soucastku se stejnym nazvem a je mi nabidnut nazev s priponou ".2".
Kdyz tedy chci do schematu vlozit upravenou soucastku tak, aby stavajici verze soucastky ve schematu byla aktualizovana take, tak mi nezbyva, nez si nekam napsat kde lezi jaka stavajici soucastka s jakou hodnotou, vsechny je smazat a pak vlozit znovu tu upravenou. A zas jim vsem rucne priradit spravna referencni cisla, hodnoty a poznamky. Coz je krkolomne..
Tak "...env7" beha, "...env12" hlasi chybu "No answer from NetHASP Licence Manager (15)"
Provozuji to na WinXP Pro SP2.
Do konce tydne chci zkusit jeste jeden prevodnik, az se dostanu do prace a jeste dam vedet. Ten vypada o neco kvalitneji. Jsem zvedav jak to pojede s nim...
Zkusil jsem provozovat plnou verzi programu na notebooku, ktery nema nativni LPT. Vzal jsem tedy PCMCIA kartu s LPT, pripojil HASP klic, a Layout pouze hlasi "Status error (#1, code 15, 0, 0)". Schema funguje bez problemu.
PCMCIA karta je nejaka neznackova, neco od Cinana, to ale vliv mit patrne nebude vzhledem k funkcnimu Schematu....
ps. VSEM PREJI PRIJEMNE SVATKY A USPESNY NOVY ROK!
Nejde mi o zpusob prace pri generovani rozpisky. Jde mi spise o doplneni funkce edit | group operation | change | references (| execute).
Co jsem tak vysledoval, tak v soucasnosti se pri automatickem precislovani referenci soucastek hledi na to, aby byla vyuzita vsechna cisla od jednicky, tedy aby pozdeji v rozpisce soucastek nevzniklo napriklad C1, C2, C7, C8. Mam pocit ze na jine okolnosti ted funkce nehledi.
No a ma myslenka je takova, aby se reference daly preskladat tak, aby shodne hodnoty soucastek (Value) sly za sebou. Ve schematu to vyznam nema, jde o pozdejsi generovani do partlistu.
Priklad:
Pred setridenim referenci:
R4,R6, R8 1k R0805
R5, R7, R9 100R R0805
Po setrideni referenci i dle shodneho obsahu Value:
R4,R5, R6 1k R0805
R7, R8, R9 100R R0805
V rozpisce potom bude vetsi prehled, a clovek, ktery bude desku osazovat, si nemusi pamatovat jednoltiva cisla referenci, ale staci mu pamatovat si ze ma osadit urcity rozsah (napr.R4 az R25). Jde ciste o vetsi pohodli pri osazovani..
Mockrat dekuji, to je presne ono :o)
Mám námět: program by mohl umět třídit i podle hodnot součástek tak, aby např.všechny 10k odpory byly za sebou - lépe se pak ručně osazuje..
Dobry den, delsi dobu pozoruji, ze obcas kdyz chci provest Undo, tak v urcitem okamziku nelze.
Nyni jsem prisel na to, kdy se to deje. Nevim jestli jese u jine prilezitosti, to ukaze opet cas, ale:
1) pomoci jakekoliv jednoduche ci skupinove operace Move nebo Drag provedu posun soucastky, anebo nebo skupiny, kde je alespon jedna soucastka
2) kdekoliv nakreslim spoj (klidne od nikud nikam)
3) provedu 2x Undo: provede se pouze odstraneni spoje, ale posun soucastky/skupiny jiz vratit nelze
kdyz to shrnu, tak to vypada, jakoby kresleni spoje zrusilo veskere predchozi zaznamy v Undo..
verze programu: 670007 (tedy nejnovejsi)
Ano, jedna se o tuto posledni verzi 650007.
1) vychozi stav:
2) zvedl jsem pomoci Drag:
3a) kdyz jsem si s tim hral jeste pred snimanim obrazku, zlobilo to tak, ze spoj byl fialovy cely, ted dosahuju na tomto konkretnim pokusnem schematu zas jen techto vysledku a jeste ne pokazde:
3b) tak jsem vzal jine, vetsi realne schema, a tam se puvodni dej (spoj fialovy cely) projevuje stale:
2c,3c) Deje se to pri zvednuti labelu (nikoliv spoje pod labelem), nebo po zvednuti soucastky - na dalsich obrazcich jsem zvedl a polozil procesor, a vzniklo naopak toto:
na tom schematu, co jsem si nakreslil ze dvou odporu, se to stavalo pouze chvili po te, co jsem ho vytvoril, od te doby at menim, ukladam, zavitram, oteviram, se jiz deje jen to co na obr.3a. Na vetsim schematu se barvi naopak cely spoj, nebo jen jeho usek (3c)..schema mohu zaslat, pokud Vam bude uzitecne..
Dobry den, tak jeste je maly detail:
1) mam nakreslene dva ruzne spoje napojene jednou stranou na nejakou soucastku a na druhe oba opatrene shodnym labelem,
2) jeden label pomoci Drag (nebo i Drag Group) zvednu a vodic pod druhym labelem zfialovi (label ne, pouze ten vodic)
3) nyni zvednutou skupinu polozim, a az do prekresleni okna je vodic dal fialovy
pokud pouziju Move nebo Move group, je vse v poradku.
Schema jsem poslal panu Krivkovi. Problem je v tom, ze vubec nevidim misto, kde doslo k selhani routeru....zadna modra cara...
Dobry den,
mam tu jedno schema, kde pri tisku (kliknutim na go | print) vyskakuje hlaska "Schema contains rubber bands." Predpokladal jsem, ze pri pokladani neco nekde router nestlihl naroutovat (dalsi otazkou je proc ho nenechat doroutovat a pak teprv blok polozit, k cemu je mit nedoroutovany spoj..). Tak jsem router pustil dle napovedy rucne, ale hlaska naskakuje stale. O co se tedy jedna?
Schema kdyztak mohu poslat mailem.
To asi je nedorozumění,(...)
Tak to jsem opravdu spatne pochopil. Dobra, budu si s tim snad hrat. Skoda jen te grafiky..ta funguje uz nyni, tak proc ji tam prozatim nenechat, a az bude jasne ovladani, tak ho jen zmenit?
Totez plati pro automatickou zmenu cesty PNL podle polohy souboru PCB....u te by ale znamenalo pridani prepinace, jestli se na to ma program ohlizet..
(...)Někdy se snad k tomu dostanu (jakmile budu mít jasno, jak ovládat přepínání pohledů).
Proste vsechno to jsou moc hezke funkce, ale uz se moc tesim az je vyuziju vsechny najednou..
To, co ve výsledku ukazuje poslední obrázek, jsem automaticky přidal do testovací verze v archivu na výše uvedené adrese (jen to zatím není ve verzi s omezením 40 / 150). Vedle toho je tam vše, co jste zmínil, kromě ukládání nastavení grafiky. To jsem z programu před časem opět odstranil, jednak kvůli nejasnostem v koncepci ovládání, jednak kvůli tomu, že by to vyžadovalo jiný formát konfiguračního souboru.
Ano, to jsem pochopil, stahnul a vyzkousel. A chtel jsem uz zacit pracovat s novymi funkcemi, ale protoze projekty, ktere delam jsou velke, tak nemam moznost si s tim temer nijak smysluplne v omezenych testovacich verzich hrat. A take je skoda, ze jste ukladani grafiky vypustil. Na tu grafiku jsem si tak zvykl, ze pouzivam jen ji a je to i v tomto stadiu mnohem rychlejsi nez kazdou chvili premyslet a vyklikavat ktere vrstvy vlastne musim schovat. Take pokud mam vylitou med, tak s kazdou zaplou/vyplou vrstvou musim znovu cekat nez se vyliti vykresli. Tolik z meho pohledu.
Zmena konf.souboru by mohla byt, a take by to mohla byt posledni "viditelna" zmena, kdyz se zohledni i pribyvajici polozky. V cem se vlastne skryvaji uskali se zmenou cnf? Napada mne pouze kompatibilita se stavajicimi starsimi verzemi Layoutu..
Poslední změny v testovací verzi mají ovšem sloužit spíše k otestování, nakolik je funkce opravdu vhodná a potřebná (a zda pokrývá vše, co by v dané souvislosti šlo rozumně požadovat), než k testování správnosti programu. Tak např. kvůli rovnání nápisů je teď v programu zhruba třikrát více kódu, než by muselo být, protože zaintegrovat tam nový kód lépe by vyžadovalo zasahovat do stávajících procedur, s nimiž se prodává standardní verze, což by muselo být otestováno lépe než jen tím, že to někomu funguje.
Na druhé straně, protože takovéto doplňky zpravidla nezasahují do stávajícího kódu, může asi pokročilejší uživatel tuto testovací verzi jakožto takovou celkem bezpečně užívat i pro běžnou práci. Pokud se ale zjistí, že některé nové příkazy nedělají, co se od nich očekává, nebo třeba dokonce vedou ke zhroucení programu, bude jedině na něm, aby se jim vyhýbal.
Je mi lito vsechny tyto nove funkce nechat jentak spat...
Vypada to velice pekne! ten Align se ridi dle uhlu natoceni soucastky? Vypada to ze ano, podle chovani k Q1 a zaroven Q7..
Takto je to naprosto dostacujici, upravy pozic takovych popisek jako jsou u diod, to bude opravdu jen kosmeticka uprava. Dekuji.
Zaroven bych Vas rad poprosil o nejakou verzi Layoutu, kterou bych mohl ja i pripadni dalsi zajemci v provozu dlouhodobe intenzivne testovat, tedy aby tam bylo alespon ukladani grafiky, moznost bileho pozadi, barveni gum.spoju, vynechani editace skrytych vrstev, a tyto dve nove funkce pro popisky (snad jsem jmenoval vse co by se mohlo otestovat), pokud souhlasite a je to z vaseho pohledu mozne. At muzeme pripadne nedostatky, napady a vylepseni v praxi odhalit. Vse klidne tak jak je napsane nahrubo, zatim nezakousnuté do programu a poskytl jste v testovacich verzich.
Vrátím-li se k Vaší výchozí motivaci, není mi jasné, proč by nápis musel být přesně ve středu. Možná stačí, dostane-li se dovnitř součástky (pokud ty se nepřekrývají, stejně součástku identifikuje jednoznačně). Samozřejmě existují i součástky jako LED pro 90° montáž, která se vlastně nalézá 2 cm vedle středu svých vývodů. Alespoň vidíte, proč jsem se výše ve vlákně zajímal, co se rozumí středem.
90° led, stejne jako konektory, jsou na desce mensinova skupina, a jejich pripadna korektura jiz nezabere tolik casu. Vetsina soucastek lezi celou svou plochou na desce. Snazil jsem se myslet na dotazeni funkce do co nejlepsich vysledku, i ten stred soucastky mi prijde nejvodnejsi zejmena z hlediska estetiky. Zaroven rozumim tomu, ze nema cenu se tim zabyvat prilis mnoho z toho duvodu ze to neni vylozene dulezita funkce ale "pouze" praci usnadnuje, takze snazim se o tom premyslet tak, aby to bylo snadno a rychle resitelne a zaroven efektivni..
Koncepci systému by se asi dost vymykalo, kdybych tam měl zavádět pojmy jako střed součástky v nějaké pevně dané vrstvě. To už by se mi více líbilo zavést příkaz pro nastavení okénka "kolem" množiny označených prvků. Skok na střed okénka již existuje, takže na zbývající operace by se třeba dalo napsat nějaké makro.
Mozna jsem to napsal nevystizne, mozna ted chapu ja nejasne. Myslel jsem to tak, ze si program zjisti u konkretni soucastky na jednotlivych osach X a Y vzdy nejvzdalenejsi bod od 0;0 soucastky, a stred textu pak umisti na souradnici Xmax/2 ; Ymax/2. Zaroven otoci text svisle pokud Xmax < Ymax, anebo vodorovne pokud Xmax >= Ymax.
Rotace nápisu kolem středu je možná, příkazem Edit | Change | Rotate Text.
Aha, omlouvam se, vim ze to nejak neslo se samotnou soucastkou (napada me vlastne, ze nelze na miste rotovat soucastku ale popisku ano, nelze posouvat hromadne popisky, ale soucastky ano...ale to patri jinam).
kolin napsal:(...) Mam tuseni ze program vi, v jakem uhlu se na desce soucastka nachazi oproti vychozimu stavu
Tohle samozřejmě v databázi je, pouze není příkaz, kterým by se takovéto součástky daly vybrat. Ale vedle Select | ... | Components | Mirrored bych jednou snad mohl přidat ještě nějaké Vertical a Flipped.
..proc ne, anebo dat moznost zadat vlastni uhel pro pripad slozitejsiho vyberu nestandartnich uhlu a vetsi univerzalnost..?
Pro zajímavost se lze zamyslet ještě nad tím, jak stejný problém řešit na obecnější úrovni. Jedna z možností by třeba byla ke stávajícím speciálním nápisům přidat ještě nějaké @NAME, @VAL a @PCKG. (Právě s tím se počítá pro verzi 5.x.) Součástka by pak mohla nápis se svým názvem obsahovat i několikrát, přičemž jeden by sloužil pro servisní potisk a další (na jiné vrstvě) např. pro ty osazovací plánky.
Mozna ze toto by bylo uplne nejlepsi, ale ne zrovna jednoduche, na druhou stranu byla by moznost osahat si to uz ted a poznatky aplikovat do nove verze. Zase ovsem zalezi na tom, kolik casu chcete ted teto funkci v teto verzi venovat..
Zkusil jsem si otevrit a editovat nekolik desek, nakonec jsem dospel k tomu, ze soucastek, ktere maji piny pouze nekde u okraje, je minimum.
Napriklad zde krom rotace nekterych popisek vyzaduje korekci jen K1, K2, Q2 a to jen z duvodu umisteni doprostred. Narazil jsem i na lezici krystal, ovsem to je opet jeden az 5 kusu na cele desce.
Necham tedy na Vas, zda a jake z diskutovanych reseni jeste provedete (primlouval bych se snad jen za to, aby se napis natocil podle toho, je-li soucastka sirsi nebo vyssi, aby nebylo potreba jeste vyzobat patricne popisky a rotovat je rucne prikazem viz.vyse - vlastne by se to po vycentrovani velice priblizilo vychozi pozici popisky po vlozeni pouzdra na desku), ale tak jak to je, to v zakladu dostacuje a casem by se to pripadne resilo dale.
Dekuji za rychlou reakci, funguje to hezky.
Vetsina nejcastejsich soucastek ma piny umistene tak, ze to napis opravdu vycentruje. Idealnejsi by bylo urcite brat v uvahu stredovou osu x a y soucastky. Nejlepe by bylo ridit se (jen) vrstvou, ktera nejlepe vyjadruje skutecny vnejsi rozmer soucastky. Nevim, zda by k tomu byla vhodnejsi vrstva 0(23) nebo 1(22), u ktere lze casteji ocekavat, ze bude vyjadrovat skutecny tvar soucastky, nebo vybrat tu, ktera vrstva k tomu byla puvodne Vami urcena spise. Ale to neni zas az tak nutne, korekci lze provest rucne a za pomoci presneho navadeni sipkami z klavesnice.
Dosla mi ale jina vec, a tou je rotace textu, pokud je soucastka otocena svisle, ma obdelnikovy tvar a je mala (ve valne vetsine odpor nebo kond.). Jelikoz neni moznost rotace na miste, pak musim postupovat nasledovne:
- provedu vycentrovani
- text, ktery jsem prehledl (nevyhoda - musim se textu stale hodne venovat), je potreba otocit do svisle (respektive vodorovne) polohy a nahrubo umistit
- provedu opet vycentrovani
Pokud byste se chtel zabyvat trochu elegantnejsim resenim, tak jsou tyto moznosti:
1) podle pomeru stran vnejsiho rozmeru soucastky lze alespon vytusit, zda se text lepe dovnitr vejde svisly, nebo vodorovny. Tato varianta se mi jevi jako nejefektivnejsi.
2) pak je jeste slozitejsi moznost a dle meho neposkytuje tolik inteligence v ohledu na umistitelnost, nicmene ji precijen zminuji:
Mam tuseni ze program vi, v jakem uhlu se na desce soucastka nachazi oproti vychozimu stavu, tudiz pokud by byla otocena v 90° a v 270°, text by byl svisle, a v 0°(360°) a 180° by text byl vodorovne, pricemz z ktere strany by byl citelny, se necha na uzivateli a prikazu Text Direction. (s ohledem na uhly, ktere nejsou v nasobcich 90° by zaroven bylo potreba se ridit rozsahy, ve kterych soucastka jeste muze byt, aby jeji text byl vhodne umisten (225 az 359°, 0 az 44°, 45 az 134° apod.), nebo tyto nestandatrtni uhly proste neresit a ignorovat, neni to precejen tak casty pripad).
Jinak ale velice dekuji, opet to usetri spoustu casu a jiz ted mohu rict, ze funkce vyhovuje a muze byt zakomponovana nastalo (pokud bude mit i drobnou inteligenci v rotaci napisu, tim lepe).
V podstate by se jednalo o vsechny popisky, ktere by byly zahrnuty do vyberu, tedy pokud oznacim celou soucastku, pak by se to tykalo vsech popisek, i tech neviditelnych, pokud oznacim pouze viditelnou popisku soucastky, pak by se to z cele teto soucastky tykalo jen ji.
Nevim co presne vyjadruje vami zminovany stred (polozku jsem nasel ve Schematu) - mam za to, ze poloha popisky pouzdra soucastky je dana v knihovne pouzder a schematicky editor nezajima poloha popisek pouzdra, nebo se mylim?
Je v podstate jedno, zda se bude brat za stred soucastky nejaky standartne definovany stred, anebo se vezme levy horni a pravy dolni roh samotneho vykresu pouzdra a pinu bez prihlednuti k jakymkoliv textovym popiskam a z toho se spocte stred. Z velke vetsiny ma soucastka alespon priblizne symetricky tvar, a nedokonalost nebo prekryvani se s pripadnymi vnitrimi obrysy soucastky si uzivatel uz opravi rucne. (Napr.to, jestli mam rozmistene opravdu vsechny popisky, kontroluji projetim nahledu pouzder pomoci Jump To | Component)
Dobry den, mam malou prosbicku:
Pokazde, kdyz dodelam desku, provadim i rozmisteni popisek soucastek v potisku. Deska do te doby muze byt stale jeste lehce upravovana, dokud se neposle do vyroby. V okamziku, kdy je deska finalni, muzeme teprve vygenerovat vykres pro osazovani (ktery vyzaduje i firma na osazovani pro jejich kontrolu a i my jej vyuzivame), coz znamena, ze rozmistene popisky kvuli vetsi prehlednosti vracim opet doprostred komponenty.
Bylo by mozne nejak ne zbytecne slozite pripsat funkci, ktera by vsechny vybrane popisky umistila doprostred plochy soucastky?
(Tato funkce by nejspise asi byla v menu Edit | Change pobliz polozky Text Direction)
Funkce se hodi i v pripade ze se upravuje napriklad jen polovina desky, kdy neni prilis vhodne vsechny dotcene soucastky smazat a nechat nahrat znovu, ale na druhou stranu bez navraceni popisek doprostred soucastky se stane, ze se popisky po posunu soucastky dostanou pres sebe, ci pres jine soucastky, a lze jen obtizne poznat, ktera popiska patri k jake soucastce.
Jen pro zajimavost uvedu jak to ma reseno Eagle, tam je to navraceni na puvodni misto mozne velice nestastne trikem - smazat veskere popisky soucastky, pricemz po smazani posledni popisky se opet vsechny objevi.
Dobry den, objevil jsem drobnou zaludnost (zajimavost, nebo snad chybku, nevim co to vlastne presne je), ktera v beznem nevrhovani nastane velmi vyjimecne. Picking Distance mam nastaveno na 10 a vsude se chova spravne, az na jednu situaci:
Cerne cary v dolni casti obrazku jsem domaloval pro znazorneni dvou navzajem nespojenych spojovych car, jak jsou vuci sobe posazeny ve schematu, odpor je pro znazorneni vzdalenosti. Snazil jsem se kurozr nastavit do nejvzdalenejsiho mista, kde primykani jeste reaguje.
Jak je patrno, dochazi k primknuti kurzoru v mnohem vetsi vzdalenosti nez je nastaveno. Je zajimave, ze k tomu nedochazi, pokud jsou cary nakresleny samotne, at jen vodorovna, nebo jen sikma. Takze, cim ostrejsi (mensi) uhel obe sviraji, tim delsi vzdalenost kurzoru od konce car napravo muze byt, aby se kurzor primknul.
Zaujalo mne to vicemene z toho duvodu, ze jsem posouval trosku delsi spoje, a jeden segment sikmeho spoje zasahoval mimo zobrazovany vyrez. Jakmile se kurzor primknul, vyrez se zaroven vycentroval na misto kam skocil kurzor a ja zprvu nechapal, proc mi poskakuje obraz. Je mozne, ze mam nekde neco spatne nastaveno, ale projel jsem cele nastaveni a nic nevypadalo ze by toto ovlivnilo..
Dekuji, obe chyby jsou odstraneny. Pokud prijdu jeste na dalsi, napisu.
Dlouholeta chyba pri tvarovani hranic typu asi bude zpusobena tim, ze nikdo patrne jeste nekombinoval ruzne sirky. Problem se totiz vyskytoval jen u signalovych car, nikoliv napr.u kontur. Snad z duvodu, ze schema je vice povazovano za logicke usporadani, a sirky spoju se resi az v layoutu, nebo proto, ze pokud vytisknu takove schema, kde jsou stejnou sirkou kresleny spoje i kontury (nebo sbernice), muze byt schema mene prehledne...nevim..
Prisel jsem jeste na jednu vec:
1) otevru program kliknutim na soubor schematu
2) vsechny labely na aktualne zobrazenem listu jsou tyrkysove (to je spravne, v celem schematu neni label, ktery by byl "homeless")
3) prepnu se na dalsi list a na nem jsou veskere labely fialove, totez je na vsech dalsich listech, vyjma listu, ktery byl zobrazen jako prvni
4) na nekterem z listu, kde jsou labely fialove, zvednu a polozim nahodne vybrany label pomoci edit / Move Pick a na aktualnim liste se vsechny labely prebarvi na tyrkysovou;
totez plati, pokud provedu prikaz Unselect All (neni podminkou, aby byl vybran jakykoliv objekt)
5) nyni opet zacnu prepinat mezi listy a zjistuji, ze na vsech listech, krom jednoho, jsou labely fialove, ovsem list, kde je vse v poradku jiz neni ten, co byl aktualni po otevreni souboru, ale list, kde jsem zvedl a polozil label naposled
Diskusní fórum k návrhovému systému Formica » Příspěvky od Tomáš Och