Hírek:

Fontos tudnivalók a migrációval kapcsolatban, kérlek olvasd el:

A régi fórumról áthozott hozzászólásoknál a felhasználó neve adatvédelmi megfontolásokból véletlenszerűen generált értékekre lett  lecserélve. Ez akkor tud a valódi értékre visszaállni, ha az adott felhasználó a régi fórumon nyilatkozik, hogy beleegyezik az adatainak az új fórumra továbbításához, majd ezután itt a régi felhasználónevével és email címével regisztrál.
8~20 óra között, 1~30 percen belül megtörténik a jóváhagyás, 30 percenként ellenőrizd email fiókodat (SPAM-ot is) mindenképp kapsz mail-t, a sikeres regisztrácioról, vagy a hibáról és, hogy mi a teendőd.
Nézd meg  "A régi fórumról, az új fórumra költözés útmutatót."
A régi fórumon használt email címmel de más felhasználói azonosítóval érkező regisztrációs kérelmek törlésre kerűlnek.

Main Menu

UCCNC vezérlő program

Indította gaben, 2024 április 09, 16:54

Előző téma - Következő téma

chyfhc809

köszönöm a választ!  
a probléma megoldódott!
Nem gondoltam volna, hogy a licence rádugás után érvényesül! ( otthoni gépen próbáltam, az UC300 a műhelygépen üzemel)

cxmcdtrx

Köszönöm, nincs több kérdésem :-)

hyuekyh7a

Balázs az M31 kódot átalakitva, mert plazmánál nem szerszámot tolok el hanem G92 vel nullázom a Z tengelyt és kivéve a bemérés pozicióját,mert az mindig az aktuális pozició, a kód jól müködik.
Viszont a tengely végállásnál kivéve a pipát az aktív lov ból, mert különben reseten marad továbbra sem menti el, minden indításkor újra bent van a pipa!
A THC még nem jó, mert ha be van kapcsolva semmilyen mozgást nem hajt végre a program, ezt az állapotot (THC) csak az M3 vagy M4 utasítást követően kell figyelembe venni, különben nem pozicionál a vágási helyre a gép,mert várja a THC ok jelet,de ugye az még nincs mert csak a vágás kezdeti helyére történő pozicionálás után az M31 lefutása után jön az M3 begyujt a plazma és csak ekkor lesz ív jó jel.

000000000

Szia Csaba,
 
Megnéztem a hibákat amiket jeleztél, az észrevételeim:
 
1.) Ha jól értem az írásodból, akkor az M31 kódot sikerült úgy átírnod, hogy jó legyen a plazmához.
 
2.) Megnéztem a Limit aktív low pipát és valóban a limit+ active low pipánál volt egy elírás a kódban és tényleg nem mentette el jól a beállítást. Ezt most javítottam, a következő verzióban benne lesz a javítás.
 
3.) Ez a funkció egy kicsit bonyolult, kellene a segítséged, hogy jól értem-e, hogy pontosan hogyan is kellene működnie, mert félek, hogy nem értem pontosan.
 
Szóval, ha a "Control THC even if..." be van pipálva, akkor mindig szabályozza a THC-t akkor is ha nincs mozgás és akkor is ha nincs M3/M4, szóval mindig szabályoz és a mozgást sem tiltja soha sem. Légyszi írd le, hogy jól gondolom-e?
 
Ha a "Control THC even if.." nincsen kipipálva, akkor:
 
1.) Ha nincsen még M3/M4, akkor a THC-t nem kell szabályozni, de a mozgásokat végre kell hajtani.
2.) Ha van M3/M4 és ha még nincs THCon jel, akkor a mozgást nem szabad elindítani és a THC-t se kell szabályozni.
3.) Ha van M3/M4 és ha megjött a THCon jel, akkor kell indítani a mozgást és akkor kell a THC-t is szabályozni.
 
Légyszi írd meg, hogy jól értelmezem-e a működést?
Jelenleg az 1. pont hiányzik még, a te leírásodból legalábbis ezt vettem ki, hogy így kéne működnie...
Ha esetleg rosszul értelmeztem a leírásod, akkor kérlek a pontokat amiket leírtam javítsd át és úgy másold be, hogy biztosan pontosan meg legyen fogalmazva a helyes működés, mert akkor letudjuk jól kódolni.

