Rychlost obrábění

[SnakeCZCOM]

Zdravým
při programování v CAMu mi vychází odlišné časy výroby. Zjistil jsem že je to tím, že pokud obrábím v 4/5 osách, tak stroj přepočítává posuv na uhlovou rychlost. Potom je obrábění pomalejší než vypočítá CAM a proto že je posuv pomalejší než jsem zadal. Můžete mi prosím poradit, jaká je funkce, aby stroj převedl uhlovou rychlost lineární rychlost, případně poslat vzorový příklad, abych mohl říct poskytovateli CAMu, co zadat do postprocesoru? Jedná se o systém Sinumerik 840.
Děkuji

[robokop]

Nemyslim ze to je tim v jakem modu se pohybujes ale tim ze cam nezapocitava akcelerace a dalsi jalove casy.

[SnakeCZCOM]

Tomu rozumím, ale v tom případě si myslím, že čas by byl odlišný cca 10-15% ale já ho mám odlišný 40-60% a to už je docela dost.
Soustružení a frézování ve třech osách mi časy sedí +- právě těch 10%

[Radislav]

Akcelerace a decelerace to je nejvetsi rozdil to co mas v CAMu a co se deje v realu. Pokud nemas nejaky lepsi CAM ktere maji i svuj simulator popripade vericut jako nadstavbu tak se to bude blbe odhadovat a nekdy ti to ujede o par procent a nekdy jak pises i o 60. A se slozitejsim tvarem obrobku budou rozdily vetsi a vetsi.

Nastesti jsou reseni co tohle cim dal zpresnuji. Viz simulatory s digitalnimi dvojcaty kde se zadavaji hodnoty stroje pro akceleraci v jednotlivych osach atd.. Dokonce nekteri meri tohle chovani pres nejakou interaktivni kostku a jezdi po nem nastrojem v realu na masine a to pak ty strojni casy se lisi napriklad +- 10 procent.

[robokop]

kdyz v camu najdes tu hodnotu ktera to popisuje mohlo by stacit modifikovat to do te doby nez ti simulace vyjde podobne jako real

[Radislav]

kdyz v camu najdes tu hodnotu ktera to popisuje mohlo by stacit modifikovat to do te doby nez ti simulace vyjde podobne jako real

Ja jsem to treba zkousel a povedlo se mi to dostat plus minus par minut rozdil. Jenze pak kdyz jsem to zkusil na 5ti ose obrabeni tak to bylo uplne vedle zase treba az o 50procent mimo. Davam za vinu ze stroj je z roku 2006 a to souvisly tam neni dobry respektive tragickej otocnej stul.

Ale pokud to nekdo s timhle mysli vazne tak to musi byt bud nadstavba jako je vericut nebo CAM musi mit svuj "virtual machining" kdy to opravdu vsechno je vyladeny i s vymenama nastroju, digitalni dvojce atd... A to jsou vetsinou CAMy v high endu. Sam jsem na tohle zvedavej u svyho CAMu jestli na to nekdy budu mit stroj.

[Mex]

Docela mě udivuje, že třeba v LinuxCNC není nějaký nástroj pro přesný výpočet doby obrábění. Nebo teda aspoň já o něm nevím.
Systém má veškeré informace o parametrech stroje. Tak pokud je to stroj bez zpětně vazby do systému, tak je možné naprosto přesně odsimulovat čas obrábění.

[RaS]

když načteš program v linuxcnc a dáš vlastnosti tak ti napíše čas obrábění.. pokud to pojede na 100% tak to i sedí

[Mex]

když načteš program v linuxcnc a dáš vlastnosti tak ti napíše čas obrábění.. pokud to pojede na 100% tak to i sedí

Takže B je správně - nevím o tom.
Díky, tam jsem to nikdy nehledal. Vždy jsem spoléhal jen na info z CAMu, ale to je hodně nepřesné.
Tady to vypadá mnohem přesněji (zatím testováno jen na malých souborech).
Takže ještě jednou dík.

EDIT: Tak jsem to zkusil na velkém souboru (110 tis. řádků). Podle odhadu měl jet 22.8 minuty, v reálu to bylo skoro 35 minut.
Tak tady se mu odhad moc nepovedl.
Jezdilo to tedy hodně rychle a s velkými akceleracemi (jede to jen naprázdno, není to připojeno na reálnou frézku).
Tak to zítra zkusím pustit nějakou výrazně pomalejší rychlostí, jestli se jeho odhad zlepší. Pak to ale bude pokus na několik hodin.

[RaS]

já tedy nikdy neměřil jak moc to sedí, ale odhadem to celkem jde...
třeba u mě trvá výměna nástroje od 3do cca 20s podle polohy nástroje v zásobníku, nicméně linuxcnc tohle nemá šanci vědět tak tam musí dát na výměnu nějaký defaultní čas (klidně třeba i 0s) tak na 2-3 výměnách nástroje to už může být znát.. rovněž netuším jak to počítá s akcelerací (jestli vůbec) jestli tam neflákne jen odhadnuté časy pohybu z bodu A do B podle aktG1/maxG0 rychlosti.. potom to na některém typu obrábění může sedět téměř dokonale a u něčeho nesedět o 10ky%..

