LinuxCNC pro obecné řízení

[zz912]

ked sme uz trochu mimo tak jedna otazocka: Je mozne pokracovat v programe g kodu tak aby sa necakalo na urcitu os pokial nedosiahne svojho ciela? T.j. ak sa mi presuva vozik v ose Y z bodu "A" do bodu "B" tak mu to trva urcitu dobu. A to by som uz chcel aby program necakal na tuto os Y a program g kodu pokracoval dalej aj napriek tomu ze os Y nie je este v pozicii.

Ono to je v konflikte s celou logikou cnc problematiky.

Řekl bych , že tato otázka rozhodně není rozhodně mimo a zcela se týká tohoto vlákna. Já si myslím, že je docela nešťastné používat k řízení takovéto mašinky G-cód, protože s ním budeš narážet na problémy viz výše. Myslím si, že nemáš pro takovéto stroječky ideální koncept použití LinuxuCNC. Třeba to tak není a někdo mě někdo opraví.

Otázka kam s příkazy y G-códu? Do HAL modulů?

Mex mi zde:
viewtopic.php?t=37308&start=45

radí s použití klávesnice:

Nevyšlo by snadněji a levněji udělat to třeba přes RS485 a číst to v user mode a nikoli v real-time režimu?

Tady si myslím, že bude klíč, k pořádnému využití LinuxuCNC. USER MODE a REAL-TIME. Pokud budu chtít něco řešit v real-time (pohyb serv, koncáky, tlačítko nouzového zastavení.... ), tak pod tím si představuji použití modulů v HALu. Pokud budu chtít něco v user mode (kontrola množství hřebíků, kontrola tlaku vzduchu), tak ani nevím, kde ten user mód hledat.

Bohužel, jsem tento dotaz na Mexa odložil, protože teď se věnuji spíše hardweru mašiny.

Byl bys ochotný rozepsat trochu více svůj problém? Bylo by zajímavé najít více řešení jednoho problému. On tvůj dotaz by mohl být podobný tomu, jak funguje automatická ruka výměny nástrojů, která si chystá třeba z kolotoče nástroj během frézování? Nebo jsem tvůj dotaz zcela nepochopil?

[testone]

paráda
klobouk dolů

359875 dni, 15 hod, 32min, Srandujem.

zeptám se jinak
Jak dlouho jsi to stavěl?
díky za info

ked sme uz trochu mimo tak jedna otazocka: Je mozne pokracovat v programe g kodu tak aby sa necakalo na urcitu os pokial nedosiahne svojho ciela? T.j. ak sa mi presuva vozik v ose Y z bodu "A" do bodu "B" tak mu to trva urcitu dobu. A to by som uz chcel aby program necakal na tuto os Y a program g kodu pokracoval dalej aj napriek tomu ze os Y nie je este v pozicii.
Ono to je v konflikte s celou logikou cnc problematiky.

možná položím dotaz úplně blbě, ale
Proč by nemohlo jezdit více os najednou?
prostě v jednom bloku (řádku) programu bude
X 123 ...
v dalším
Y 234 Z 345 ....
pak třeba
Z 456 A999 B888 ...
a pak zas
X 123
atd
atd
to je přece jen otázka jak je napsaný G kod
vždyť interpolovat pohyb více os je přece základní vlastnost CNC řízení
samozřejmě to není řešení viz dotaz výše, ale určitě by to celý proces zrychlilo
samozřejmě by to šlo použít jen tam, kde by nehrozily kolize, a asi by byla trochu pakárna to napsat, ale i tak
ale možná mi něco uniká

[Milan199]

to testone
U klasického ISO kodu jsou právě osy tou interpolací spřaženy a to co je v jednom řádku začne a skončí v jednom okamžiku. Pak se vykoná další řádek ...

Pokud jsem dotaz dobře pochopil, chce aby v průběhu interpolace např XZ jela osa Y tak, že začne třeba na 50% dráhy a skončí na 70% dráhy interpolace XZ.

