UCCNC vezérlő program

[dezsoe]

Ha nullára húzod, akkor ugyanúgy szakadás-biztos lesz, csak más aktív szinttel.

[dosalaszlo]

Sziasztok,
Ugyanazon kérdéssel fordulnék hozzátok ha jól láttam még nem érkezett rá válasz:
SheetCAM és UCCNC szoftvereket használnék Floating Head-es plazmavágáshoz, mi lenne a legalkalmasabb post processor?

Üdv
László

[dezsoe]

Szia!

Hogy veszed fel a magasságot? A legtöbben a Z home bemenetre szokták kötni a magasság érzékelőt, majd egy G28.1-gyel a Z-n felveszik a referenciát a kellő eltolással.

A legutóbb a "Mach3 THC with scriber.scpost" post módosított változatát láttam használni. A módosítás annyi volt benne, hogy ha használsz THC-t, akkor annak a be- és kikapcsoló parancsát be kell állítani.

Kód Kijelölés Kibont


thcOnCode = " M205"
thcOffCode = " M206"


Még érdekes lehet az alábbi pár sor:

Kód Kijelölés Kibont


--this is the distance between each torch reference in MILLIMETRES
refDistance = 250

--Put your switch offset value here in MILLIMETRES
switchOffset = 1.5


Az első határozza meg, hogy a legutóbbi ref. ponttól milyen messze kell megint mérni, a második az érzékelő eltolását.

[dosalaszlo]

Köszönöm szépen!

[wv07scd6x]

Sziasztok!
Ismételten az "autoleveler" -rel gyűlt meg a bajom a 1.2106 -as verzióban. Nyomtatott áramköri lemezt szerettem volna hosszú pihentetés után ismét kigravírozni. A letapogatási folyamat látszólag végbemegy, de az eredmény mégsem az a gravírozás folyamán amit várok. A vannak részek ahol szépen kimarja a felületet, és vannak részek ahol nem is érinti a lemezt a gravírtű. Megpróbáltam újra egy másik lemezen, és a végeredmény hasonlóképp megint nem az amit vártam volna. Amikor én még megvettem a modult, és letöltöttem a weblapon szereplő UCCNC verziót, akkor is próbáltam már ilyesmit csinálni, és akkor pontosan tartotta a vágási mélységet. Azóta a gépemen nem változott semmi. Vagy van valami zűr ebben a verzióban ami kihathat erre is és azért állt meg a fejlesztés? Mert látom hogy csak egy régebbi verzió csiszolgatása zajlik, ami most az 1.2049 -nél tart. Használjam inkább a 1.2049 -est?

[dezsoe]

Szia!

Haladjunk visszafelé. A fejlesztés egyáltalán nem állt meg. Attól, hogy nincs heti három új teszt verzió, még készülnek dolgok. A 1.21xx sorozat egyelőre teszt verzió, így lehet benne hiba, sőt, van is a 2106-ban, amiről tudunk. Éppen ezért javasoljuk mindig a stabil verziók használatát. (Ha jól tudom, akkor neked UC400ETH-d van, azt pedig nem érinti az említett hiba.)

Már sokszor leírtam, de nem elégszer. Az Autoleveler egy lelkes felhasználó alkotása, ha gond van vele, akkor nála kell érdeklődni. Ennek ellenére gyanús a problémád, mert nem hallottam róla, hogy másnak hasonló gondja lenne. Bár a plugin forrása csak a fejlesztőnél van meg, nagy meglepetések nem várhatók, mert eredetileg egy angol úriember írta, a forrása fent van a neten, én is az alapján írtam a saját szintezőmet.

Esetleg tegyél fel eredeti és az Autoleveler által módosított g-kódot, mert abból sokminden kiderül. Lehet, hogy már a bemenő g-kód sem volt jó, nemrég láthattunk rá példát a Mach3 topikban.

[zt2c4wh9]

Szia,

