Szerintem is fontos, hogy határozott szándék esetén induljon el bármilyen mozgás, tehát enterre ne,
hanem csak a START gombra.
Az meg alapból fontos, hogy fizikai valós nyomógombokat is lehessen használni az összes fontos funkcióhoz ne pedig csak az egérrel egerészni egy képernyőn.
Munka közben a gombok nyomkodása vakon kell, hogy menjen, erre sem a billentyűzet sem az egér nem alakalmas.
Bár ez megoldható itt is, már most is egy másik billentyűzetként csatlakoztatott felülettel ahol ergonómiailag jól elhelyezett nyomógombok vannak kiképezve.
Az iparból átvenni a formai külsőségeket azért is hasznos, mert aki hobbistaként beleszokik ebbe a világba az ha beáll egy ipari gép mellé akkor sokmindent ismerősként üdvözölhet.
Szerintem is a letisztult felület a jó, csak az van ott ami kell, és az az ablak csak azt tudja ami oda tartozik.

Előzmény: svejk, 2014-07-14 11:13:00 [503]

CNCdrive1,írtam egy levelet,kérlek majd nézd meg.

Még egy dolog, érdemes előre gondolkodni az UC300-ra is.
Ott ugye van elegendő bemenet, az össze fontos kezelőgomb kivihető igazi nyomógombra.
(azt azért tudjuk, hogy az egerészés munka közben nem túl kellemes, marad esetleg az érintőképernyő)
De ha már a gombok kivezethetők akkor érdemes maga a képernyőt is úgy szerkeszteni, hogy egy intaraktív gombsor legyen a képernyő oldalán, alján ami továbbra is kezelhet egérrel de akár a képernyő mellé ki lehet helyezni fizikailag is a gombokat.
Az iparban ez is megszokott bevált formula, természetesen itt egy gombnak több funkciója lehet és van is, de ez az interaktív képernyőn jól leolvasható.
Ezekkel pl. lehetne az üzemmódokat váltani.

Én elterveztem, hogy az UC300 és a Mach3 párossal elkövetem ezt, de most már inkább hajlanék az UCCNC-re mint a kissé háklis mach3-ra.

Kiszürkítés esetén lehet maradhatna a mostani képernyő is, mert biztos nagy munka újat létrehozni.
Ilyenkor lehetne alul vagy felül egy gombsor amivel ki lehetne választani a Programfutás, MDI , kézi üzemmódot.


No persze én innen könnyen beszélek, nincs is semmi közöm hozzá, de hát ugye most tesztelés van.

Ha a zagyvaságaimban találtok 1% hasznos dolgot akkor már megérte.

Én úgy gondolom érdemes lenne egy-egy ipari gépet tanulmányozni és a hasznos funkciókat lekoppintani.

Kár, hogy olyan fórumtársak nem szólnak hozzá a témához, akik napi szinten használják a gépüket, ami lehet akár ipari vagy hobby gép.
leírhatnák ők is a saját vezérlőik előnyeit, hátrányait.

Előzmény: svejk, 2014-07-14 11:21:00 [504]

Az MDI üzemmódot általában koordinátákra való ráállásra egyszerű, pár műveletes marásokra, fúrásokra használja az ember, ilyenkor feleslegesek azok a funkciók amik a program futásával kapcsolatosak.
Ugyan így fordítva is, program futása közben felesleges az MDI sor.

Már az elején is említettem, hogy nem ártana az épp nem használatos vagy nem funkcionáló gombokat kiszürkíteni a könnyebb átláthatóság kedvéért.

Előzmény: svejk, 2014-07-14 11:13:00 [503]

Nem tudom de ez valahogy nem kafa...

Valahogy szét kellene választani az MDI-t a programfutástól akár külön fülre.
pl. a toolpath-nak kár a külön fül úgy hogy a DRO-kat sem látom mert így csak látványt nyújt, de hasznos információt alig.

A mostani helyzetben ha beütök az MDI-sorba parancsot akkor az is az enterrel hajtódik végre és ugyan úgy az enterrel kell kilépni is.
Ezért nyomom meg félve, vagyis nagyon kell figyelni, hogy ne legyen semmi írva az MDI sorba kilépéskor.

Az iparban az MDI parancs is csak a ciklus start gomb megnyomásával hajtódik végre.