[fupe]

1 - Zajímají mě success-stories, tedy nasazení LinuxCNC v nějaké oblasti pro obecné řízení. Třeba řízení nějaké průmyslové linky, nebo třeba zavlažování skleníku či řízení klimatizace/vytápění nebo cokoli jiného.

Před pár lety jsem vymýšlel kontrolní stanici na měření svárů světel do aut. Snad se zadavatel nebude zlobit když to zveřejním.
celý to fungovalo tak, že se do přípravku zastrčily levé-pravé světlo, přiklopil se měřící protikus s hrotama a ono to vyhodnotilo na cca 40 mistech jestli jsou kontakty dobre zatavené. Takže práce pro cvičenou opici, založit, zavřit, podívat se na kontrolku zelená-červená, v případě červené to hned ukázalo, který svár je chybný, vyndat, hodit do krabice. celý cyklus pár vteřin.
behalo to na beaglebone black (velikost kreditni karty) + 10" lcd, takže nebyl potřeba počítač. Řešil jsem nedostatek pinu, tak tam byly v řadě posuvny registry, ktery to načetly a pak se to seriově vyčetlo. Tím padem počet pinů v podstatě neomezený a vyčtený to má za pár ms.
mělo to vlastní grafické prostředí, počítalo to vadné a dobré kusy v serii a par nějakych kravinek okolo.
Protože to ničím nehejbalo, tak jsem použil jen nejaky základní hal moduly bez trajektory planneru a vlastní graficky ksicht a to je celé.
Linuxcnc (respektive machinekit) jsem použil proto, že ho jakštakš ovládám a navíc má možnost to celé pěkně nastavit a ladit. tim myslim třeba halscope a showconfig kde vidim co dělá v realném čase.
ještě nejakej obrázek at mate představu.
Martin

[Juro]

Taktiez zaujimave. Classicladder neslo pouzit? Kvoli vlasnemu screenu?

[Mex]

Moc děkuji oběma (Juro, fupe) za zveřejněné projekty.

Moje pojetí je prakticky totožné s tím fupeho. Tedy použít LinuxCNC jen jako platformu, kde jsou nachystané prostředky pro vývoj a pak běh v real-time prostředí. Ale i možností běhu v user-mode pro časově nekritické úkoly.
Tedy použít to v podstatě jako velké PLC, které má téměř neomezené možnosti a rozšiřitelnost, a které je programovatelné v "normálních" jazycích jako je Python nebo C.

Naprogramovat to celé jen přes G-kód mi připadá velmi komplikované. A klobouk dolů, že to Juro dal.

Ještě jednou díky. Mimo jiné i za to, že z fóra strojírenství děláte zase zpátky trochu fórum CNC.

[testone]

to testone
U klasického ISO kodu jsou právě osy tou interpolací spřaženy a to co je v jednom řádku začne a skončí v jednom okamžiku. Pak se vykoná další řádek ...

Pokud jsem dotaz dobře pochopil, chce aby v průběhu interpolace např XZ jela osa Y tak, že začne třeba na 50% dráhy a skončí na 70% dráhy interpolace XZ.

samozřejmě, to vím
jen mě napadlo, že v tom videu mu vždy jezdí jen jedna osa (jestli jsem správně koukal)
určitě by se tam někde našla možnost jet několika osami najednou, např. si něco někam předchystat
třeba abych pak nemusel čekat až vozík ujede celý metr, ale ujel by třeba 90 cm zároveň s něčím jiným (tak aby nehrozila kolize) a solo by v pravý okamžik dojel jen těch zbývajících 10 cm
nebo tak něco
určitě by se něco takového našlo
vím, že to neodpovídá původnímu dotazu na paralelní chod os, ale zato by to stálo jen zoptimalizovat G kod

[zz912]

Naprogramovat to celé jen přes G-kód mi připadá velmi komplikované. A klobouk dolů, že to Juro dal.

