CNC Fórum

Zdravím. Chtěl bych se zeptat na možnosti viz nadpis. Mám nějaké konkrétní znalosti ohledně možností aretace / pozicování vřetenového motoru který standartně běží v rychlostním režimu. Ovšem při některých aplikacích narážím na mezery nebo nevědomost a rád bych zjistil jak to funguje. Popíšu oč mi jde.

Příkaz M19 normálně slouží k aretaci vřetene. Hádám že lze k něj připisovat parametr jako úhel. Takže třeba M19 P120. Vím že profi stroje si třeba pootáčí sondu tak aby vždy sondovala stejnou stranou. (jakože třeba levým unašecím kamenem vždy jede ve směru sondování).

Jak je tohoto docíleno ? Je nutné driver pro takto přesné pozicování přepnout do step dir ?
Já znám prakticky 2 možnosti aretace. Jednoduše přes pin "zaaretuj" do driveru a zpětná vazba zpět "zaaretováno". Případně přepnout driver do step dir. A tam není co řešit, ale je to step dir a ne rychlostní smyčka.

S tím je např. spojené závitování a řízení startovací polohy závitování. Systém (mach kupříkladu) vidí polohu enkodéru, případně další data. Takže dokáže synchronizovat posuv s otáčkami.
Jak ale funguje to pokud chci zaaretovat vřeteno na nějaký "startovací" úhel před začátkem toho závitování.

(S mým dosavadním poznáním) Představuju si že buď teda budu mít vřeteno v step dir při závitování celou dobu (což nevím jestli by vůbec nějak rozumně mohlo fungovat).
Nebo bych mohl přepnout driver do step dir, natočit do požadovaného úhlu, přepnout zpátky do rychlostní smyčky a pokračovat v řezání toho závitu.

Nebo je i nějaká další možnost jak řídit přesnou polohu vřetene bez přepínání do step/dir ?

Ja to delal na analogu zavedeni zpetne vazby od zavit. Encoderu a polohovou pid regulaci

No kombinuješ dvě věci dohromady.

Nejdřív probereme závitování. Tam to funguje tak, že vřeteno je celou dobu v rychlostním režimu a osa Z se přizpůsobuje poloze vřetene. Při závitování, není vřeteno v polohovacím režimu. Určitě si ted kladeš otazku jak je to řešený u soustruhu, když závituje na víckrát. Do řídícího systému musiš mít zavedeny signály o poloze z enkoderu, nejčastěji je to kvadratický signál A B. Zároveň musíš mít z enkodéru do systému zavedený i signál Z. To je jedno místo na enkodéru z celé otáčky. Cyklus závitování je zjednodušeně řešen tak, že se roztočí vřeteno a v okamžiku, kdy systém dostane Z signál, tak dojde k synchronizaci s osou Z. Čili při závitování nemusíš řídit vřeteno STEP DIR.

No a M19 je skutečně polohovací režim, se vším všudy. Může být řešen mnoha způsoby. Často zde bývá i požadavek na referování. Já to mám třeba řešený tak, že můj měnič umí fungovat i v polohovacím režimu, tak mu přes Modbus pošlu informaci, že chci aby byl v polohacím režimu a do jakého úhlu má dojet a o nic se nestarám.

To co popisuje robokop, tak ten si polohovací režim řeší na úrovni LCNC a do měníče posílá analogově rychlostní vazbu. Když už si umí tu polohu na úrovni LCNC vytvořit, tak ji jednoduše přes M19 využívá.

Ono i té M19 to není jen o tom, že přepneš na STEP DIR, ale musíš vyřešit i referování a to že se vřeteno při přepínání režimů zastaví pokaždé někde jinde.

zz912 píše: ↑8. 10. 2025, 7:40 No kombinuješ dvě věci dohromady.

Nejdřív probereme závitování. Tam to funguje tak, že vřeteno je celou dobu v rychlostním režimu a osa Z se přizpůsobuje poloze vřetene. Při závitování, není vřeteno v polohovacím režimu. Určitě si ted kladeš otazku jak je to řešený u soustruhu, když závituje na víckrát. Do řídícího systému musiš mít zavedeny signály o poloze z enkoderu, nejčastěji je to kvadratický signál A B. Zároveň musíš mít z enkodéru do systému zavedený i signál Z. To je jedno místo na enkodéru z celé otáčky. Cyklus závitování je zjednodušeně řešen tak, že se roztočí vřeteno a v okamžiku, kdy systém dostane Z signál, tak dojde k synchronizaci s osou Z. Čili při závitování nemusíš řídit vřeteno STEP DIR.

No a M19 je skutečně polohovací režim, se vším všudy. Může být řešen mnoha způsoby. Často zde bývá i požadavek na referování. Já to mám třeba řešený tak, že můj měnič umí fungovat i v polohovacím režimu, tak mu přes Modbus pošlu informaci, že chci aby byl v polohacím režimu a do jakého úhlu má dojet a o nic se nestarám.