Az UCCNC-nél ha be van töltve egy program és írok az MDI-ba akkor enterrel az MDI hajtódik végre a Start gombbal a betöltött G-kód.
De ebbe szerintem bele lehet majd keveredni.

Előzmény: n/a (inaktív), 2014-07-14 10:18:00 [502]

Szia,

Na ok, de akkor hogyan kellene kilépni az MDI-ből?
Mach3-ban egyébként éppen ugyanígy lehet, az enter-el...

Előzmény: svejk, 2014-07-14 09:59:00 [501]

Most az előbb munkadarabot is faragtam az UCCNC segítségével.
De nekem ez az Enterrel való kilépés az MDI üzemmódból nagyon nem tetszik.
Az Enter ugye általában adatbevitelre vagy folyamat elindítására való, így akaratlanul is nagyon félve nyomtam le minden alkalommal.
Tudom-tudom szokás kérdése is lehet...
(mondjuk a Mach3 Alt-1, Alt-2 váltása is elég körülményes)

Az igazi gépeken ugye egy-egy átváltó gomb van a Programfuttatás, MDI, kézi üzemmód, stb. közt.

Arra is gondolni kell, hogy az UC300-on van elég(?) bemenet, ott ez könnyen megoldható lesz külső gombokkal.
Lehet már itt fel lehetne készülni egy-egy képernyő gombbal.

Nem a jövő héten van ? Mindegy én inkább írom a programomat most tovább, annyira nem izgat.

Előzmény: n/a (inaktív), 2014-07-13 21:57:00 [499]

Jaaajajj, megyek is nézni a VB döntőt, jó, hogy szóltál...

Előzmény: Törölt felhasználó, 2014-07-13 21:49:00 [497]

Én lehetek bármilyen alázatos, az még nem változtat azon a tényen, hogy a szoftver nem mér környezeti fizikai tulajdonságokat, változókat, így az én alázatomtól függetlenül ő mit sem tud a környezetéről.
Sajnos ennél érthetőbben nem tudom leírni.

Amúgy a program konfigurálható, úgy adja ki a jeleket ahogy a felhasználója beállította.
Ha a felhasználó elég alázatos volt, akkor jól fogja vezérelni az adott gépet, ha nem akkor meg a szoftver ha megszakad sem tudja jól vezérelni az elrontott gépet.

Előzmény: Törölt felhasználó, 2014-07-13 21:49:00 [497]

Nem értelek teljesen.
Tiszteletbe kell tartani, és figyelembe kell venni azt a környezetet, amit vezérelsz. Van motor időállandó, átviteli függvény, gyorsulás, felbontás, gépmerevség.... Ezek mint írtam elsőbbrendű szepontok, megelőzik a programot, a programnak kell alkalmazkodni ezekhez.
Ha nem vagy kellően "alázatos, és tiszetelettudó", akkor annak nem lesz jó vége (persze a monitor mindent elbír). Azaz a CNC egész rendszerét, műszaki paramétereit eredőként figyelni kell programozáskor, és olyan vezérlőjeleket kell a programnak kiadni, ami végre is hajtható 1000 %-osan, és a lehető legnagyobb pontossággal.
Így aztán hiába nem mér semmit a program, az ott alkalmazott algortimusok, döntések, utasítások igenis vezérlés esetén is összefüggésben vannak a fizikával, azzal a környezettel, amit működtetsz. Még mondhatnám azt is, vezérlésnél jobban kell figyelni, alkalmazkodni, hiszen a szervó előbb utóbb korrigál, de a step hajtás lépést veszíthet, ami aztán öröklődök, és végzetes a hiba.
De tudod mit? VB döntő van, a CNC megvár minket.:)

Előzmény: n/a (inaktív), 2014-07-13 21:20:00 [494]

Még azt elfelejtettem leírni, hogy ha a szoftver elkészül, akkor tervbe vettük, hogy fejlesztünk egy zárt hurkú szabályzókört is, hogy a nagyipari ipari felhasználókra is gondoljunk.
Ehhez végülis csak a hardver-t kell megváltoztatni, a szoftver szempontjából nem sok változtatás kell. És akkor mehet majd az encoderes mérőléces visszacsatolás és az analog +-10V-os szervo meghajtás is. Majd persze meglátjuk milyen ütemben haladunk, de ez is szerepel a nem túl távoli tervek közt...

