CNC Fórum

Zatim neni, ale bude. Ctvrta osa je v planu.
V kartach Gve64 a nove Gve66 je plne 4 osa interpolace (hotova).
Do Armota budu psat cca po vanocich, ted dopisuji jog (MPG)
pro Gve64, a to tak, ze bude chodit i bez PC, pro moznost rucniho
ovladani stroje, napr. orovnavani, kostkovani apod. S Armotem
samozrejme taky. Jen najednou vse nestiham.
Pavel

MPG uz funguje pekne, ted se jeste asi 14 dni budou testovat
mozne mezni stavy a celkova spolehlivost a pouzitelnost primo na stroji.
Pak prijde na radu ta 4.osa.
Pokud budou soucastni vlastnici Gve64 rozsirit o MPG, budou si muset nechat v Gravosu nahrat novy firmware soucasne s koupi MPG.
Pavel

GVE 64 je pouzitelne len s ARMOTE?

zaujima ma ci sa neda pouzit GVE 64 v kombinacii s Mach NINOS alebo EMC?
Ninos mam na mysli preto, lebo ma jasne a intuitivne ovladanie, mach preto lebo ho pouzivam nasledne co si vytvorim g kod v Ninose. Ludia zvyknuty pouzivat graficke sofware su raz dva v nom zorientovany.
Gravostar podla mna taky nie je, aj ked vela ludi ho tu ospevuje. Ked chcem v nom nieco nakreslit vzdy to vzdam, vsetko funguje naopak ako normalne.
Mam pocit ze aj Armote bude cosi podobne.

Chcel by som GVE 64, ale aby mi ta doska isla bez ARMOTE.
Je to mozne?

Zdravim,
Gve64 ma zverejneny instrukcni soubor (soucast datasheetu).
To znamena, ze si kdokoli muze napsat pro tuto jednotku aplikaci jakou chce. Jedna z techto aplikaci je Armote. SW nemusi byt nejak moc slozity,
muze napr. ridit davkovani zkumavek, ridit pohyb cidla magnetismu
pro zkoumani silocar apod... Zalezi na fantazii a potrebach.

Gve64 se pokusil ovladat Machem p.Pupak, ale zrejme to nedodelal,
nemam od nej zpravy, on sem uz nepise. O EMC ve spojeni s Gve64
se nikdo nepokusil (pokud vim).

Navrhl bych vam, aby az budete mit cestu do Prahy, zastavte se v Gravosu, (po predchozi telef.domluve s p.Vostarkem), a muzete si nezavazne vyzkouset. Rozhodnete se sam.
Armote byl navrzen tak, aby se dal tychle naucit, nic sloziteho na nem
neni, a je cesky.

Gravostar byl trochu inspirovan Autocadem, a pokud jste zvykly na Corel
nedivim se ze mate potize, je to odlisna filozofie. Hlavni sila je ale
ve vypoctech strojnich drah. Je mozne, a lide to casto delaji, ze si grafiku
navrhnou treba zrovna v Corelu, pres dxf prenesou do Gravostaru,
a tam vytvori strojni drahy, ktere jsou mnohem efektivnejsi, nez kdyz
tvorite offsety v Corelu. Umi i zbytkove obrabeni, kdy velke plochy vybere velka freza, a rohy vybere mensi freza. Setri se nastroje a cas.

Pavel

Zpozdilo se to, kousli jsme se na MPG ale uz doreseno. MPG umi ovladat
stroj s PC i bez PC, pak funguje to podobne jako klasicka frezka s klickami. Editor Gkodu uz taky je.
4.osa se blizi do finale, ke kouknuti 1.video z toho:
http://www.gravos.cz/download/m3k260.wmv - ke konci videa.
Pavel

Nechci zakládat nové téma, tak se zeptám tady. Zvažuji nákup GVE64-50. V současné době používám EMC2 + IO Board + drivery Leadshine. Mikrokrokování mám nastaveno na 1/5. Zrychlení 400 mm/s2. Referenční spínače na osách X a Y (indukční) a senzor nástroje (indukční). Běhá to perfektně, ale vadí mi na tom jedna věc. Uvedu příklad na kružnici. Pokud pojedu kružnici příkazem G2 s F2000 tak to opravdu jede nastavenou rychlostí. Pokud je ale kružnice z "čáreček" a jede to G1 tak to jede hodně pomaleji - čím více "čáreček" tím pomaleji to jede. Rád bych se zeptal, zda to výše uvedený systém ve spojení s Armote nějak řeší. Zda si trasu nějak předem předpočítává a opravdu udržuje nastavenou rychlost. Další otázka je zda je bezproblémové spojení GVE64 s drivery Leadshine 752. Děkuji za Vaše postřehy .....

