UCCNC vezérlő program

[ium8w94xp]

Elküldtem....köszi.

[ium8w94xp]

Megnéztem a g kódom másik programban, az rendesen végig csinálja. Balázséknak is elküldöm.

[ium8w94xp]

2037-es is rosszul csinálja

[dezsoe]

Na, csak eljutottam odáig, hogy végignézzem.

A helyzet az, hogy minden jó, csak mégsem. A pálya attól rossz, hogy a program jó. Nem, nem ittam semmi töményet. A következő történik:

A 68-as sor (G2 X289.385 Y290.9629 I192.3902 J-64.5029) hatására az X 289.3840, az Y 290.9640 lesz. Bár a kódban más értékek vannak, a kijelzőn a tényleges koordináták jelennek meg, és ezzel is számol a program. A tényleges és a programozott koordináta csak és kizárólag akkor lehet azonos, ha a programozott koordináta osztható a tengelyre előírt lépéssel, azaz egész számú lépést kell végrehajtania az adott koordináta eléréséhez. Mivel ez elég ritka, ezért két lehetőség adódik: vagy kiírod a tényleges koordinátát, ami többé-kevésbé az lesz, amit a g-kód előírt, vagy kiírod a g-kódban kért koordinátát, ami nem felel meg a valóságnak, de nagyon jól mutat. Az UCCNC az első verziót választja: a koordináták megjelenítése a ténylegesen megtett lépések száma alapján történik.

És itt el is érkeztünk a problémához, ugyanis a következő sorban (G2 Y290.9631 I186.8722 J-79.0784) a következő mozgást írja elő a kód: menj egy köríven a jelenlegi (289.3840, 290.9640) pontból (+186.8722, -79.0784) középponttal (289.3840, 290.9631) pontig. (Itt azt kell észrevenni, hogy a parancsban nem volt X, tehát az az éppen aktuális lesz, a középpont pedig relatív: az aktuális X és Y koordinátákhoz kell hozzáadni, de most mindkét dolog lényegtelen.)

Egymás mellé írom, hogy jól látszódjon: (289.3840, 290.9640) ---> (289.3840, 290.9631)! Az X ugyanaz, de az Y végpont KISEBB, mint a kezdőpont! Ezért fog egy teljes kört menni! A G2 előírja, hogy óramutató járása szerinti körívet kell bejárni, és mivel a végpont egy hajszállal a kezdőpont mögött van, ezért teljesen körbe kell mennie. Ha a kezdőpont nem a tényleges koordináta lenne, hanem az átverős, akkor nem lenne semmi gondod, mert egy 0.0003mm hosszú, az említett középponttal rendelkező körívet kéne bejárnia...

Hogy mi a megoldás? Nem tudom. Nem ismerem a CamBam-ot. Ha át lehet állítani a legkisebb szakasz hosszát, akkor jó. Vagy azt, hogy ne köríveket generáljon, hanem csak szakaszokat. Valamelyik (vagy mindkettő) segíthet.

  

[000000000]

"Hogy mi a megoldás? Nem tudom."

Talán az egy megoldás lehetne, hogy az UCCNC ne az adott gép durva hajtás felbontásával számoljon, hanem attól sokkal pontosabban, a kettő közti különbségeket pedig tengelyenként tartsa nyilván egy hiba regiszterben. Hiszen így mint a példa is mutatja egy jó G kód "rosszá válik" a vezérlő program hibás algoritmusa miatt, sőt balesetveszélyes szerszám törés, ütközés következhet be, amikor egy pici ívszakasz helyett betesz egy teljes kört a hibás működése kapcsán.

[ium8w94xp]

Köszönöm a kielégítő kisérletet, tesztet. Érdekes, hogy másik program "rendben" megcsinálja. Bár nem értem dxf-ből hogy sikerült "hibás" gkódot létrehozatnom. Majd másik progiba generálom le. Köszönöm mégegyszer.

[kmajer]

A dxf-ben a vektorok teljesen zártak?

[ium8w94xp]

A kérdés jó, de nem tudom...nem foglalkoztam vele másképp legeneráltam...ahogy Csaba mondta. Nem ívekre bontattam, hanem szakaszokra. Megoldódott.

[dezsoe]

