tak uz se to hejbe, krasa nadhera. akorat se vozik strasne kejve, neb pusobi prilis velke zatizeni na dlouhem rameni, tzn ze jeste musim vyztuzit vedeni retezu nejakym prizmatickym vedenim pod koncem retezu a pres hlinikove jekly to propojit s tycema portalu. Coz neni nijak tragicke, celkem jsem rad, ze to utahnou draty motoru. Blby je, ze se nedostanu pres 400mm/s, coz zavani pruserem (krokace zacinaji rvat, pokud se k teto hodnote priblizim). Nicmene uz to jezdi jak ma, senzor materialu take funguje, takze do tydne by to mohlo fachat. Neni tu mezi vami nejaky TIGar se specializaci na hlinik? Kdyztak msg. Dik moc.

AKA_THE_A: rozebirat to kvuli tomu nebudu, ale to je prave alfa omega vlaknovyho laseru - ze se paprsek tvori primo v tom vlaknu, ktery pak pokracuje ven a vede ten paprsek. Ostatne nejde od zdroje oddelat - a to si vsimni u vsech fiberu, ze se prodavaji s kabelem. jinak by tam mohl byt nejaky QBH konektor jako na hlave, coz neni. Hadat se nebudu, ale co mam nastudovany, tak by to melo byt takto.

TLOUDEV: v tomhle kabelu by se nic (krom prostýho vedení) dít nemělo, vlákno laseru samotnýho by mělo bejt namotaný na bubnu ve zdroji...
ale cena zajímavá

TLOUDEV: laserovej modul, kabel a hlava se prodávaj jako sada? kolik to btw stojí? :D

Jedna fotka z prestavby CO2 na fiber - uz to jde do finale...

TEAPACK: ja to mam vymyslene trochu jinak, Pocitam s C osou, takze s pohonem vretene servem s prepinanim polohoveho a rychlostniho rezimu. Dneska uz to nevyjde o moc draz nez asynchronak s menicem. No a zavity pobezi vektorove, tedy v polohove rezimu. Pres enkoder by to slo taky, jen prepnu enkored z MPG na enkoder na vreteni, ale to bych se pripravil o moznost rezani /frezovani zavitu s libovolnxm poctem chodu a to by mi prisla skoda, no a taky najezdy a odjezdy z rezu zavitu zavisle na parametrech ktere v takovme pripade moc nebo spatne ovlivnim. Takhloe budu mit pod kontrolou uplne vsechno, co jsem koukal tam podobne to je reseno na vsech novejsich soustruzich. Je to i jednodussi nez resit mechanickou spojku z asynchronaku pro otackove rizeni a serva pro polohove rizeni C osy jako se to delalo driv.

TEAPACK: Je to i během řezání - když je to nějakej větší průměr, tak na začátku závitu jede třeba 1600 RPM, a na konci už třeba jenom 1200, protože to prostě neutáhne :-)

THERIDANE: já myslel během řezání závitů =) ale pokud máš všechno spřažený od rychlosti vřetene, tak tomu už docela rozumím =)

TEAPACK: Override se právě používá furt, protože programy píšou povětšinou ručně, rychlosti jsou vytahaný z klobouku a tak prostě naláduje tyč, spustí to, a pak přidává rychlost aby to mělo pěknej zvuk :-D

Velkým kolem (který přes šroub ovládá ten variátor) se šteluje rychlost vřetena, od které se odvozuje sync posuv. Na panelu je pak override 50-250% pro ostatní posuvy. Je to takový ghetto, ale padají z toho díly v toleranci, a dát novej život stoletýmu obráběcímu stroji je pěknej pocit :)

THERIDANE: tak takového stařečka nemáme ani my :D mne drží soustruh otáčky +-2 ot/min od 600 do 2400 :)

ale tam asi moc override otáček nepoužiješ...

TEAPACK: To by muselo mít vřeteno obrovský zrychlení aby nestačilo mezi pulzy enkoderu jít jen lineárně :) my máme na soustruhu enkoder se zhruba 50 pulzy na otáčku (a 1 index na otáčku), linuxcnc podle toho řídí synchronizovanej pohyb. Vřeteno není řízeno numericky, dokonce nemá ani regulaci otáček, je tam velmi starej asynchronák a variátorová převodovka. Otáčky kolísají v 10 % i na volnoběh, při řezání delších závitů to kolikrát sleze o třetinu :-D a výrobky jsou v pohodě.