Nem rémlik, hogy bárki jelzett volna ehhez hasonló problémát.
Nem zajlik a régi verzió csiszolgatása, csupán a teszt verziók még nem jutottak el odáig, hogy hivatalos kiadásba átmenjenek és az UCR201 kézivezérlő pluginját viszont ki kellett adni, ezért készült az 1.2048 és 1.2049 kiadás. Az UCR201 plugint beraktuk és utána még csiszoltunk a pluginon a visszajelzések alapján, ezért lett 2 verzió is egymás után.
Amúgy az 1.2048 és 1.2049 teljesen ugyanaz mint az 1.2047, az egyetlen különbség, hogy belekerült az UCR201 plugin.
 
Illetve volt még egy Windows Defender vírusirtó téves riasztás az 1.2047 verzióra, ezért beleraktunk pár "kamu" kódot az UCCNC.exe-be, amivel megoldódott ez a probléma is, mivel a téves riasztást egy olyan kódrész okozta amit tévesen vírusnak hitt a Defender és azzal, hogy belepakoltunk pár olyan kódot amit amúgy a szoftver nem használ semmire, ezzel megváltoztak a fájlban a bit-ek és bájtok sorrendjei ami miatt ezután már nem fordult elő benne a vírusnak hitt kódrészlet. Persze ez az UCCNC működésén semmit nem változtat, nem történt a működő kódban változás, nem történt fejlesztés...

[3ebj3bk8b]

Sziasztok!

Régóta küzdök azzal, hogy a program az aktuális főorsó fordulatszámot jelezze, ill, hogy tudjam használni a főorsó PWM szabályzást a programból.Egyenlőre még nem működik.

Konfiguráció:
UC300ETH
UCCNC 1.2047
Főorsó Fanuc alpha M9/3000 servo, most egy Fanuc incrementális encoderrel 1024ppr.

A program leírásában a 19-oldalon írja:

Index port és pin: Ez egy fizikai bemenet lábszáma a főorsó fordulatszám érzékelőnek. Ezen a
bemeneten érkező impulzusokból a szoftver kiszámolja a tényleges főorsó fordulatszámot és kijelzi
a SACT DRO-ban. Az index bemenet az encoder index csatornája, ha főorsó szinkron mozgáshoz
(menetvágás) inkrementális jeladó van csatlakoztatva.


A PWM vezérlésnél a  22-ik oldalon meg ezt:

A főorsóhoz egy inkrementális jeladót (encodert) kell csatlakoztatni, aminek az A és B csatorna
jeleit be kell kötni a mozgásvezérlő bemeneteire.
(Megjegyzés: Index csatornás sebesség mérés nem használható ehhez a funkcióhoz, a visszacsatoló
jelet mindenképpen egy inkrementális encoder A és B csatornájának kell szolgáltatnia.)

Nálam egyenlőre az index csatornán csak néha jelenik meg egy impulzus: ide van kötve a Z jele az encodernek.

Az A és B-n van impulzus, az Sact ír fordulatszámot, de köszönő viszonyban sincs az Sset értékkel, és nem is arányosan változik vele.

Kb. 28Khz bemenő frekvenciánál(kb. 1580 ford/perc) az Sact lenullázódik, és nem jelez többet semmit, csak ha lejjebb viszem a fordulatszámot.

Ha az index csatorna jele íródik az Sact DRO-ba, nekem miért van fordulatszám értékem?

28khz környékén miért veszti el a jelet? A diagnosztikai ablakban is a ledek kialszanak.

Miért lehet az, hogy nem arányos a kijelzett Sact a beállított Sset-el?  Pl. Sset 100 ford/perc Sact 250,  Sset 200 ford/perc  Sact 625.

[dezsoe]

Szia!

A bemeneteken levő szűrők miatt nem tudsz túl nagy frekvenciájú jelet bevinni, ezért enkódernek jó a 100-as felbontású is.

A fordulatszám érzékeléséhez csak akkor nem elég az index jel, ha a fordulatszámot zárt hurokban akarod szabályozni. A második idézeted onnan származik, ezek szerint zárt hurokkal szeretnél fordulatszámot szabályozni?

Ha az Sset és az Sact arányaiban sem stimmel, akkor gyanús, hogy a főorsó fordulatszáma sem arányos a PWM jellel. Látod-e vagy tudod-e mérni a főorsó tényleges fordulatszámát? Ha igen, akkor be kéne állítani a PWM frekvenciát, a min. és max. százalékot és az ezekhez tartozó min. és max. fordulatszámot. Ha a főorsó már jó fordulatszámon megy, akkor helyes enkóder felbontás esetén illene jó Sact értéket kijeleznie.