Előzmény: csg67, 2014-07-13 19:17:00 [481]

A gépek méretezése nagyon fontos dolog, egyet is kell értenem azzal a szemlélettel, hogy felesleges kilowattos motorokat tenni egy pincurka gépre, hogy aztán hangsebességgel száguldjon.
Én is méreteztem már nem egy hajtásláncot, pontosan tudom, hogy mekkorát lehet tévedni, ha az ember számolás nélkül ugrik neki...

Egyébként reszelni én is szeretek, nade minek verjük be a szöget kőbunkóval, ha közben feltalálták a kalapácsot?

Előzmény: Törölt felhasználó, 2014-07-13 20:59:00 [493]

Az idézett mondatot szó szerint értettem, vagyis, hogy a szoftver nem mér semmit, így valóban semmit nem tud a fizikai dolgokról. Ezzel is arra szerettem volna utalni, hogy vezérlésről beszélünk, nem szabályzásról.
Szóval ez nem az én szemléletem, csupán egy tény.

Előzmény: Törölt felhasználó, 2014-07-13 20:59:00 [493]

"A vezérlőszoftver oldalnak vajmi kevés köze van a fizikához, hiszen nem szabályzókörről beszélünk, így a szoftver mit sem tud a fizika törvényeiről. "

Ez a Te véleményed, de nem helyes szerintem.
Hiányzik belőle a mechatronikai rendszerszemlélet. Nem öncélúan programozunk...
Ezért írhattál olyat, amire reagáltam, hiszen ez a mondatod így nem igaz: "így nincsen az említett lemaradás és a kör sugara éppen akkora lesz mint amekkorát programoztál."

Azt gondolná az ember a vezérlés vagy szabályzás az úr. Te nagyon így gondolkodsz, mert a programozásra koncentrálsz. De mint írtam vannak nagyobb, és fontosabb tényezők, amik a gép eredő pontosságát a programtól függetlenül is meghatározzák, és prioritásuk van, azaz csak a "szoftveres gondolkodás" ide nem elég, és helytelen is.
Az egyik ilyen legfontosabb tényező a mechanikai áttétel. Úgy kell megtervezni a hajtásmechanikát, hogy az vasba öntve maximális gyorsulási képességet biztosítson, azaz minél dinamikusabb legyen.
Ezért pofázok itt már vagy 6 éve a megfelelő optimális áttételezésről, 1 fordulatra eső elmozdulásról, akár léptetős, akár szervós.
Ez minden CNC gépre, technológiára más és más.
Ha itt valaki nagyon elrontja, semilyen szoftver legyen az vezérlő vagy szabályzó már alig tud ezen javítani.
Csak ma olyan világot élünk, hogy a monitort bámulja nép, és megvezetik alaposan, abban hisznek, amit látnak ott szép díszletek közepett jó drága X gigás alaplapokon félévente változó op. rendszerek bűvöletében. Tisztelet a kivételnek.
Félre értés ne essék: én drukkolok, és gratulálok Nektek ehhez a vezérlő fejlesztéshez, én is sokat szenvedtem a saját CNC vezérlő programom írása kapcsán, csak én reszelni is imádok, és ennek bevillanásával, figyelembevételével ütök le minden karaktert programozáskor.

Előzmény: n/a (inaktív), 2014-07-13 17:02:00 [473]

Mi a legjobb megoldás ? Vagy olyan nincs is ?

Szerintem azt akarta elmagyarázni, hogy miért nem lehet nulla hibával követni a körfüggvény által definiált ívet. Na de valóban ennek az UCCNC-hez nem igazán van köze, mivel ahogy már párszor utaltam rá, ez a program nem szabályoz, hanem vezérel.

Előzmény: svejk, 2014-07-13 20:29:00 [490]

Szépen leírtad a szervo vagy komplett mozgásvezérlő működését, visszacsatolásait de hogy ennek mi köze az UCCNC szoftverhez?

Főleg azon a szinten, hogy miként valósítja meg a szoftver körinterpolációt és miként adja ki a Step jeleket G61 esetében.
Mert ugye a #449-ben innen indult el a dolog.