To co popisuje robokop, tak ten si polohovací režim řeší na úrovni LCNC a do měníče posílá analogově rychlostní vazbu. Když už si umí tu polohu na úrovni LCNC vytvořit, tak ji jednoduše přes M19 využívá.

Ono i té M19 to není jen o tom, že přepneš na STEP DIR, ale musíš vyřešit i referování a to že se vřeteno při přepínání režimů zastaví pokaždé někde jinde.

Bezva. Už mi to je jasné.
Co se týče referování tak to by být problém neměl. S tím bych si poradil tak že systém vidí pozici enkodéru, a tak po změně režimu do step dir by systém akorát převzal polohu z něj. A referovat bych nemusel buď vůbec nebo při startu stroje (kde bych referenci řešil jen v driveru a signálem zreferováno bych šel zpět do systému).

Závitování tedy rozumím taky. A říkám si že když to funguje takto, tak by vlastně šlo úplně stejné chování aplikovat i k tomu závitování. Když v reálném čase jsem schopen vidět polohu enkodéru, tak bych nemusel sledovat signál ze Z ale jen číst polohu toho enkodéru a čekat na pozici 0 (nebo jakoukoli jinou). A prakticky by tak šlo dělat i vícechodý závit.
Tady je výhoda controlleru který používám protože enkodér se do něj dá jednoduše nacvaknout a propojení se systémem je tím vlastně hotové.

Díky mockrát, snad jak to popisuju to chápu správně.
Ještě jsem takovou práci s enkodérem nemusel řešit. Ale teď dávám dohromady 4 osý kombi soustruh a tam to bude potřeba.

Ono si jen pohlídej, aby to čekání na polohu 0 probíhalo realtimově. Pokud tam budeš mít nějakou userspaceovou komponentu, tak Ti to třeba někdy vyřeže závit v pohodě, někdy ne. LCNC obvykle pracuje na 1 kHz čili spoždění na spuštění synchronizace je do 1ms.

Vicechody zavit se dela bezne tak ze statrtujes se Z offsetem vuci prvnimu chodu

To mě taky napadlo a vidím to jako možnou bariéru co je třeba si pohlídat.
Já teď přesně nevím jak pracuje předávání informací mezi controllerem a počítačem.
Takto... V machu si mohu nastavit refresh rate PLC scriptu. Default je 50ms. Testoval jsem že i když si tam dopíšu dost věcí tak to v rámci jednoho "ticku" sežvejkne ten PLC script pod 1 ms. Ovšem když ten PLC script neběží, tak nám něco může uniknout. A asi si dokážu představit že není žádoucí PLC script spouštět každé 3ms... Ovšem...

Ovšem předpokládám že přenos dat mezi controllerem a počítačem na PLC scriptu závislý nebude a ten přenos je opravdu bez prodlevy (ethernetová komunikace). Tudíž z toho soudím že i přenos dat z enkodéru by měl být realtime.

Je to tak u LCNC ? Tam bude určitě stejný princip i v machu.

Případně pokud by tam prodleva byla a dělalo to problém tak bych mohl využít část Machu pro zpracování signálů (signal script) která je na PLC nezávislá a rychlost by měla být okamžitá. \tam bych využil ten Z signál z enkodéru.

robokop píše: ↑8. 10. 2025, 8:30 Vicechody zavit se dela bezne tak ze statrtujes se Z offsetem vuci prvnimu chodu

To zní jednoduše a účelně

Lukas_2 píše: ↑8. 10. 2025, 9:21

robokop píše: ↑8. 10. 2025, 8:30 Vicechody zavit se dela bezne tak ze statrtujes se Z offsetem vuci prvnimu chodu

To zní jednoduše a účelně

Má to omezení. Pokud ten závit děláš k nějakému osazení // což je dost často // tak to nemůžeš použít.
Možná by bylo dobré, když už se s tím zabýváš počítat s offsetem úhlovým od IRCu vřetene. Těch možností je víc. Já to mám udělané tak, že čekám ve výchozí poloze na Z impulz. U jednochodého závitu startuji hned, u vícechodých přičítám to "úhlové pootočení" pro další chody. Po synchronizaci řadím natvrdo, že po n pulzech od IRCu se vykoná krok v příslušném směru Z osy.
Má to ale nevýhodu, že to startuje natvrdo bez rampy, což nemusí být po chuti krokáčům.
Takže snižuji otáčky vřetene při startu a po rozjezdu osy je zvýším na pracovní úroveň.

U linuxcnc muzes takto delat k osazeni i vycechody. Na cilovem Z to co nejrychleji vytahne a je jedno kde startoval. Typicky si namerim kde se vejdu s kudlou na papirek. Opravdu se platek skoro dotyka. To vezmu jako cilove Z a nikdy nezabouram.