[3ebj3bk8b]

Szia!

A mellékelt kép szerint van beállítva a PWM Spindle, ezen még a régi encoder volt az 900-as felbontással. 10V-ot ad ki 100%-nál, akkor 200Hz-et kap a motor elméletileg az a max 3000 ford/perc.

De az igaz, hogy soha nem mértem meg ténylegesen a fordulatot. Erre viszont sort kerítek.

Ha sikerülne végre helyes fordulatszám értékeket kapni, akkor szeretném zárt hurokba szabályozni a főorsót. Szinkron menet vágáshoz is szeretném használni.

Csak azt nem értem, hogy ha nekem az index bemeneten, csak néha. néha (tehát nem fordulatonként), van egy egy bevillanásom a leden. Akkor honnan veszi az Sact értéket a program? Az  A és B bemenetről?
Ha igen akkor nem is kell a fordulatszám kijelzéshez az index jel?

  

[dezsoe]

A fordulatszámot tudja az indexből is és az A-B-ból is számolni. Egyedül a szinkron menetfúráshoz kell mind együtt.

Ha a PWM kimenettel 0-10V-ot állítasz elő és van egy UC300-ad, akkor miért nem rögtön az analóg kimenetét használod?

Az index bemeneten azért nem látod, hogy mi történik, mert a jel nagyon rövid ideig aktív, a képernyőt viszont nagyságrendekkel nagyobb időközönként frissíti a program. A vezérlő látja, hogy jött index jel, de annak a valószínűsége, hogy a képen is elkapd, nagyon kicsi. Ráadásul az index jel (általában) csak akkor aktív, ha az A és B inaktív, tehát a 360°-ot elosztod az enkóder teljes felbontásával és megkapod, hogy hány fokon belül lesz aktív az indexed. Nem lesz túl nagy szám... (Ez a jel is hosszabbá válik, ha kisebb felbontású enkódert használsz.)

[zt2c4wh9]

Ahogy Dezsoe is írta az Index jelet azért nem látod megfelelően a képernyőn, mert a képernyő 20msec-onként van frissítve az index jel pedig rövid/gyors jel.

Ha beállítod a spindle encoder A és B bemeneti pin-jét, akkor az UCCNC automatikusan azt használja fordulatszám mérésre. Ha csak index jelet állítasz be akkor pedig azt.
Szinkron menetfuráshoz és menetvágáshoz az A és B és az index jelekre is szükség van, legalábbis ha több bekezdéses és/vagy több fogásos menetet készítesz. Ilyenkor azért fontos az index jel megléte, mert az A és B jel nem ad abszolút pozíciót (inkrementális encoder), szóval a menet kezdetét mindig az index jelhez szinkronizálja a vezérlő.
Ebből következik, hogy az is fontos, hogy az index jel egyetlen impulzus legyen fordulatonként és mindig ugyanabban a pozícióban történjen. Vagyis az index jel nem lehet áttétel mögött a főorsóhoz képest, mert az egytől különböző számú index jelet adna különböző pozíciókban aminek a hatására a vezérlő nem tudná egymáshoz képest szinkronizálni a menet több fogását, illetve több bekezdését.

[3ebj3bk8b]

Köszönöm a segítséget!

Most már érthető! Délután megnézem még egyszer a jeleket.

Mivel ez gyári encoder és 1024 a felbontása. Arra gondoltam, hogy le kellene osztani a jelet 10-el vagy 100-al így elméletileg a magasabb fordulaton is tudja fogadni a jelet a vezérlő.

[ium8w94xp]

Nem lehetne amúgy a programon ezt úgy megcsinálni, hogy aki áttétel mögül figyeli a jelet az tudjon beállítani index értéket? Pl nekem 5 index jelre fordul egyet a főorsóm, akkor ezt is lehessen megfelelően használni? Vagy beállítani, hogy x jeladóm van, de 3:1-es áttétel mögött? Vagy bárakármi

[dezsoe]

Lehetne. De melyik lesz az öt egyforma index jel közül az, amelyikre induljon a szinkron?