Hümm... [#nemtudom]

Egy napja próbálom megemészteni, amit írtál. Rajtad kívül bárkiről el tudtam volna képzelni, hogy azt javasolja, hogy a program mással számoljon, mint a tényleges pozíció. Pont az ilyen átverésekre szoktál ugrani. No, mindegy, csodálkozom tovább, de addig is elmondom a saját véleményemet.

1. A program helyesen jár el, amikor a tényleges koordinátát jeleníti meg, illetve ezt is tárolja, mint aktuális koordinátát. Én személy szerint nagyon fel lennék háborodva, ha kiderülne, hogy a tudtom nélkül, valami akárhogyan kiszámolt koordinátával dolgozik, miközben mást ír ki. (Egyszerű példa: soronként hajtom végre a kódot. Megnézem, hogy hol áll a gép, tetszik, nyomom a következő sort. Egyszer csak kiderül, hogy nem is azzal számol, amit látok...)

2. A program szintén helyesen jár el, amikor a G2 kezdőpontjának az aktuális koordinátát veszi. Ez a dolga, a szabvány ezt írja elő, ettől G2 a G2.

3. Szerintem a CamBam (vagy a posztprocesszora) csinál hülyeséget, amikor képes egy 0.0003mm hosszú körívet generálni. Értem én, hogy erre is lehet szükség egy csillagvizsgáló tükrének kialakításához, de nem tudom elképzelni, hogy bármi értelme lenne akár még ipari környezetben is. Még a 0.03 csak elmegy, de az két nullával odébb van...

Hogy hasznosat is írjak: kicsit utánaolvastam gyorsan a CamBam-nak. A posztprocesszornak meg lehet mondani, hogy milyen hosszúságú körív alatt generáljon inkább G1-et (Options - Arc To Lines Tolerance). Gondolom, hogy ha itt értelmes, a tengelyen egy lépéshez tartozó távolságnál nagyobb érték van megadva, akkor rögtön használhatóvá válik a rendszer. Sokszor csak annyi a baj, hogy az eredeti paraméterek ángilus mértékegységhez lettek megadva és emberi (értsd: metrikus) környezetben értelmetlenül kis értéket képviselnek.

[000000000]

Hol írtam hogy a kijelzés NE a felbontásból megvalósítható valós koordináta legyen? Sehol! Ez jó a programban, a Robsy CNC vezérlőimben is így van.

Viszont a kijelzés és a számolás két külön dolog, szerintem SÚLYOS  elvi programhiba egybemosni. Gondold végig micsoda durva G kód-tól való veszélyes (ütközés, szerszámtörés) eltéréseket jelent ez (mint az adott példa mutatja), amint egyre kisebb step/mm a gépfelbontás a setup-ban. Ez most így azt jelenti, egy teljesen jó G kód attól függően válik egyre rosszabbá az UCCNC szerint és a te magyarázkodásod szerint, minél hitványabb felbontású a gép felbontása. Ez pedig nyilván nonszensz!

[000000000]

Még egy kiegészítés. A világ, a matematika alapja analóg dolgokon nyugszik, hiába ülünk naphosszat egy vacak digitális PC előtt.
 
Az analóg világban a 0.0003 egy igen nagy számként is értelmezhető, hiszen tőle végtelenül sok és kisebb is van.
A digitális ennek nyilván csak egy része lehet, de olyan algorimusokat kell alkalmaznunk, ami mindig a lehető legjobban közelíti a valóságot, azaz az analóg világot.

[4ybj8h3c8]

Persze. A kvantumszámítógép analogra épül, már amelyik próbálkozás már működik.
A vacak digitális PC, (mint a tiéd, vagy abakuszt rángatsz?) kőkeményen a 0 - 1 páros alapján dolgozik. Ne próbálkozz a TTL vagy CMOS, vagy akármilyen szintek analóg magyarázkodásán, a lényeg az 1 és a 0.

[000000000]

Aztán még ez ugatott le, hogy idióta vagyok mert analóg tachogenerátorral mértem egy analóg bemenetes szkóppal a REZONANCIÁT a léptetős rendszernél !
Miközben ez meg full digitális bohóckodással kábítja a fórumot.
És még Én voltam elhordva mindenféle idiótának !

[000000000]

Hogy jön ez ide? Gondolkozzál már el, súlyos szövegértési, szakmai problémáid vannak, de ez természetes is annál, aki csak kötözködni, "aprítani" jár ide pár haverjával együtt, amikor meglátják a Robsy nick nevet.[#nyes]

[4ybj8h3c8]

"A világ, a matematika alapja analóg dolgokon nyugszik, hiába ülünk naphosszat egy vacak digitális PC előtt."

Az nem az én problémám, ha már arra sem emlékszel amit írtál.