[Radislav]

já tedy nikdy neměřil jak moc to sedí, ale odhadem to celkem jde...
třeba u mě trvá výměna nástroje od 3do cca 20s podle polohy nástroje v zásobníku, nicméně linuxcnc tohle nemá šanci vědět tak tam musí dát na výměnu nějaký defaultní čas (klidně třeba i 0s) tak na 2-3 výměnách nástroje to už může být znát.. rovněž netuším jak to počítá s akcelerací (jestli vůbec) jestli tam neflákne jen odhadnuté časy pohybu z bodu A do B podle aktG1/maxG0 rychlosti.. potom to na některém typu obrábění může sedět téměř dokonale a u něčeho nesedět o 10ky%..

Přesně tak. Jak jsem psal ,ten kdo něco takového potřebuje tak si pořídí třeba Vericut. Nebo dojde na mašinu třeba na Haidnu a odsimuluje si tam daný program a věřím ,že tam bude odchylka cca do 20 procent. (kterou si člověk může vždycky přičíst) CAM ,který dokáže reálnou simulaci stroje tak ten bude umět strojní čas odhadnout do 10 procentní max. odchylky (můj odhad). Co vím tak hyperMILL a jejich momentální virtual machining. Říkám to proto ,že hyperMILL máme takže mám přehled co a jak je. NX CAM taky něco má tuším. A víceméně určitě všichni z top segmentu jako je workNC,NX,hyperMILL,TEBIS,POWERMILL budou mít featurky pro přesnější odhad strojního času na mašině.

Jistotou je Vericut ten v tom jede dost dlouho. Kdo ví jestli není první.

[Thomeeque]

LinuxCNC se asi o něco trochu sofistikovanějšího pokouší, ale funguje to všelijak. V GCU se o nic nepokouším a jednoduše sčítám délka/feed jednotlivých úseků (tj. akceleraci-brždění neřeším), přesto mi u některých programů LinuxCNC ukazuje kratší čas, což není fyzicky možné (leda bych měl já chybu v GCU, ale to také není možné ). A extrém je LinuxCNC example 3D_Chips.ngc, který mi LinuxCNC odhadl na 4 vteřiny (GCU to vidí na 2 minuty, což je imho reálnější ).

T.

EDIT: Ha ha, ten 3D_Chips.ngc má feedrate mezi jedním až 4.5 milionu (#<fscale> = 10000.0) Tak to to má nakonec ten LinuxCNC spočtené možná přesněji

EDIT2: Už vim. Pokud (v GCU) při výpočtu času pro daný segment aktuální feed překračuje hodnotu zadanou pro Rapid Feed, použiju zadaný Rapid Feed (čili to není bug, ale feature )

[SnakeCZCOM]

Jestli vás dobře chápu, tak tou akcelerací myslíte za jak dlouho dosáhne stroj požadované rychlosti že? Kolik to tak může u stroje dělat?

[SnakeCZCOM]

Já chápu, že jsou další fakta které nejsou v CAMu. Já mám třeba u výměny nástrojů nastavených 30 vteřin. Přitom výměna mi trvá cca 10 vteřin. Ale právě i tímto jsem chtěl kompenzovat další odchylky. To samé dělám u výpočtu času. Řezné podmínky stanovým cca o 30% menší.
Při soustružení a frézování ve třech osách mám vždy skutečný čas díky tomu rychlejší. Klidně můžu soustružit 5 hodin v kuse a ten čas vždy sedí. Jakmile ale dojde na 4 a 5 osé je rozdíl hodně velký. Když spočítám na něco 8 hodin a výsledek je 14 hodin, bez toho abych něco nastavovaly, opravovaly a pokaždé jedeme na 100 někdy i 120%. Tak to asi v pořádku nebude. A nemyslím si, že v tomto hraje roli akcelerace a podobně. Protože ty časové odchylky u těchto strojů jsou v setinách vteřiny.

[robokop]

Ty rotacni osy maji typicky mnohem delsi akcelerace. A pohyb cele masiny je limitovany jeji nejpomalejsi osou ktera je v tom kterem pohybu zucastnena.
Jestlize nelze zadat do camu akceleraci kazde jedne osy jak by to mohl vedet? Podle ceho by mohl pocitat casy? Jak moc jede vyhlazovani drah? Nepredpokladam ze jedes v exact stop modu. Je cela rada parametru ktera to primo ovlivnuje. A ty vyse zminovane to ovlivnuji pokazde takze je li ten viceosy program pro plynule viceose obrabeni slozeny z milionu vektoru. Kdyz se na kazdem tom vektoru projevi treba 30 ms a mas tam 100k vektoru tak jestli dobre pocitam je to slaba hodinka odchylky v dobe trvani programu. Takze sebemensi odchylka v zadane akceleraci zpusobi brutalni chybu ve vypoctu trvani programu. Jeste stale mas nejaky pocit nebo uz jsem ti dokazal kde s nejvetsi pravdepodobnosti vezi chyba?
Mas moznost nastavit v camu akcelerace pro jednotlive osy zvlast? A co limitni rychlosti os?