Előzmény: csg67, 2014-07-13 19:17:00 [481]

Hát igen, pedig milyen szép, változatos nyelv a Magyar. Angolul meg csak controller, aztán találd ki, hogy most az pontosan mit is csinál.

Előzmény: csg67, 2014-07-13 19:41:00 [487]

Jaja, de végülis a szabályzó bemenetét írtad, én olvastam félre, így ok az, hogy arányos félreolvastam...

Előzmény: csg67, 2014-07-13 19:36:00 [486]

"Nyílt hurok = vezérlés, nem szabályzás. Eleve a szoftver neve is "vezérlő" és nem "szabályzó"."
Igaz.
De még sosem olvastam azt egy gépkönyvben, hogy a gépen CNC szabályzó van.

Előzmény: n/a (inaktív), 2014-07-13 19:31:00 [482]

Persze, mindig kell egy I tag is, de próbáltam úgy leírni a folyamatot, hogy közérthető, szemléletes legyen.

Előzmény: n/a (inaktív), 2014-07-13 19:33:00 [484]

bocs, most én olvastam félre, igazad van...

Előzmény: n/a (inaktív), 2014-07-13 19:33:00 [484]

Részleges igazságokat írsz.

"Ha eltérés van, akkor az eltéréssel arányos feszültséget küld a hajtások bemenetére (általában a hajtások +/-10V-os alapjellel vezérelhetőek és úgy szokás beállítani a vezérlést, hogy a motor névleges fordulatszámához 9V-os alapjel tartozzon - ez lesz a gyorsjárat), ettől kezd el forogni a motor és próbál egyensúlyi helyzetbe kerülni a rendszer. Ezért van az is, hogy egy álló szervó tengellyel lehet "birkózni": ha megpróbálod kitéríteni az egyensúlyi helyzetből, akkor a szabályozás visszahúzza oda."

Igen, ha egy egyszerű P szabályzóval próbálunk meg szabályozni akkor ez akár igaz is lenne. Nade ugyebár P szabályzó önállóan sohasem stabil....

Előzmény: csg67, 2014-07-13 19:17:00 [481]

Már régen kiderült, hogy egyik szabályozási mód sem tökéletes, a kérdés mindig az, hogy melyik kínál kielégítő megoldást az adott gépen...

Előzmény: elektron, 2014-07-13 15:58:00 [465]

Nyílt hurok = vezérlés, nem szabályzás. Eleve a szoftver neve is "vezérlő" és nem "szabályzó".

Előzmény: csg67, 2014-07-13 19:17:00 [481]

"a körívnél arra gondolsz amit most le is írtál, hogy végül is a G2/3 kódot is a vezérlőszoftver egyenesekből rakja össze."
Ha van pozíció visszacsatolás (minden ipari CNC így működik), akkor:
A vezérlés generálja az adott időpillanatban érvényes névleges pozíciót. Mivel a vezérlésnek fix ciklusideje van amivel a pálya névleges pontjait időről időre generálja (jellemzően néhány ms), ezért a sebesség abból adódik, hogy az egyes pontok milyen messze vannak egymástól. Amikor kört generál, akkor a kör egyes kerületi pontjai lesznek a névleges pozíciók. Minél nagyobb sebességgel kell a pályán haladni, annál messzebb lesznek a pontok kijelölve (ebből már látszik, hogy a pálya névleges pontjainak távolsága a sebességtől és a vezérlés ciklusidejétől függ). Miből állítja elő a vezérlés a hajtások alapjelét? Összehasonlítja a névleges (pillanatnyi pozíciót) a mérőrendszerről jövő aktuális pozícióval. Ha eltérés van, akkor az eltéréssel arányos feszültséget küld a hajtások bemenetére (általában a hajtások +/-10V-os alapjellel vezérelhetőek és úgy szokás beállítani a vezérlést, hogy a motor névleges fordulatszámához 9V-os alapjel tartozzon - ez lesz a gyorsjárat), ettől kezd el forogni a motor és próbál egyensúlyi helyzetbe kerülni a rendszer. Ezért van az is, hogy egy álló szervó tengellyel lehet "birkózni": ha megpróbálod kitéríteni az egyensúlyi helyzetből, akkor a szabályozás visszahúzza oda.