z vlastni zkusenosti:
nikdy jsem nezaznamenal zpomaleni

pachal jsem napriklad mini program na vrtani/zavitovani M3 s datron nastrojem

vzorek je tu:
http://www.fdhs.cz/spiral/" onclick="window.open(this.href);return false;

ve finale by to asi muselo byt jeste jemnejsi aby to treba zahltilo komunikaci mezi pc a interpolatorem
nejaky limit tam bude ale ja jsem na nej v praxi nenarazil

s tema driverama nebude problem

V případě GVE64+Armote je to prakticky omezeno jen komunikační rychlostí, tedy na závislosti počtu/délky vektorů a požadované rychlosti. Všechny naše interpolační jednotky mají proto buffer vektorů, tedy komunikace probíhá tak, že armote posílá příkazy jednotce do bufferu a ta je zpracovává nastavenou rychlostí. Pokud je možné dodat vektory rychleji než se zpracují, k žádnému zpomalení nedojde a stroj se drží nastavené rychlosti. GVE64 má buffer o velikosti 420 vektorů.

V opačném případě stroj jede jen takovou rychlostí, aby na momentálně známém konci bufferu bylo možné bezpečně zastavit po nastavené rampě.

Pokud by tedy ke zpomalování vlivem zpracování vektorů v bufferu rychleji, než je možné jednotce dodat docházelo, lze to řešit v Armote 2 způsoby.

První způsob je využití vestavěného filtru krátkých vektorů, stačí zadat jak maximálně krátké mají vektory být, avšak s rostoucí délkou nejkratších vektorů roste odchylka od ideálního tvaru. (defaultně je filtr nastaven na délku 0,01mm)

Druhý způsob je použití paketizace komunikace, tedy interpolační jednotka neodpovídá na přijaté příkazy hned, ale až po dokončení paketu, tím se komunikace s jednotkou opět o něco zlepší, protože jednotka nemusí po každém příkazu posílat odpověď a Armote nemusí po každém příkazu na odpověď jednotky čekat. Délku paketu lze nastavit v rozmezí 2-64 příkazů.

V nejbližších dnech se chystáme rychlost komunikace o "něco málo" posílit, ze současných max 115 200Bd až na 921 600Bd, bude k tomu však potřeba do PC přidat přídavný řadič COM portu, který takovou rychlost skutečně zvládne (firmware je na to připravený).

Takový řadič který zaručeně zvládne takovou komunikační rychlost včetně galvanického oddělení komunikační linky též brzy bude u nás v nabídce.

Nicméně v běžné praxi stačí i těch 115 200Bd, to navýšení je zejména z důvodu vyšší komunikační náročnosti při kontinuálním 4-osém obrábění (hlavně pro jemné a rychlé finishování povrchu), kdy se kromě vektorů jednotce neustále posílají i nové rychlosti, protože aby mohla být dodržena nastavená rychlost, tak skutečná rychlost se neustále mění v závislosti na vzdálenosti špičky nástroje od středu otáčení rotační osy.

Jan Vostárek - GRAVOS

to MartinHora:
Spojeni driveru s gve64 bude bezproblemovy, testovali jsme driver M542, stejny
interface, vse ok.

S velkym datovym tokem (spusta kratkych carecek) jsme se setkali uz davno s daty
z nekterych SW pri gravirovani. Je to vyreseno velkym bufferem, vejde se do nej
420 vektoru (carecek) a rychlou komunikaci 921,6 kBaud.
Ve vetsine pripadu ale staci standardnich 115,2 kBaud.

Plynulost pohybu zalezi nejvic na kvalite rozpocitani jednotlivych carecek. Pokud je to
kostrbate, tak to ani rychle jet nemuze, napr. kdyz je v datech male vpravo vbok,
tak se proste brzdit musi, draha je svatá, a rychlost se musi prizpusobit fyzice stroje.
Kdo neveri, muze zkusit s autem ve velke rychlosti prudce zatocit.

Armote skutecne predpocitava kazky vektor a bere v uvahu maximalni moznou
rychlost na jeho konci a to posila do jednotky. V jednotce je tak jakasi mapa
koncovych rychlosti toho ktereho vektoru v bufferu.

Aby se dalo rict neco konkretnejsiho, bylo by potreba nejaka typicka data
z daneho SW videt, vyzkouset.
Take by se asi dalo domluvit s p.Vostarkem predvedeni, rozhodnete se sam.

Pavel

