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.
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.
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
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
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.
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.
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.
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.