"Egyébként a sebesség előrecsatolás megtalálható az összes gyári step-dir-es vagy analóg szervo vezérlőn, mint állítható paraméter.
Jótékony hatását is tapasztaltam már, de azt nem tudtam hogy pont a körívek problémája keltette életre létét."
A sebesség előrecsatolás végül is egyszerűnek látszik, mivel a lemaradás nem más, mint a sebesség és a körerősítés szorzata, mind a kettőt ismeri a vezérlés és ki is tudja számítani és hozzá is tudja adni a kiszámított elméleti pozícióhoz. Sajnos a probléma -mint mindig- a részletekben van. Eddig minden esetben egyenletes sebességről beszéltem, ahol nincs gyorsulás. Gyorsuláskor már nem ilyen egyszerű a helyzet, könnyen túlléphetőek a rendszer korlátai (nincs elég teljesítménye a hajtásnak a kiadódó sebességváltozáshoz, illetve a rendszer gerjedésre hajlamos lesz), ezért nem lehet egyszerűen megvalósítani ezt a szabályozási módot (ezért is nem lehet ennek a hajtásban a helye). A sebesség előrecsatolást csak részben a kör alakhűsége hívta életre. A fő probléma az 5 tengelyes megmunkálás. Ha a körtengelyek szervó lemaradással dolgoznak, akkor adott sebesség mellett adott szöghibával követik a parancsot. Ha egy ilyen körasztalra felfogunk egy munkadarabot, akkor a pályahiba már nem csak a sebességgel (és a körerősítéssel) lesz arányos, hanem attól is függ, hogy a körtengely középpontjától milyen távol van. Ezért van az, hogy szervó lemaradásos CNC vezérlővel reménytelen dolog (nagy és/vagy gyors) 5 tengelyes gépet működtetni.

Előzmény: svejk, 2014-07-13 15:55:00 [464]

Sorozatosan visszatérő hiba... Megint megfeledkeztek a nyílthurkú szabályozásról.

Ja még annyit és itt tényleg befejeztem, hogy továbbra is várom frappáns megfogalmazásodat, ha már ennyire értesz hozzá.

Előzmény: csg67, 2014-07-13 18:37:00 [477]

Szerintem ne fárasszuk egymást, látom, hogy csak a kötekedni szeretnél, erre én nem vagyok vevő. Ezen a ponton befejeztem a veled való társalgást, van jobb dolgom is ennél.

Előzmény: csg67, 2014-07-13 18:37:00 [477]

Akkor utoljára a leírásról: "Ebben az üzemmódban a programozott és a valóságos út megegyezik, a pályakövetési hiba 0." Ha valóban nincs pozíció visszacsatolás a rendszerben, akkor hogyan beszélhetünk valóságos pályáról?
Esetleg a leírás első oldalán meg lehetne említeni, hogy ez egy olyan rendszerről szól, ahol nincs pozíció szabályozó hurok. Akkor persze nem is olvastam volna bele...

Előzmény: n/a (inaktív), 2014-07-13 17:57:00 [476]

Szuper, ebben az esetben Tibor programjánál szabályzásról beszélhetünk és ha mi is ezt csinálnánk, akkor a felvetés is jogos volna és már javítanám is a dokumentációt. De mi nem szabályzóprogramot írunk, hanem vezérlőt.

Előzmény: elektron, 2014-07-13 17:13:00 [475]

Az elég ha te tökéletesen kiadod az ideális jelet, majd Tibor45 ezt puffereli és kiszámolja, hogy a hozzákötött szervó motorjának milyen megfelelő PWM jelet adjon, hogy az időben előre ismert pálya szerint a legtökéletesebben működjön.

Előzmény: n/a (inaktív), 2014-07-13 17:02:00 [473]

A léptetőmotort idealizáltam abból a célból, hogy csg67-nek eltudjam magyarázni, hogy mire gondolok. Enélkül nehéz lett volna megfogalmazni azt, hogy pontosan mire is gondolok, de konkrétan arra gondoltam, hogy ha nincsen külső szabályzóhurok akkor az amit leírt nem fedi a valóságot ezt egy idealizált léptetőmotoros vezérléssel tudtam talán legjobban megfogalmazni.