Lukas_2 píše: ↑8. 10. 2025, 8:50 Je to tak u LCNC ? Tam bude určitě stejný princip i v machu.

Určitě NE. Mach není LinuxCNC a LinuxCNC není Mach, tak jak Windows není Linux a Linux není Windows. Jsou to dva světy.

Rozdíl mezi Machem a LinuxemCNC není jen o tom, že LCNC má otevřený zdrojáky. Hlavní je rozdíl je v Architektuře. Pokud bychom tyto dva systémy porovnávali ve variantě s paralelním portem, tak na tom oba systémy budou podobně. Sice teď schytám narážky na realtime ve windowsech, ale znám lidi, kterým to "nějak" funguje. Jakmile se začnem bavit o variantě Machu s controlerem, tak zde se situace drasticky mění. Je potřeba si uvědomit, LCNC nepoužívá controléry. Teoreticky by controlér používat mohl, ale je to proti jeho vlastní filozofii. Kdysi jsem četl, že se o to někdo pokoušel, ale víc jsem se o to nezajímal. LinuxCNC používá externí elektroniky (nejčastěji Mesa karty), což jsou pouze elektroniky, které mají stepgeny (vytváření pulzů pro krokáče), čítače (počítání pulzů z enkoderů), vstupy/výstupy a mnoho dalšího. To co se bere v Machu jako controlér, tak je v LCNC částečně v elektronice a částečně v softwaru, který přechroupává CPU.
U Machu po ethernetu běží G-code (nebo nějaká jeho úprava)
U LCNC po ethernetu běží hodnoty poloh serv, enkodérů, IO atd.

Výhody této koncepce:
- elektroniky řeší jen primitivní úkony. neřeší interpolace, překládání G-códu atd.
- využití FPGA nebo CPU na elektronikách je maximálně efektivní
- neuvěřitelná možnost variability. Například když máš 4 stepgeny, tak je můžeš využívat jako kinematiky: XYZA, XYZB, XYZC, XXYZ, XYZZ, XXZZ, ..... Nebo stepgen můžeš používat pro otáčení karuselu a neplýtváš osami. Nebo při změně firmwaru, můžeš výstup pro stepgen používat jako PWM generátor
- jádro LCNC je stavěné na to, aby pracovalo rychle, takže když řešíš, že něco se musí stihnout, tak víš, že to se to stihne. Je běžné že LCNC počítá vše každou milisekundu 24/7. Umí používat userspace komponenty, které nevyužívají realtime a nezdržují ho. Třeba zobrazování GUI se aktualizuje každých 100ms. Navíc LCNC umí řešit najednou až tři vlákna, takže může počítat něco daleko pomalejc než každou ms ale i daleko rychlejc.

Nevýhody této koncepce:
Musíš mít dobře vybranej hardware a dobře naladěnej aby vše stíhal. Na druhou stranu, existují postupy jak to udělat a když už Ti to jednou funguje, tak na to nešaháš.

Proto si nemyslím, že je dobré aby integrátor Machu opisoval od integrátora LCNC. V LCNC máš na startu sice spoustu problémů, ale vše se dá nějak vyřešit. V Machu máš na začátku jasně daná pravidla daná možnostmi kontroléru, ale otázka je, zda uspěješ, pokud budeš chtít tyto možnosti obcházet.

Píšeš, že děláš 4 osý kombi soustruh. Pokud k němu seženeš Mach controlér, který je koncipován pro 4 osé kombi soustruhy, tak v tom případě bych chápal cestu Machu....

Ty možnosti Linuxu jsou opravdu větší. O tom není sporu.
Co se týče Machu tak tam to řídí controller, a proto je potřeba aby ten controller byl kvalitní. Máš pravdu že Mach posílá do controlleru G kód nebo nějakou jeho formu.

Každopádně. Udělal jsem si rychlé testování.
Mach běží na knihovně wxLua.
Vytvořil jsem si vlastní thread a refresh rate nastavil na 1 ms.
V rámci tohoto threadu snímám registr s polohou enkodéru.
Při protnutí pozice <0.01 se thread ukončí a vrátí do systému informaci o vyžádané poloze.
Pak systém může navázat.

Toto jsem testoval v M kódu který běží v hlavní smyčce Machu, tudíž bez prostojů.

Dále jsem se zaměřil na odezvu controller - PC. Ta je dle diagnostiky průměrně 1,5ms. Což je standartní podle toho co jsem se dočetl.

Podle tohoto si myslím že odezva je dostatečně malá aby s tím šlo nějak pracovat a třeba si vytvářet vlastní funkce.
To ovšem bude chtít testování. Pro maximální spolehlivost asi i implementaci nějakého koeficientu dle otáček vřetene, akcelerace os atd...