Řekl bych, že Juro taky volí možnost, tudy vím jak jít, tak tudy jdu.

[Juro]

Ono to nie je iba cez G kody. Su tam aj python programy ktore mi aktivuju v pravy okamih M kody.
Iba s Geckami by som to nedal.

@testone Samozrejme ze voziky (osi) som stamdemoval ako sa len dalo, ale to je este malo.
Ak mi portal zbija (klincuje) pracuju dve osi (X a Y). No a chcel by som aby osi Z a A pracovali "DOCASNE" nezavislo na X,Y a potom sa zasa zosynchronizovali s X,Y. A navyse mi do toho vstupuju signaly cakania na vstum M66 a to su dalsie sekundy.

Ale funguje to dobre a da sa tato linka ladit do nekonecna.

[milan584]

359875 dni, 15 hod, 32min, Srandujem.
Nepoznam ekonomicku situaciu zakaznika, tak netusim. Podla jeho slov, ma problem s ludmi.
Zbijanie a narezavania dreva na palety nie je nejak odborna kvalifikovana praca a tak si tuto pracu vyhladavaju miestny ludia s nizsim vzdelanim a sebavedomim. Potom vznika problem s dochvilnostou ,zodpovednostou, spolahlivostou a hlavne s alkoholom zamestnavanych ludi.

Este sa riesia casy pohybov rychlosti pohybov v programoch a pneumatike. Uz to ide sviznejsie ako na videu.

Ale tato linka bola odpoved na MEXovu otazku ci niekto riesi vyuzitie Linuxcnc trochu inak.

ked sme uz trochu mimo tak jedna otazocka: Je mozne pokracovat v programe g kodu tak aby sa necakalo na urcitu os pokial nedosiahne svojho ciela? T.j. ak sa mi presuva vozik v ose Y z bodu "A" do bodu "B" tak mu to trva urcitu dobu. A to by som uz chcel aby program necakal na tuto os Y a program g kodu pokracoval dalej aj napriek tomu ze os Y nie je este v pozicii.

Ono to je v konflikte s celou logikou cnc problematiky.

v konfliktu to není, běžně se to používá (od začátku numeriky) a bylo by to třeba.
Typická ukázka v historií je třeba SAB (SARY) kde šlo revolverem dělat v smyčce a jednotlivé příčné suporty (nebo cykly na hlavě v S1) pouštět tak, že revolver nečekal na dokončení suportového cyklu, ale hlídal pouze sebe - takže šlo dělat více suporty nejednou a bezpečně. Vyřešené to bylo celkem elegantně pomocí tzv. krokovacích podmínek - třeba:
N20 Z-100.00 C304 K301
N30 Z0.00
N40 T5 Z-50.00 K304
N50 G1 Z-60.00 F1000
(blok N30 se začne dělat po startu S3 ale dokončí se až když bude revolver na Z-100, N50 se rozběhne až když S3 rozjede z přepínacího bodu na baluffu rychloposuvem zpátky do výchozí polohy, pokud je při N40 S3 už zpátky, tak se rozběhne další blok hned)

[fupe]

Taktiez zaujimave. Classicladder neslo pouzit? Kvoli vlasnemu screenu?

Asi by šel použít,
na začátku studování LCNC asi tak 12 roků tomu na zad sem classiclader zkoušel, ale nejak mi nikdy nepřirostl k srdci. Připadá mi to takový nepřehledný, to si radši spichnu svůj HAL modul na miru na pár řádcích nebo python prográmek a ten pak použiju.