hyuekyh7a

Teljesen jól értelmezted, így kell működnie ahogy leírtad.
Igen az M31 is jó a plazmához átírva kicsit!

000000000

Elkészült az UCCNC 1.0036-ös verziója.  
A változások, javítások:  
 
- A limit+ active low beállítást nem jól mentette el a program, javítva.
- A THC működésén módosítottunk az itt tárgyaltak szerint.
- A home-ot nem állította meg a stop gomb, csak a reset, javítva.
 
http://cncdrive.com/UCCNC/setup_1.0036.exe" TARGET=_fnew>UCCNC 1.0036

frkdv6dyr

Lenne egy érdekes kérdésem :)
 
Normál léptetőmotor vezérlővel, de enkóderes motorral, vagy külön felszerelt enkóderrel az UC300 segítségével hogyan lehet megoldani egyszerűen és hatékonyan a kontrollált léptetést? Azaz amikor is kiad egy lépés jelet a program, 5us késleltetésen belül ha nem érkezik az enkóderről egy "léptem jobbra vagy balra" jel akkor vár még 5us majd megismétli, vagy hibával megáll.

000000000

Szia,
 
Ezt sajnos nem lehet úgy megoldani, ahogy leírtad, mert a feladat amit vázoltál nem annyira egyszerű mint amilyennek tűnik. Bár nem ez a leglényegesebb probléma, de eleve az 5usec annyira rövid idő amit írsz,  1/5usec = 200kHz, hogy a legtöbb léptetőmotorban ennyi idő alatt nem is történik meg a lépés, főleg ha az elektronika feldolgozási képességét is figyelembe vesszük.  
 
A másik (ez a nagyobbik gond) probléma a léptetőmotor inverz sebesség/nyomaték jelleggörbéje, vagyis ha nem történt meg a lépés és újra ki kell adni, akkor az léptetési frekvencia növekedést jelentene, főleg jelentős problémává válik ez ha több lépéssel elmarad.
A motor pedig valószínűleg azért tévesztett lépést, mert túl alacsony volt a nyomaték és kiesett a szinkronból. Ilyenkor csökkenteni kéne a frekit, nem növelni, de ez a "digitális" algoritmus amit írsz ez éppen, hogy növelné. Így éppen az ellenkezőjét érnénk el mint ami a cél volna, vagyis tutira a megtorpant állapotban maradna a motor.
 
A lépés tévesztéskor le kellene lassítani a mozgást a tengelyeken arányosan addig a pontig, amíg a hibázó tengely újraindul és akkor tud tovább futni.
 
Vannak olyan vezérlők (szabályzók) amik tudják ezt, amik zárt hurokban szabályozzák a motorokat, az ipari vezérlők általában így működnek, de ez a tudás az árban is megmutatkozik, kb. két nullát írj az UC300 ára mögé és annyiért már lehet ilyen vezérlést kapni, persze csak a vezérlést.
Az ilyen vezérlőkhöz a motormeghajtók sem step/dir jeleket fogadnak, hanem EtherCAT vagy más gyors kétirányú adatátvitelt igényelnek és hát az ilyen motorvezérlő kártyák sem a hobby pénztárcára vannak szabva.
 
Az UC300-al és az UCCNC-vel maximum azt tudnád megcsinálni, hogy egy külső encoder számláló elektronika számolhatná a lépéseket és a step/dir jeleket egyidejűleg és bizonyos definiált pozíció hiba felett kiadhat egy vészstop jelet az UCCNC felé, amivel a mozgás megállna.

hyuekyh7a

Szia Balázs!
Most már nagyjábó jó,csak annyi a probléma,hogy mikor megkapja az ív jó jelet el is kezd szabályozni a Z tengely azonnal de valamiért a mozgás nem indul meg csak kb. 2-3mp múlva.
minden késleletetés le van véve nullára aTHC menüben is és a motor menüben is.

000000000

Szia Csaba,
 
Köszi a tesztelést és a visszajelzést.
Ellenőriztük a működéstés a mozgás és a THC szabályzás is azonnal indul, kimértük logikai analizátorral a jeleket.
 