JVCNC: jasný, ono u toho závitování bude záležet hodně na tom, jak máš nadrátovaný enkodér z vřetene do systému. Většinou jsou tam overridy zakázané, protože systém má už dost práce se synchronizací polohy vřetene a nože a ještě aby řešil synchronizaci přechodových křivek mezi oběma, když mu zvedneš rychlost o 20 %, to bys musel snímat polohu vřetene spojitě a nikoli jen z tacha a referenčního pulzu, jak to má většina soustruhů... =/

Jinak já raději do postprocesoru přebouchám definici cyklů z RS, než abych se to snažil implementovat sám, protože pak můžu v mašině v cyklu celkem jednoduše změnit nějaké parametry a nemusím kvůli tomu generovat celý soubor znova - například přísuv nebo nějaký rádius.

TEAPACK: uz to mam hotove, tak jak jsem psal, override otacek meni reznou rychlost a override posuvu meni feed per rev. Doslo mi ze ono to vlastne nejak jinak ani resit nejde, takye tohle bude u vsech systemu stejne.

teoreticky muze override fungovat i pri tom zavitovani, jen teda s otackama se zmeni i posuv a s posuvem i otacky, pak bz to nemel byt problem a az budu implementovat zavitovani tak to tak udelam. Jen teda jak tak koukam na zavitove cykly na soustruhu tak tam moc nejaka unifikace G kodu nefunguje. To bude vice prace udelat reserzi co ma jaky kod vlastne delat a co bude delat jaky jeho parametr nez samotna implementace :D

no to zavitovani bude taky zabava, no alespon se nejak posouvam, yavitovani asi bude na rade ted, predtim jsem delal automaticky popotahovac tyci. To si resi RS sam, neni treba zadnych M kodu atd. Obcas mi prijde docela hloupe resit kdejakou blbost ktera je strojni konstantou a funkci stroje delegovat do G kodu atd. pritom si to RS muze resit sam. treba implementaci toho popotahovace sem mel hotovou driv, nez bych to dodelal do postprocesoru nejakeho camu a ne vsechny camy vsechny funkce umi a obcas je dost opruz to resit v postu.

ja zase neznam moc (vubec) Haidna

JVCNC: Jinak, mám vysledovaný "výpočtový" strom, jak to tam funguje, ale znám terminologii pouze z Haidnu, takže pokud bys to chtěl přeložit do ISO-G, tak bych potřeboval výkladový slovník na tvoje zkratky, nebo ti to napíšu pseudokódem =)

JVCNC: Haidenhain to umí v obou případech, protože u každého nástroje si volíš buď fixní otáčky vřetene, nebo řeznou rychlost a posuv máš podle toho buď v mm/ot nebo mm/min a override funguje vždy, pokud stroj nepotřebuje mít synchronizovaný pohyb vřetene a suportu (typicky závitování)

Co se týče limitů, tak jsou tam rychlostní limity na vřeteno pro daný stupeň převodovky a limit rpm pro nástroj. Ani jeden z těch limitů to nepřeleze, ale pokud na limitu nejsi, tak si nastavenou řeznou rychlost v klidu "přetížíš" až o +- 50 % =) stejně tak ot/min vs maximální otáčky vřetene pro daný nástroj.

jo ted koukam na jedno video od Haase a tam to take pres G50 nepreleze nijak nic

to SSV taky asi implementuju, to bude prace na chvilku
Spindle Speed Variation - Stop chatter on your CNC lathe - Haas Automation
https://www.youtube.com/watch?v=dXR2wDDFFm4&t=1020s

TEAPACK: me jde o to jak se to chova pri zapnutem CSS, tedy kdyz se otacky meni automaticky podle prumeru a nezadavaji se otacky ale rezna rychlost a pak u posuvu kdyz se nezadava mm/min ale mm/rev a kdyz je zaroven pouzito CSS tedy posuv v mm/min je rizen automaticky podle otacek ktere jsou rizeny automaticky podle prumeru. Pak nemuzu overridem ovlivnovat primo ani otacky ani posuv, oboje je rizeno automaticky ale jedine co lze je ovlivnovat misto otacek reznou rychlost a misto minutoveho posuvu ovlivnovat otackovy posuv. Jen jestli to tak je jsem se nikde nedocetl, jen to ze overridem u otacek se lze dostat pres limit nastaveny pomoci G50, coz me prekvapilo, to by u mych zakazniku neproslo a omlatili mi o hlavu ze to je nebezpecne. Ten limit overridu mam jinak az do 999%, samozrejme pokud neprijde nejaky limit, v praxi to vede casto k tomu ze obsluha je lina si to nejak nastavit a nastavi to az na stroji overridem :D