Když už to MEX nakousl, tak se taky zeptám. nezkoušeli jste někdo spřáhnout více LCNC strojů. Myslím tím nejakou třeba NML komunikaci nebo RSH po síti a podobně.
Jeden řídici stroj a nějaká podřazené. Něco jako zmiňovaná výrobní linka s master řidičem?
Některý stroje už začínají být tak složité, že by jim podle mě slušely třeba dva nezavislé řídíci systémy, které by ale měly možnost se za určitých podmínek spřáhnout a povidat si mezi sebou.
Třeba moderní soustruh s protivřetenem, kde si každá strana jede svoje operace (k tomu si hlidá kolize) ale pak přijde okamžik přehazovani obrobku, tak je potřeba spolupráce.
M

[Mex]

... nezkoušeli jste někdo spřáhnout více LCNC strojů. Myslím tím nejakou třeba NML komunikaci nebo RSH po síti a podobně.
Jeden řídici stroj a nějaká podřazené. Něco jako zmiňovaná výrobní linka s master řidičem?...

To je podle mě dost zajímavé téma.
Kdysi dávno jsem na to měl dokonce zakázku (kterou jsem nerealizoval). Nějakou "Rundtaktmachine" s odpáleným řízením. Ale mechanické věci i elektronika pohonů byla funkční.
Tyhle stroje mají otočný stůl a kolem něho několik 1-3osých obráběcích pracovišť. Na obrobku se vždy udělá jedna operace na jednom pracovišti, a pak se přesune na další.

Ten zákazník měl takových pracovišť už několik a koupil další se zničenou elektronikou. Původní dodavatel elektroniky mu na to dal naprosto nesmyslnou cenu (Švýcarská firma se Švýcarskýma cenama, už jen cestovné bylo dražší než za co koupil tu mašinu). Zkoušel se pak domluvit se Siemensem, některé jejich systémy to snad umí. Ale mám pocit, že se to nakonec taky nerealizovalo, že to taky vycházelo likvidačně draho.

Já jsem to tehdy musel odmítnout, protože jsem s LinuxCNC teprve začínal a netroufnul bych si na to ani náhodou.
Dneska bych to možná aspoň zkusil. Dát tam LCNC na nějakém malém HW pro každé to pracoviště, a pak možná ještě jedno, které by ovládalo otočný stůl a synchronizovalo jednotlivé operace.

Ilustrační obrázek takové Rundtaktmachine:

Rundtaktmaschine.jpg (15.79 KiB) Zobrazeno 3412 x

[Radhard]

Tak ten hlavní arbitr může běžet na čemkoliv - klidně to může řídit i blbý LOGO - co splní požadavek na I/O a další věci.

Podle mě, pokud má být něco něčím řízeno, a nemá to být klasické PLC s celou tou mašinérií kolem, tak preferuji věci jednoduché - malé (vhodné) MCU + C + (RTOS)

[Radhard]

Taky jedna možnost
https://www.controllino.biz/

[Mex]

Tak ten hlavní arbitr může běžet na čemkoliv - klidně to může řídit i blbý LOGO - co splní požadavek na I/O a další věci.
Podle mě, pokud má být něco něčím řízeno, a nemá to být klasické PLC s celou tou mašinérií kolem, tak preferuji věci jednoduché - malé (vhodné) MCU + C + (RTOS)

No to by sice mohlo. Ale pokud to bude taky LCNC, tak to celé bude pracovat v homogenním prostředí. Třeba včetně toho, že to centrální LCNC povede nějaké sumární agendy - statistiky, zajistí vzdálený přístup a monitoring a tak.

Ta jednodušší pracoviště by se jistě dala řídit i něčím velmi jednoduchým. Například GRBL. Ale to by jednak zanášelo do celého systému nehomogenitu. A hlavně by to fungovalo jen s omezeným sortimentem pohonů. Pro nějaké jednoduché DIR/STEP krokáče nebo serva ještě OK. Ale nějaká sběrnicová nebo analogová serva už tím neobsloužíš.

Kdežto kdyby se pro to nachystalo nějaké řešení na levném standardním HW (třeba RPi + karta Mesa), tak pořád cena té elektroniky pro jednu stanici bude nízká, ale už se otevírají velmi široké možnosti co a jak s tím řídit.