UCCNC vezérlő program

[kaqkk007]

Ha felrakok két fejet (maró-lézer) egymás után használhatom őket más beállítással , vagy akár a két külön gépet is egy egy szalagkábellel rá lehet kötni egy vezérlőre ..

[ANTAL GÁBOR]

Szerintem nem érted hogy mit akart sugallni Miki2 .  Minek a szerszámsugár korrekció a lézehez ? és minek a THC kontroll az esztergához ?  nem kell a szinkron menet a plazmához stb  Pont az a baj hogy elkészül valami és elromlik egy másik jól működő rész ." Van egy régi közmondás : aki sokat markol az keveset fog "

Szerintem is szét kellene szedni és akkor az egyes részek kifogástalanul fognak működni .  Az hogy hogyan lesz a licensz díj megállapítva az tisztán közgazdasági számítás.    Pl most veszek egyet és lézerezhetek, plazmázhatok esztergálhatok ,marózhatok .  Miért nem lehetne ugyanígy a jövőben is ?.  Csak azt fogom betölteni ami nekem kell. Balázséknak nem csökken a jövedelmük csak a munkájuk

[kaqkk007]

Akkor tényleg nem értem , ezt most is meg tudod csinálni , hogy csinálsz  x + 1 profilt és azt indítod el amelyik kell . Miért szednéd szét 5-6 külön programra ??

[Miki2]

Az előző hozzászólásban Antal Gábor pontosan leírta az ötlet értelmét.

[ANTAL GÁBOR]