Előzmény: Törölt felhasználó, 2014-07-13 16:51:00 [471]

Neked is azt tudom mondani, hogy a vezérlő szoftverről beszélünk, nem a fizika törvényeiről.
A vezérlőszoftver oldalnak vajmi kevés köze van a fizikához, hiszen nem szabályzókörről beszélünk, így a szoftver mit sem tud a fizika törvényeiről.

Azért nagyon kíváncsi lennék, ha már ennyire sok hozzászólás érkezett ebben a témában, hogy ti hogyan fogalmaznátok meg az exact stop módot, úgy, hogy az ne legyen egy konkrét vezérlőtípusra vonatkoztatva. Gondolok itt egy általános megfogalmazásra. Csak mert ha belekeverünk a vezérlőprogramon kívül álló dolgokat, akkor általánosan nem megfogalmazható dolog ez szerintem, túl sok az ismeretlen az egyenletben...

Előzmény: Törölt felhasználó, 2014-07-13 16:51:00 [471]

Meg sem fordult a fejemben az ellenkezője, csupán válaszoltam az észrevételre. Próbáltam elmagyarázni, hogy miért téved, remélem sikerült érthetően leírnom és eloszlatni a félreértést.

A szoftvert irogatjuk teljes gőzzel, hamarosan elkészül a G90/G91 is.

Előzmény: svejk, 2014-07-13 16:46:00 [470]

"Mert mi van például ha valaki léptetőmotorokkal használja a gépet (ha már ennyire leragadtál a konkrétumoknál és ha nem tudsz elvonatkoztatni).
Ez esetben az összes dolog amiket leírtál máris nem állja meg a helyét, mivel a léptetőmotoros vezérlés nem szabályzás,
így nincsen az említett lemaradás és a kör sugara éppen akkora lesz mint amekkorát programoztál."
Bocs, de a léptető motor mióta nulla hibával lépkedő szerkezet? Csinálj csak pár egységugrás tesztet velük... Dinamikailag hajtástechnikai méretezéskor sajnos itt is tehetetlen tömegekkel kell számolni, így aztán
időállandója van neki is. Azaz túllendülések, lemaradások, rezonanciák jellemzik ezt a motor típust is.
Durván azt is lehet mondani, a csicsavilág képernyő egy dolog, a valóság pedig mindig más, így csg67 felvetései nagyon is jogosak.

Előzmény: n/a (inaktív), 2014-07-13 16:27:00 [467]

Persze-persze, csak írjátok minél nagyobb gőzzel!

Csg67-nek csak szúrta a szemét egy dolog...
Egyébként nagy tudású nagyon rendes ember.

Előzmény: n/a (inaktív), 2014-07-13 16:40:00 [469]

Nagyipari gépeknél általában eleve szabályzás van, van visszacsatolás a vezérlőszoftver felé, ha ilyet fejlesztenénk, akkor csg67-nek igaza lenne, de mi nem folyamatszabályzó szoftvert írunk, csak egy vezérlőt.

Előzmény: svejk, 2014-07-13 16:00:00 [466]

Még annyit, hogy nem engem nem érdekel a gép.
Viszont az, hogy a szervóid mekkora és milyen mértékű hibát visznek a rendszerbe az a szervoidnak a dolga. A szoftver nem szabályoz, csupán vezérel. És exact stop módban ezt 0 hibával teszi.

Előzmény: csg67, 2014-07-13 15:23:00 [463]

A leírás nem idealizált, a leírás konkretizált a vezérlőszoftver algoritmusát tárgyalja.

A probléma ott van, hogy te viszont nem a vezérlő szoftverről, hanem egy konkrét meghajtóelektronika típusról beszélsz mégpedig szervo elektronikáról,
pozíció szabályzásról, aminek a működése valóban olyan, ahogy leírtad.
Megint csak azt tudom mondani, hogy a leírásnak köze sincs a szervo rendszerhez, ez egy vezérlőszoftver leírása.

Mert mi van például ha valaki léptetőmotorokkal használja a gépet (ha már ennyire leragadtál a konkrétumoknál és ha nem tudsz elvonatkoztatni).
Ez esetben az összes dolog amiket leírtál máris nem állja meg a helyét, mivel a léptetőmotoros vezérlés nem szabályzás,
így nincsen az említett lemaradás és a kör sugara éppen akkora lesz mint amekkorát programoztál.

