UCCNC vezérlő program

[000000000]

Itt van ! [#nevetes1]  

[ium8w94xp]

Igen, ismertem Az a jó, ha minél többen, minél több alkalmazásra használjuk a teszt verziókat, mert hamar kiderülnek a bug-ok. Csak meglepődtem egy korábban remekül működő dolog változásán.

[dezsoe]

Szerencsére, nem elromlott, csak egy az egyben kimaradt.

[dezsoe]

Adatok tárolása egy makró többszöri futtatása között, avagy static változók UCCNC makrókban

Ahogy fejlődött az UCCNC, először bevezetésre került az #Events tag. Ezzel a makrónk végére olyan kódokat írhatunk, ami a makró kódblokkján kívülre való. Ilyenek például a függvények, eljárások, amit többször is fel akarunk használni, vagy - amiért eredetileg készült - a formok kezeléséhez szükséges esemény kezelők. Aztán egy másik fejlesztés során az is elkészült, hogy a makrók ne forduljanak le minden futáskor. Jelenleg úgy néz ki, hogy ha a Precompile kapcsoló be van kapcsolva, akkor már a program indulásakor, ha nincs, akkor az első futtatáskor fordulnak le. Természetesen, mindkét esetben újra fordul az a makró, amelyiknek a forrása (a .txt file) megváltozik.

Ennek a két fejlesztésnek van egy nem várt, de igen hasznos mellékhatása: az #Events tag után megadhatunk static változókat. Ezek a változók mindaddig újra használhatók és tárolják a korábbi értéküket, amíg a programból ki nem lépünk vagy a makró újra nem fordul. Például ezt a makrót egymás után többször elindítjuk, akkor a státusz ablakban szépen láthatjuk a futások között megőrzött értéket:

AS3.Additemtolistbeginning("Proba: " + proba, 2);
++proba;

#Events

static int proba = 0;

Innentől a lehetőségek korlátlanok. Például csinálhatunk 3 állású gombot, ami minden megnyomásra a következő funkciót végzi:

switch (state)
{
  case 1:
    AS3.Additemtolistbeginning("Egyes állapot", 2);
    ++state;
    break;
  case 2:
    AS3.Additemtolistbeginning("Kettes állapot", 2);
    ++state;
    break;
  case 3:
    AS3.Additemtolistbeginning("Hármas állapot", 2);
    state = 1;
    break;
}

#Events

static int state = 1;

Eddig ezt #változókon keresztül, vagy még rosszabb megoldással, a profilba tárolással és kiolvasással tudtuk megoldani. Az elsővel az a baj, hogy egy g-kód használhatja másra pont azt a változót, a második lassú és teleszemeteli a profilt. A #változókkal az az apró probléma is fennáll, hogy numerikusak. Mi van, ha string-et kell tárolni?

[krnj79r9n]

Sziasztok,

Nem tudom volt-e már jelezve, hogy a fúró ciklusok szerintem nem teljesen úgy működnek az UCCNC-ben ahogy kellene.

Múlthéten készítettem fúróciklussal süllyesztett fejű csavaroknak süllyesztékeket.
A CAM részét Fusion 360-ban csináltam a posztot a Fusion-hoz letölthető UCCNC posztprocesszorral.

Próbáltam a G81-el és a G82-es fúróciklussal is. A problémám, hogy a teljes visszahúzási magasságról mindenáron előtolási sebességgel (plunge) akart lefelé haladni és nem vette figyelembe a megadott R paramétert (síkot) ameddig gyorsjáratban kellene lemenni, majd onnan előtolási sebességgel.

Fusion-ban a szimuláció jó, a posztolt kód szerintem jó.

Itt elég jól le van írva, de nem így működik.
Az UCCNC-ben a második szakasz nem gyors járat, hanem a szintén plunge:
G82 leírása

Visszahúzásnál működik, ha több fúrási koordináta is van egy ciklusban, akkor csak az R síkig húzza vissza a szerszámot.

Mivel elég sok süllyeszték kellett és az átemelési magasság is elég magas volt közbenső lefogatások miatt, ezért jelentős idő többletet jelentett, hogy 25 mm-ről ment lefelé előtolással és nem 2 mm-ről. Kézzel átírva megoldottam, csak szerintem jó lenne, ha a generált kódot úgy futtatná ahogy az alábbi linken.

[fa_kukac]

Sziasztok! Nem tudom miért, de én mindig írok fúráshoz szubrutint, abban biztos vagyok. "Magamban bíztam eleitől fogva" A minap is volt olyan megrendelésem, hogy több mint 6600 likat kellett fúrnom, ráadásul műanyagba, ahol igencsak el kellett apróznom a forgács megszakítás miatt, és pár próba után szuper gyors és használható kód lett az eredmény. Attól még gondolom működni kellene a G81- 82-nek is rendesen.

[svejk]

Már jeleztük többen itt pár hete, az [#t218p3923#] az utolsó kiadásban ki lett javítva.

[dezsoe]

Szia!

Igen, volt már róla szó. Már ki van javítva az 1.2038-as teszt verziótól, nyilvánosban még nem jelent meg, de előbb-utább az is várható.

(Ezt a verziót nem javaslom használatra, mert egyrészt próbaverzió, másrészt egy probe hiba maradt benne, de itt lett javítva a fúróciklus.)

[dezsoe]

Sziasztok!

Megjelent az UCCNC 1.2039-es tesztverziója.

Innen tölthető le.

Javítások és változások:

- SRO által módosított S érték a DRO-ban túlmehetett a minimum és maximum értéken, javítva
- UC300 és UC300ETH analóg bemenetével szabályzott SRO és FRO nem frissítette az Overridden DRO-kat, javítva
- G31 probe esetén a mért koordináták # változóba tárolása véletlenül kimaradt az előző teszt verziónál, javítva

[ium8w94xp]

Köszi.

Indul a teszt

[krnj79r9n]

Köszönöm a válaszokat!
Ez jó hír, akkor várom a végleges verziót és majd frissítek.

[kaqkk007]

Megpróbáltam a programban összekapcsolni az Y és az A tengelyt az y nak megadtam hogy az A tengely a szolgája de a képernyőn a számláló nullán áll az A tengelynél ha elindítom a szimulációt míg a többi tengelynél pörögnek a számlálók (és a diagnosztikánál sem villognak a step-dir kimenetjelzők csak az engedélyező kimenet aktív) mit csinálok rosszul ?

[svejk]

Az úgy rendben is van, hogy az "A" DRO nem mutat ha az egy szolga tengelynek van definiálva, mert csak zavaró lenne.

De hogy miért nincs kimenetei jel azt nem tudom.
Ellenőrizd azért a valóságban is mert lehet csak diagnosztikai hiba.

[kaqkk007]

Ok köszönöm a segítséget .

[kaqkk007]

Nemsoká elkezdem beépíteni az elektronikát ,akkor majd kiderül , még egyszer köszönöm . Majd megírom a fejleményeket.