Az nem lehet, hogy az M31-ben benne hagytál várakozásokat és amiatt késik? Az M31 kódban van összesen kb. 2.5sec várakozás is belerakva. Ha azt benne hagytad a kódban az okozhatja.
Nézd meg majd légyszi a kódot hogy van-e benne még .wait kód.
A másik dolog, hogy az M203 kódot azt direkt plazma magasság felvételére írtuk, azt is megnézhetnéd az talán jobban illeszkedik ahhoz amit csinálsz.
 
Ami még jó volna, ha át tudnád küldeni nekem a G-kódot és a makrót e-mailben amikkel próbálgatod és akkor megnézzük, hátha megtaláljuk, hogy mi lehet a gond.

frkdv6dyr

Végül is ez lenne a célom amit a végén írtál. Az 5us csak egy lényegtelen adatnak tűnt nekem :) de ezek szerint van konkrét jelentősége.  
 
A távlati célom az lenne ezzel a dologgal, hogy bizonyos százalék után stop legyen, de mondjuk egy-két lépés kihagyásakor az összes tengelyen álljon meg, majd (lassabban ahogy írtad) próbáljon lépni mondjuk ötször, és ezután stop.  
 
Tény és való, hogy hobby célra nincsenek plusz nullái senkinek, de mondjuk egy 200lépés/1mm beállításnál 5 lépés elvesztésénél kezdjen el valamit csinálni a progi. Az UC300-nak van annyi bemenete, hogy ez ne legyen gond. A sebességet meg értelemszerűen le lehet venni akár 25kHz-re is, cserébe kapnál egy kontrolláltan "pontos" vezérlés.  
 
Ha nem is akarsz ennyire mélyen belemászni, makróból látsz esélyt a megvalósításra? Az olcsó, de cserébe gyenge motorokkal van elég rossz tapasztalatom, és ezt szeretném kiküszöbölni.

svejk

" Az olcsó, de cserébe gyenge motorokkal van elég rossz tapasztalatom, és ezt szeretném kiküszöbölni."
 
És lesz cserébe helyette egy szoftverrel meghágott béna, darabos mozgású, ugyan úgy bizonytalan, bosszantó hajtásod...
 
Szerintem nem éri meg vele foglalkozni amikor a szervok szinte már semmivel nem drágábbak mint a velük hasonló súlycsoportban levő léptetős hajtások.

hyuekyh7a

Ok megnézem, de csak szerdán tudom ismét tesztelni.
Holnap egy 1Kw os dióda lézer beüzemelésen vagyok:-)

000000000

Szia,
 
Ahogy írtam, azt meglehet csinálni egy külső kis mikrovezérlős áramkörrel, hogy számolja az encoder osztást és a step és dir jeleket és stoppot csináljon ha nagyobb a poz.hiba egy előre beállított értéknél.
 
Azt, hogy visszavegye mondjuk a feedrate-et azzal az a baj, hogy azt akkor dinamikusan kellene állítani, de azt nem igazán tudod úgy megoldani, hogy jó is legyen. Ahogy Svejk írta kapnál egy szaggatós mozgatást.
 
A helyes megoldás az volna, ha a motor áramát vektorosan szabályoznád és a motor kommutációs felbontásánál (alap felbontás) egy nagyságrenddel nagyobb felbontású encoder lenne a motoron, hogy ne legyen kommutációban hiba. És akkor vektorosan szabályozhatod (2db sin/cos áramjellel egy-egy PI szabályzóval) a léptetőmotort, mintha egy sokpólusú AC szervo lenne. Egy beépített pozíció PID hurokkal pedig szépen lehetne szabályozni a lemaradást, pozíció hibát. Így a nyomaték vektor mindig megfelelő irányú lenne és szép egyenletes futást tudnál elérni, hasonlót mint egy szervónál.  
Persze egy ilyen rendszert megalkotni nem 2 perces feladat, kell hozzá némi tapasztalat és háttérismeret.  
De a lényeg, hogy így meglehetne csinálni és igazából így volna értelme egyáltalán megcsinálni.

000000000

OK, akkor majd ha lesz időd nézd meg légyszi, mert mi kimértünk mindent és látszólag minden OK és azonnal történik.  
Esetleg ha megvannak a fájlok és átküldöd őket, akkor mi addig azzal is letesztelnénk, kimérnénk a dolgokat...
 
Jó lézer üzemelést és csak óvatosan. :)