A vezérlőelektronikák sokszínűsége miatt nincsen értelme a szoftver leírásában ezeket tárgyalni,
azokat megteszi majd a vezérlőelektronika gyártója.

"De ez már nem az én problémám lesz... "

Az bizonyos, hogy neked aligha lehet szükséged mondjuk UCCNC mozgásvezérlőre.

Nekünk hobbistáknak ha már nem csinál szarvashibákat, akkor már jó...
A munkadarabok zöme relief szerű darabok, a mechanikák szintén elnyomó többsége jó ha tizeden belüli pontosságú.

Előzmény: csg67, 2014-07-13 15:23:00 [463]

A végén kiderül hogy egyik program se jó, ne is használjuk ? Nem hinném, az adott felbontás mellett és gyorsulás sebesség és a step dir rendszeren belül lehető legpontosabb időzítéssel kiadott léptetési jelsorozattól jobbat mit vártok ?

Sziesztám ideje alatt rájöttem, hogy bizony a körívnél arra gondolsz amit most le is írtál, hogy végül is a G2/3 kódot is a vezérlőszoftver egyenesekből rakja össze.

Nem ismerem sem a szóbelei UCCNC szoftver, sem a gyári mozgásvezérlők lelki világát, bonyolult interpolációs képleteit nem is értenék belőle sokat.
De elméletileg talán elképzelhető lenne az is, hogy nem a körív apró húrjain vezeti a vezérlő a gépet hanem mondjuk szelőkön és azok metszéspontjain, így már a sokszög által keltett kör átmérője jobban igazodik a valósághoz. De ehhez meg még több részre kellene felbontani a kört, azaz még több számolást igényel.
(ha jól rémlik a gyári vezérlőkön van ilyen paraméter, hogy az adott kört milyen pontossággal kövesse le)

Egyébként a sebesség előrecsatolás megtalálható az összes gyári step-dir-es vagy analóg szervo vezérlőn, mint állítható paraméter.
Jótékony hatását is tapasztaltam már, de azt nem tudtam hogy pont a körívek problémája keltette életre létét.

Előzmény: csg67, 2014-07-13 13:49:00 [460]

Elég furcsa hozzáállás egy vezérlő szoftver írójától arra hivatkozni, hogy őt nem érdekli a gép, amit a szoftvere vezérel. Egy idealizált leírás pedig semmit sem ér annak aki használni is akarja azt. De ez már nem az én problémám lesz...

Előzmény: n/a (inaktív), 2014-07-13 14:15:00 [461]

Modbus kommunikációt tud az UCCNC program? illetve plazmánál kezeli a THC-t?

Nagyon szépen leírtad a dolgokat és mindez amit leírtál nagyjából, kisebb fenntartásokkal így is van.
Én mindössze annyit mondtam, mondok, hogy a szoftver, a pályatervező szempontjából a pályakövetési hiba exact stop mód esetén nulla.
Felesleges idekeverni, hogy mit csinál az elektronika, mit csinálnak a motorok, mert nem erről szól ez a leírás.
A leírás a pályatervezőről beszél, sohasem motorokról vagy netán tengelyekről. Te konkretizált esetekről, megvalósításról beszélsz, de a leírás nem erről szól, hanem a pályatervezőről, arról, hogy mit kalkulál és hogyan.

A constant velocity mód pedig nem úgy működik ahogy leírtad, mégcsak idealizált esetben sem. Ha van rá igény akkor a későbbiekben leírom majd a működését, de most mennem kell...

Előzmény: csg67, 2014-07-13 13:49:00 [460]

A problémának semmi köze a kontúrmaráshoz (egyébként sem a szerszámátmérővel, csak a szerszám sugarával kell korrigálni a pályát). De mint mondtam ennek semmi köze az alapproblémához.