Persze de minden egyben van  . Pont ez a bajok forrása  . Bele sem kell (alapból ) tenni ami nem kell, és akkor amikor fejlesztik  (pl a G42 ) akkor nem fog elromolni más   ( mert nem is használ G42 t) )  Az előzőleg leírtak szerint minek a plazmához a szinkron menet lehetősége  ?  ( ami 1.5 évig hibásan működött az egész világon  és most talán sikerült kijavítani Balázséknak ( mert végre elhitték hogy igazat állítok )


 Amit írok az példa   de én rendszeresen konzultálok Dezsoe vel és sokat bosszankodom ( utoljára a config változtatásaim mentése nem sikerült ha túl sokat állítgattam , de a soft újraindítás megoldotta , a korábbi verziónál nem volt ilyen hiba  Win 10 es a gépem  )
Vagyis egy egy új funkció bevezetése elrontja a régi jól működő dolgokat . Most a G41 ,G42 ( és még sok más az új  ) ami nem is kell mindenhová a korábbiak szerint  . Én nem vagyok híve : a" merjünk nagyot álmodni szlogennek ". Kis ( és biztos ) lépésekkel előbbre lehet jutni

[000000000]

A probléma már ott elkezdődik, amit már egyszer megemlítettem. Neveztesen a forgó és lineáris tengelyek setup ablakai azonosak. Innentől kezdve a pályamenti előtolási sebesség valódisága erősen kérdéses.

[Béni]

A vegyes interpoláción a lineáris és forgó tengelyek egy mondatban programozott szinkron mozgását értem. A példát pedig az 5168-ban hozott két programmondatra értettem.

[Béni]

Nem gondolom, hogy a konfigurációs ablak szövegei kihatással lennének a működésre. Mivel az A B és C jelölésű tengely lineárisként is használható, valamint a Units és a Units/min félreérthetetlenül értelmezhető minden mértékrendszerben, ebben nem látok valós problémát.
A "pályameneti előtolási sebesség" számítása forgó tengely és említésre méltó fogásmélység esetén már ki kell hogy térjen a szerszám minimális és maximális bemerülő részén adódó sebesség eltérésének kezelésére. (A felhasználó választására bízva.) De ez nem vezérlő oldali, hanem programozási feladat.

[000000000]

Tudtommal a jobbsodrású CNC koordinátarendszerben  az X, Y, Z, A, B, C kódok meghatározottan, egymással összefüggően 3 lineáris, és 3 forgó tengelyt jelent.
Az "units" túl általános, és a lineáris mozgásra mások az elmozdulás és sebesség mértékegységek, mint a körmozgásra.

De legye itt egy példa:

G90
G0 X0 Y0 A0 B0
G1 F600 X100 Y100 A200 B200

Kérdések:
Mit jelent itt a programban és mit a valóságban az F600? Mi ennek ilyenkor a mértékegysége?

[Béni]

Nincs kőbe vésve, azaz nem kötelező a tengelyek jelölése és viszonya sem. Csak praktikus, mert elterjedt.
"Units" pont azért jó, mert általános. Mi baj van a behelyettesítés utáni "mm/min", "deg/min" vagy "foot/min"-el?
(A tárgybéli programnak már talán a földön kívül is vannak felhasználói. Rájuk is kell gondolni!) [#alien]

Én értem a vegyes interpoláció előtolás problémáját és azt is, hogyan oldják fel ezt azok a vezérlőprogramok, amelyek szimultán 4 és több tengelyes interpolálásra képesek. (Inverse time feed.)
Az [5169] béli kérdésem gyakorlatilag ugyanaz, mit a tiéd.

[dezsoe]

Igaz, hogy nem nekem szólt a kérdés, de megpróbálok több mint 3 évtized programozással a hátam mögött válaszolni a felvetésedre (illetve, felvetésetekre, Gáborral együtt). Mivel a szétdarabolt program jelentős része továbbra is ugyanarra a kódbázisra épülne, csak egy-egy részlet kimaradna, ugyanúgy együtt kéne fejleszteni, javítani. Ha kiderül valami probléma, akkor az összes verziót lehetne javítani. Ez semmilyen előnnyel nem járna, viszont cserébe mindent lehetne több példányban csinálni, ami maga az exponenciális szopásfaktor.

Az például, hogy itt a fórumon nem sokan használnak G42-t, egyáltalán nem jelenti azt, hogy mások sem használják. Amióta folyamatosan olvasom a többi UCCNC-s fórumot is, állandóan téma és nagyon várták már. Amelyik funkcióra nincs szükséged, azt nem használod, és meg is van oldva. (Két kocsid van: az egyikben anyósülés, a másikban meg csomagtartó van?

A menetvágás hibáját Gábor felfedezte, de nehéz volt reprodukálni, így nehéz volt javítani is. Az egy másik kérdés, hogy kiderült, hogy más is küzd vele, ráadásul gyorsabban tudja előhozni a hibát, mint Gábor. De akkor miért nem szól, hogy valami bibi van? (Ezen a fórumon felhasználó.)

A változással (fejlődéssel!) semmi baj nincs, ez a normális. Ha valami nem sikerül, az bizony előfordul, ha dolgozik az ember. Pont erre valók a teszt verziók, hogy ezek kiderüljenek. Azért a hivatalos verziókban nem nagyon szokott hiba maradni, szerintem.

[ANTAL GÁBOR]

Értek én a szóból , és a javaslatom pont azt célozta hogy kevesebb legyen  a munkátok .

[zt2c4wh9]

Én teljesen másképp látom ezt a dolgot. Szerintem a program szétszedése részekre csinálna nekünk sokkal több munkát és jelentősen több problémát.
Gondolj bele, hogy ha mondjuk 3 helyen különböző dolgokat fejlesztenénk, azzal mennyire lenne átláthatóbb az egész rendszer a fejlesztőknek, szerintem sokkal kevésbé látnánk át egy idő után.
Így, hogy egy közös kód mag van így egyszerű átlátni a fejlesztést és szinkronban tartani az API-t és magát a programot.

Az pedig hogy valami elromlik kiszokott derülni még a teszt kiadásoknál, ahogy most is, éppen ezért csinálunk teszt kiadásokat.

A szétválasztást én a különböző képernyőszettekben látom. Például ha nincs szükséged valamire akkor le lehet szedni a képernyőről például a port/pin-jeit és máris nem lehet konfigurálni.

Az igaz, hogy G-kód szinten már más a helyzet, de ha nincs szükséged a G42-re akkor nem kapcsolod be. Az hogy most éppen emiatt elromlott valami az sajnos benne van a pakliban, mert csak az nem hibázik aki nem dolgozik, de ahogy írtam fentebb ezért adjuk ki teszt verzióban ezeket és várunk bizonyos ideig hogy kiderüljenek ha vannak hibák mielőtt kiraknánk az adott verziót hivatalos kiadásba.

[zt2c4wh9]

Szia Miki,

Köszönöm az ötletet, de ahogy leírtam Gábornak is az előző válaszomban én nem látom ezt annyira jó ötletnek, mert sokkal több munkánk lenne vele.
Nem véletlen van a Mach3-nak is egy mag programja és külön képernyőszettjei a különböző gépfajtákhoz.
Így nekünk jóval egyszerűbb és gyorsabb és problémamentesebb a fejlesztés.

[zt2c4wh9]

Az UCCNC nem ismeri a forgó tengelyeket.
Ha használtad, nézted a programot akkor láthattad, hogy nincsen benne forgó tengely opció egyelőre.
Ahhoz, hogy forgó tengelyt is tudjon kezelni, ahhoz másfajta számítás kell, illetve némileg a gép kinematikáját is ismernie kéne a programnak (a legtöbb esetben).
Ezt az UCCNC jelenleg nem tudja, nincsen benne ilyen opció.
A pozicionált tengelyeket mindig lineárisnak tekinti.

Viszont Svejk átmeneti pozíció hibát írt és nem sebesség hibát, ezért nem értettem a kérdésedet.

Úgy tudom, hogy mintha a LinuxCNC-ben lehetne kinematikát programozni. Nem vagyok benne 100%-ig biztos, de mintha azt olvastam volna valamikor. Szóval ha ilyenre van szükséged akkor próbáld meg LinuxCNC-vel, talán az tudja kezelni úgy ahogy szeretnéd.