Hlavní navigace

Vlákno názorů k článku Prohlížení vektorových výkresů ve formátu HPGL/PLT od anonym - mam rozdelany jednoduchy prohlizec PLT pod knihovnou Qt. dam...

  • Článek je starý, nové názory již nelze přidávat.
  • 15. 3. 2007 12:20

    Pavel Tišnovský
    To zni zajimave. Kdybyste potreboval nejake ukazkove soubory generovane napriklad AutoCADem 2006 pro ruzne plottery, muzu poslouzit.
  • 15. 3. 2007 12:23

    anonymní
    pouziju vase streva na cteni, akorat misto opengl prikazu to bude v ramci Qt widgetu.
    zadna silenost, jenom demonstracni srandicka.
  • 15. 3. 2007 13:46

    Pavel Tišnovský
    Treba se to nakonec vyvine v nejake univerzalnejsi vektorove prohlizedlo. To by nebylo vubec spatne, aplikaci tohoto typu je malo a nektere jsou prilis jednoucelove.
  • 15. 3. 2007 19:48

    Pavel Píša (neregistrovaný)
    Zdravím, opět musím zopakovat své poděkování za velmi hezky
    psané série článků.

    Co se týče software, tak zde přidám svojí již spíše odloženou
    hračku/trošku do mlýna, XY HPGL viewer a interpreter pro systém
    s krokovými motory, který běhal pod DOSem.

    http://cmp.felk.cvut.cz/~pisa/misc/xy-hpgl.tar.gz

    Je to projekt velmi starý, již dlouho neinovovaný, ale implementuje
    množství zajímavých vlastností, které by se Vám mohly hodit.
    Umí většinu běžně používaných příkazů HPGL, umí libovolné
    skládání transformačních matic, přitom výsledek zároveň vždy
    přepočítá pro zrychlení vykreslování do jedné matice.
    Protože kód běžel na velmi pomalém stroji, byl kód psán tak,
    aby nepotřeboval plovoucí aritmetiku.
    HPGL také definuje/původně definovalo rozlišení čísel jako 1/1000.
    Čísla jsou pak udržována ve formátu s pevnou desetinnou čárkou
    (0.001). Práci s tímto typem je nadefinována C++ třída a operátory,
    takže se s formátem pracuje bez nutnosti nad jeho vlastnostmi přemýšlet.
    Kód lze při použití současných výkonech desktopových procesorů
    převést na double. Na druhou stranu 1/1000 není soudělitelná
    s dvojkovým vyjádřením necelých čísel a při dlouhých sekvencích
    relativních pohybů může dojít ke kumulaci absolutních chyb.
    Pro malá embedded zařízení je použitá aritmetika výhodná i dnes.

    Kód je bohužel místy závislý na BC a 386 assembleru. Především

    muldiv(a,y,z) ... (int32_t)(((int64_t)x*(int64_t)y)/z)

    V GCC přepis není problém, pokud chybí int64_t (alá dřevní BC
    a Microsoft VC6.0), lze použít optimalizovaný náhradní C kód
    pro embedded aplikace.

    http://ocera.cvs.sourceforge.net/ocera/ocera/components/comm/can/utils/suiut/sui_dtrans.c?view=markup

    Kód umí výstup vykreslovat přes BGI drivery na obrazovku pod DOSem
    nebo může být výstup interpretovaný krokovým motorem připojeným
    na paralelní port. Je implementován i výstup textů přes BGI fonty.
    Například šlo vypsat HPGL vytisknuté z Wordu v Gotice.

    Při skládání úseků je použita třícestná optimalizace, která dovolí projíždění
    hran se zpomalením omezeným pouze požadavkem na maximální krok
    rychlosti v jedné ose a výpočtem zpomalení přes všechny zbývající úseky
    tak, aby se v posledním bodě trajektorie, nebo v místě PEN UP/DOWN
    dokázaly motory zastavit.

    Rozšířená n-rozměrná verze této optimalizace s možností pohybu
    po křivkách zadaných polynomy je použita i ve firmware
    jednotek MARS8. Ty ovšem nepracují s krokovými motory,
    ale s výkonnými regulátory a servy

    http://www.pikron.com/pages/products/motion_control/mars_8.html

    Kód XY HPGL jsem již před časem uvolnil pod GPL a alternativně
    i velmi volnou licencí, která za podmínky, že budou vylepšení do projektu
    vrácena, umožňuje i jeho použití v uzavřeném firmware různých zařízení.
    Udělal jsem to kvůli jednomu našemu studentovi, který chtěl psát
    placený SW pro řízení plotterů. Nikdy se mi potom již neozval.
    Na Web kód dávám jako reakci na Vaše články, protože přece jenom
    obsahuje o něco více funkcionality, než ten základní výukový příklad
    a zbytečné vynalézání kola se mi často zdá jako mrhání lidskou energií.
    Na druhou stranu je někdy z hlediska výuky nutné pro evoluci nových
    programátorů.

    Co se týče již předchozích příspěvcích zmíněné slušnosti některých lidí
    a firem a jejich vztahu k opensource, tak je situace velmi mrzutá. Mám s takovými
    lidmi, jejich úzkoprsostí a podrazy osobní velmi špatné zkušenosti, a to často
    přímo v místních luzích a hájích. Přitom na druhou stranu mezi rozumně uvažujícími
    lidmi opensource funguje a je velmi výhodným způsobem spolupráce,
    který nevyžaduje ztrácet většinu času nesmyslnými právními kličkami
    a znovuvymýšlením kol. Je ovšem potřeba, aby si komunita pamatovala
    ty, co nerespektují pravidla ( http://gpl-violations.org/ ) a ignorovala je
    v případech, kdy žádají o další pomoc a čas, za který od nich nelze očekávat
    žádný příspěvek ani slušnost, že uvedou, že dostupný kód použili. Měl jsem
    chuť zde uvést pár takových jmen, která zaslouží ban, ale kolega, jehož
    si vážím se jich zastal. Ti jedinci si to nezaslouží, ale zatím jejich zveřejnění
    odložím.

    Pokud by měl někdo ze studentů na ČVUT zájem dělat diplomovou
    nebo bakalářskou práci v této oblasti, tak tak ho rád povedu.
    Pokud kód použije kdokoliv jiný a bude respektovat nabídnuté podmínky
    a třeba něčím přispěje tak mě to jen potěší. Rád bych přislíbil i svojí pomoc,
    ale vzhledem k nedostatku času mohu nabídnout jen to, že když mi zbude
    čas, tak se pokusím odpovědět na případné dotazy.

    S pozdravem

    Pavel Píša
    pisa@cmp.felk.cvut.cz
  • 16. 3. 2007 14:24

    Pavel Tišnovský
    To vypadá moc zajímavě, děkuji (děkujeme) za odkaz.

    Já si pamatuji problémy se staršími perovými plottery (snad to dokonce byl originální HP), kde se rychlost posuvu krokových motorků nikdy neměnila - motorek buď stál nebo se točil konstantní rychlostí jedním směrem. Ten problém se projevoval zejména při použití neoriginálních per (v ČR resp. tehdy ČSR se na těchto věces šetřilo) při tisku šikmých čar.

    Zatímco motorky perem horizontálně či vertikálně pohybují konstantní rychlostí, u čáry šikmé 45 stupnů je ta rychlost v součtu 1,4x větší (Pythagorova věta :-). To dělalo problémy s tím, že česká rýsovací pera nedokázala tak rychle "pouštět tuš", takže se musela globálně snížit rychlost vykreslování (v té době se jednalo o AutoCAD 9).

    U stavebních výkresů, kde je 90% všech čar horizontálních a vertikálních to pěkně zpomalilo celé vykreslování a přitom by stačila malá úprava driveru, který by absolutní rychlost posuvu udržoval konstantní.

    S tím přístupem lidí k open source a zakázkám obecně máte pravdu. Problém je v tom, že teoreticky sice můžete svoje práva uhájit ale prakticky těžko. Když se jedná o malou zakázku (pár tisíc), tak spíš mávnu nad ztrátou rukou, než abych angažoval nějaké právníky a vůbec tím ztrácel čas.
  • 16. 3. 2007 16:32

    Pavel Píša (neregistrovaný)
    Krokový motorek nejde rozumně roztočit bez postupného zrychlování.
    Vypadl by z kroku nebo by se muselo motorkem pohybovat velmi pomalu.
    Takže si myslím, že ten plotr se rozjížděl na více kroků,
    ale u rychlých motorů to nemusí být téměř vidět.

    Jinak ten můj kód problém diagonální rychlosti přímo neřeší.
    Ale není problém to tam přidat. V kódu MARS8 je již možné
    určit horní maximum rychlosti pro každou osu zvlášť a minimální
    dobu pohybu (vlastně s/v) specifikovat pro každý úsek samostatně.

    Optimalizace řeší především přechody mezi úseky.
    Na starším originálním HP plotteru jsem pozoroval,
    že například přechody z kruhu do přímky a mezi přímkami
    znamenaly vždy zastavení na nulovou rychlost.

    Ideální test je Archimedova spirála. Kód XY zajistil,
    že se nejdříve pisátko pro malé poloměry pohybovalo pomalu
    a pak plynule zrychlovalo do maximální rychlosti limitované
    použitými motory. Obecně vycházela navržená optimalizace
    pro krokové motory velmi dobře. Pro DC motory, kde se zrychluje
    na mnohem více kroků je spíš výhodnější změny směru nahradit
    spline nebo je nutné trajektorii zadat jako velmi velké množství
    lineárních úseků opisujících oblouček, které mezi sebou mají
    velmi malé odchylkami směrů.

    Co se týče porušování pravidel, tak si myslím, že potřeba
    především zajistit, aby se vědělo (bylo někde publikováno),
    kdo se jak špatně zachoval a má být komunitou ignorován.
    Vzhledem k tomu, že v současné době začíná být používání
    a spolupráce s opensource nutností i pro velké firmy
    (software je tak složitý, že nikdo již nemá na vývoj
    všeho od začátku čas a ani peníze - to druhé má snad jen MS,
    ale neumí vychovávat lidi a výsává a křiví kde co - BSD, PD, atd),
    tak se tento trest může stát dostatečným prostředkem
    pro udržování pořádku. Totéž částečně platí i pro komerční
    projekty, protože subjekty, které jednou provedly podraz
    ho mohou provést opět a jsou pro všechny rizikovými partnery,
    kterým je lepší se vyhnout.
  • 15. 3. 2007 20:17

    xxx (neregistrovaný)
    zatim to bude srandicka. jako lepsi cesta se mi jevi filtr plt2svg a svg umi inkscape.
  • 16. 3. 2007 14:25

    Pavel Tišnovský
    Prave ze Inkscape (i kdyz je to vyborna aplikace) ma se zobrazenim nekterych SVG problemy, a to i u podle me zakladnich veci. Ciste prohlizecka by nebyla spatna, ostatne rastrove obrazky si taky prohlizim ve vieweru a nepoustim na ne GIMP.
  • 4. 8. 2007 0:37

    me (neregistrovaný)
    A hp2xx znate? Mozna ze ne, tak tady je link:

    http://www.gnu.org/software/hp2xx/