Nézzük meg, hogy mit csinál az "Exact Stop"! Ahogyan a neve is mondja; pontosan áll meg. A pozíciók a mondat végén, de CSAK A VÉGÉN lesznek pontosak! Hogyan valósítja ezt meg (ez) a vezérlő (is)? Nagyon egyszerűen; nem indítja el a következő mozgást addig, amíg az aktuális mozgás be nem ért a programozott végpontba (nyilván van egy pozícióablak, amin belül elfogadja az aktuális pozíciót névleges pozíciónak). Amikor ez megtörtént, akkor mehet tovább a megmunkálás, indulhat a következő mondat... Persze ennek tényleg az az eredménye, hogy minden mozgásnál gyorsít, lassít, megáll. Idegesítően "rángat" a gép megmunkálás közben. Mire jó mégis ez a lehetőség? Például pontosan meg tudjuk munkálni egy üreg belső sarkait (természetesen nem lesz sarkos, hiszen a szerszám sugara nem nulla).
Mi történik akkor, ha a "Constans Velocity" az aktív? Egyszerűen nem várja meg a vezérlés azt, hogy a mondat végén beérjen a tengely a programozott pozícióba, hanem indítja a következő mozgást. A hajtások meg követik úgy, ahogy tudják a pályát.
Ez a vezérlés a követési hibára épül (following error, servo lag), azaz azért mozognak a tengelyek, mert a vezérlés által számított (névleges) pozíció nem egyezik meg a mérőrendszerrel mért (aktuális) pozícióval. Minél nagyobb az eltérés (követési hiba), annál nagyobb a sebesség. A követési hiba a sebességgel arányos, az arányosítási tényezőt szokás a pozíciószabályozás körerősítésének (kv faktor) hívni. Azaz a lemaradás a sebességtől és a szabályozási hurok erősítésétől függ. Az erősítést nem lehet büntetlenül növelni, mert egy idő után a rendszer gerjedni, remegni kezd.
Tehát elmondhatjuk, hogy minden mozgás lemaradással valósul meg. Persze a végpontban lehet pontos a pozíció, ha ott megáll a tengely. Mi történik mozgás közben? A tengely (a sebességgel arányos) lemaradással követi az elméleti pozíciót. Ez nem gond, ha egyszerre csak egy tengely mozog (ugyan nincs ott még a tengely ahol lenni kéne az adott időpillanatban, de előbb-utóbb végigmegy a pályán). Mi a helyzet több tengellyel megvalósított egyenes mentén történő elmozdulásnál (térbeli egyenes)? Ha a tengelyeken az erősítés egyforma (minden tengely azonos sebesség mellett egyforma lemaradással mozog), akkor szintén az elméleti pályát fogja követni. Mi a helyzet a körnél? A szánok itt is az aktuális pozícióból az elméleti pozíció felé mozdulnak el. Ez minden esetben egy húr mentén történik, azaz a körön belül. Ezért lesz kisebb a valós körív az elméleti pozíciókkal megadottól. A köríven folyamatosan mozog a szerszám, nincs minden egyes elméleti pontnál "Exact Stop". Mennyivel lesz kisebb a valós pálya sugara az elméletitől? Ez függ a követési hibától, azaz a sebességtől (mivel ezek egyenes arányban vannak), és függ a körív sugarától (a két elméleti pontot a köríven egy húr köti össze, a húr hossza függ a sebességtől, de minél kisebb a körív sugara, az adott hosszúságú húr annál közelebb lesz a kör középpontjához, azaz annál nagyobb lesz a kontúrhiba).
A fentiekből látható, hogy ennél a vezérlésnél ez minden esetben fennáll, csak a mértéke kérdéses.

Persze létezik erre is megoldás (lásd a velocity feedforward control kifejezést a gugliban). Egy ilyen vezérlésnél valóban le lehet írni, hogy a "pályakövetési hiba 0". Ráadásul a "velocity feedforward" nem a motor és a hajtás dolga, hanem a pozíció szabályozó körbe lehet beépíteni, azaz a szoftver a felelős érte (ezért a szoftver leírásában a helye CNCdrive1 állításával ellentétben)! Ezért bátorkodtam (bár lehet, hogy egy kicsit sértően - ezért elnézést kérek) erre a félrevezető mondatra felhívni a figyelmet.

Maradok tisztelettel őszinte csodálója a hobbistáknak.

Előzmény: svejk, 2014-07-13 11:54:00 [454]

Az már extra lenne, és szerintem egy nagyobb kódnál igen csak elmolyolna vele mire kiszámolná.

Előzmény: Farkas Attila, 2014-07-13 13:07:00 [458]