Dík za odpovědi. V příloze je g-kod který jsem jel naposledy. Jedná se o spirálové finishování kulovou frézou 3mm. Ikdyž mám nastaveno F2000 stroj mi jel max F600. Hodně by mi pomohlo při rozhodování, kdyby jste to někdo mohl vyzkoušet "nasucho". Pokud to armote nesežere, prosim napište co upravit a já upravím post. Ještě mám dotaz k referenčním spínačům. Mám je řešené jako spínací - je to problém? Ještě jedna věc. Při 3d obrábění finishuji v osách Y a Z (X-ko jede jen boční krok). Na osách Y a Z mám zrychlení 400 mm/s2 a na X jen 300 mm/s2 (portál má 70kg). Pročítal jsem manuál k armote a tam se zadává stejné zrychlení pro všechny osy - je to tak? Ale pravděpodobně to bude jedno. EMC při každém vektoru zrychluje a zpomaluje. Pokud si to Armote předpočítává tak by snad neměl být problém. Teď už jenom dostat chuť k předrátování elektroniky

EMC ma buffer treba na 100 000 radku programu(dufaultne nacita 2000).V planeru drahy je predem zpracovan cely program. Toto co popisujete s poctem entit na draze nema nic spolecneho a zavisi pouze na nastaveni a chtene presnosti dodrzeni skutecne drahy.

Zkuste pouzit funkci G64 s parametrem P ktery udava povoleni nepresnosti pri prechodech mezi entitami. Jinak je defaultne nastaven na nula a stroj presne dodrzuje drahu a rampy na kazde jednotlive usecce drahy !!! Neustale brzdi a rozjizdi se dle nastavenych ramp a max. rychlosti.

Zkuste nasledujici kod pro lepsi pochopeni.

G64 P0
G0 X0 Y0 Z50
X20
Y20
X0
Y0
M30

a s povolenim nepresnosti.

G64 P1
G0 X0 Y0 Z50
X20
Y20
X0
Y0
M30

V druhem prikladu program G kod projede v podstate plynule a temer jedenkrat rychleji ale rohy ctverce budou "zakulaceny o povolenou odchylku"


Vyse uvedeny problem se v praxi resi systemem planovani drahy ktery se nazyva JERK anebo dnes uz SMOOTH JERK ktery v podstate jednoduse receno nema linearni prubeh zrychleni a zpomaleni. (tot je uz ale vyssi divci a ani EMC ci GVE "pokud vim toto neumi)


RADEK

Dle mych dosavadnich znalosti JERK neni ani tak o planovani drahy jako spise o planovani rychlostniho profilu. Jde o to ze EMC (pravdepodobne i GVE) pouziva pouze lichobeznikovy profil, kde zmnena akcelerace je skokova. Tim padem je skokova i síla která je na stroj vyvíjena. Pokud se omezi na urcitou hodnotu i zmnena akcelerace (onen JERK) bude pohyb stroje plynulejsi (méně trhaný při plynulé zmněně síly) a tím pádem lze dosáhnout vyšších hodnot akcelerace.

Plánování dráhy zústává stejné, akorát má k dispozici lepší akceleraci = lepší dynamika = vyšší rychlost projetí "složitých" míst (ostrých rohů atd..).

Už si chvilku hraju s implementací JERKU přímo do MESY (5i20) takže v dohledné době bude pro EMC možnost použít lepší rychlostní profil než je stávající lichoběžníkový.

Problém je že nevím jaký bude zájem okolního světa implementovat tento JERK do "oficiálního" EMC. Něco jiného je když si to rozchodím u sebe doma, a další kapitola je "protlačit" to do oficiální verze aby z toho mohli těžit i ostatní. "Problém" je že je potřeba zmněnit jak Firmware v FPGA tak i HOST MOT 2 driver který s MESOU komunikuje.

ja bych to rad vyuzil
cim vic nas bude tim vetsi muze byt tlak na vyvojare oficialni distribuce

No ono to ma sve uskali v tom ze to bude pouzitelne pouze pro MESA karty, protoze RIZENI AKCELERACE i JERKU bude presunuto prave do FPGA. Ted je rizeni udelane kompatibilne tak aby bylo jedno jestli jedu pres software nebo hardware. Zezacatku me docela me prekvapilo ze ani akcelerace neni umistena v FPGA , ale zustava v PC - je to dáno prave tim jednotnym pristupem jak k SW reseni tak k HW reseni.
Nez se mi podari to zrealizovat tak to jeste chvilku potrva (precejen si s tim hraji po navratu z prace kdy uz mozek usilovně odmíta cokoliv řešit ).

Velmi zajimavy pristup na jerk limiting je pouyziti low-pass FIR filtru. Proste se klasicky vygeneruje seznam rychlosti s konstantni akceleraci, pak se pro kazdy nenavazujici usek prida nulova rychlost o delce FIR filtru. Pak se to prozene skrz FIR (prumer z n hodnot) a vysledkem je jerk-limited rychlostni profil, ktery presne kopiruje drahu. Nekde jsem na tohle tema vydel disertacku. Implementace primo do EMC by nemusela byt prilis slozita ...