A legnagyobb használható #változó #5999. Ebből foglaltak: #5060-#5066 és #5399. Úgy látom, hogy a kézikönyv még 999-et említ, majd javítjuk.
Előzmény: hegedűs györgy, 2021-11-16 10:06:23 [8636]
hegedűs györgy | 68
2021-11-16 10:06:23
[8636]
Üdv, harcostársak! Talán Csabához szól leginkább ez az észrevételem... A mach3-ban ha változókat szeretnék használni a programozáshoz, akkor akár tízezer valahányszáz változót is meghatározhatok (definiálhatok). Az UCCNC-ben csak 999-et. Ezen nagy gond lenne változtatni? Egy asztalos számára, azért lenne ez átláthatósági szempontból könnyítés, mert egy mérethez (mondjuk szekrény szélesség...) csak valamilyen ezerig terjedő változónév rendelhető hozzá. Ebben az a bibi, hogy az ezerig terjedő számok rengeteg esetben takarnak valós bútor méretet, ami a program ellenőrzésénél, készítésénél,méret megadásnál nagyon zavaró tud lenni. Pl: UCCNC #888=888 (mm__szekrény szélesség ) MACH3 #8888=888(mm__szekrény szélesség ) Ha simán 5000 feletti változó "neveket" használok, nem zavar be egy 4 jegyű szám, mert nagyon ritkán készül 5m-es bútor darab . Sokkal egyszerűbb átlátni a programot. Tudom, nem sok asztalos programoz parametrikusan, viszont van az a "termék", aminek a legyártásához egy g-kód 1000x jobb, mint egy cad program. A g-kódban van 3 sorom egy-egy értékkel, amin változtatni kell, becsukom a szerkesztőt (g-kód editort) és már aprítom is az anyagot. Nem kell ide-oda menteni meg a többi nyavalya. Előre is köszönöm a választ. Gyuri ui: bocsika a hosszú mondatokért . . .
Ez az atkapcsolas otletes, teszek ra egy kiserletet. Arra gondolsz, hogy ket meresre allitom, az elso "visszapattan" a fenykapurol, atkapcsolja a bemerore es a masodik mar a bemeron tortenik? A gyorsmenet azert nem jo, mert a karbid bemero feje megsertheti a vagoelt.
Régi álmom, de jelenleg még nem. Illetve igen, ha trükközöl: egy kimenetet fel lehet használni arra, hogy átkapcsolja a bemérő bemenetét mondjuk egy fénykapu és a tényleges bemérő között. Így gyors méréssel elmehetsz a kapuig, majd utána indítod a rendes mérést. Egyébként, ha jófajta a bemérőd (hosszan le lehet nyomni azután, hogy bejelzett) és nem milliméter alatti a szerszám, akkor az első mérés lehet gyors és csak a második a pontos. De nem tudom, hogy milyen géped és milyen bemérőd van.
Lehetseges betenni egy limitert a szerszam bemero fole, ahol lelassit a meres elott? Hogy ne a teljes tavot kelljen neki lassan megtennie? Ez egy lezer kapu lenne.
dezsoe | 2914
2021-11-05 08:57:57
[8629]
De, úgy is lehet, sőt, még további legalább ötféleképpen. Miután a két kérdésből összesen annyi derült ki, hogy relatív mozgás kell, én ennyit írtam.
Persze. A feladat elsőre rém egyszerű: legyen M70 a bekapcsolás, M90 a kikapcsolás. Legyen a kimeneted a port 2, pin 17.
M70:
exec.Setoutpin(2, 17);
M90:
exec.Clroutpin(2, 17);
Eddig oké, de most megbonyolítom egy kicsit. Biztos szeretnél a képernyőre egy nyomógombot, amivel egyrészt be és ki tudod kapcsolni, másrészt visszajelzi a kimenet állapotát. Mivel a képernyő gombjai közvetlenül csak a 20000-21999-es makrókat tudják hívni, kell még egy makró. Legyen pl. M20000:
Ekkor már három makród van, ahol be kell állítani a kimenet adatait, amit már simán el lehet téveszteni. Érdemes tehát mindháromban fix érték helyett a profilból felolvasni a port/pin értéket. Ezt rögtön meg is kavarhatjuk azzal, ha a kimenet "active low" típusú, mert akkor a Setoutpin és Clroutpin hívásokat fel kell cserélni. Ehhez jön még további pár apróság:
- Program indulásakor alaphelyzetbe kéne állni. Ez különösen akkor érdekes, ha alacsony aktív jelről van szó. Így már az M99998 makróban is ott lesz a port/pin (és active low) beállítás. A nyomógomb sorszáma nem kell, mert úgyis kikapcsolt állapotból indulunk.
- Stop vagy reset esetén a kimenetet illene kikapcsolni. Ehhez kell még egy makró, ami hurokban fut. Ide is kellenek a kimenet adatai és a nyomógomb sorszáma.
- Ha esetleg az M7/M8/M9 mintájára szeretnél két kimenetet (tehát az M9 mindkettőt kikapcsolja), akkor mindkét kimenet állapotát követni kell, ráadásul két nyomógombra lesz szükséged.
- Ha a kimenetek kapcsolásakor várakozásra is szükség van, akkor azt is bele kell írni a makrókba.
És még lehet, hogy nem is jutott eszembe minden szempont. Viszont ennyi minden már bőven elég ahhoz, hogy ne makrókban gondolkozzunk, hanem öntsük egybe az egészet egy plugin-ba.
Segítséget kérek tőletek. Egy makro parancsra volna szükségem, amivel X és Y-ban lehessen elmozdítani a maró motrot, szeretném egy gombbal ezt megoldani, hogy ne legyen szükség minden alkalommal MDI-ben megírni.
dezsoe | 2914
2021-11-04 15:29:51
[8618]
A FreeCAD-et és az OpenSCAD-et tanulgatom, amikor épp van időm foglalkozni vele. Leginkább 3D nyomtatáshoz kell. UCCNC-vel leginkább NyÁK-ot marok, ahhoz Eagle-lel tervezek és pcb-gcode-dal generálok.
Hogy az F360-ban mit lehet beállítani, azt nem tudom, nagyon nem is izgat. Nálam elásta magát a beetetős, majd minden fontosat kivevős üzletpolitikájával. Szerencsére nem öltem bele sok időt, azt a pár napot sem kellett volna.
UCCNC-ben viszont megfelelő makrókkal meg lehet csinálni, hogy legyenek további kimeneteid. Vagy ha túl sok a makró, akkor össze lehet hozni egy plugin-ba az egészet. Meg kell néznem, mert ugyan írtam már ilyen plugin-t, csak abban volt valami spéci dolog, mert egy bizonyos géphez készült. (És, persze, nem is nagyon emlékszem a részletekre így kb. 2 év után.)
Koszonom a valaszt. Az M7, M8 a mist es a flood. A misthez kell levego is es kulon-kulon szeretnem kapcsolni, hogy a levego opcio kulon is elerheto legyen es meghivhato a CAM-bol. Az elszivas meg mehet M8-ra, az nem gond, de jo lenne ha sajat neven futna. Szoval nem is tudom boviteni a CAM-bol elerheto makrokat?
Így sehogy. Az exec osztály nem tartalmazza ezeket a függvényeket.
Tudsz kimenetet kapcsolgatni exec.Setoutpin(<port>, <pin>) és exec.Clroutpin(<port>, <pin>) hívásokkal, de ez még így kevés, mert tudnod kell a kimenet aktuális állapotát is, resetre vagy stopre ki is kéne kapcsolnod stb. Az M7-M8 miért nem jó? Már elhasználtad másra?
Sikerült módosítanom a postot, működik is. Eljutottam oda, hogy hozzáadtam egy levegő és elszívás makrót, M70 és M71 néven. Az M70 exec.Airon() és az M71 exec.Suctionon() lett. A következő akadály, hogy ezeket a futtatható állományokat vagy hivatkozásokat hogy rendelem hozzá portokhoz? Gombokhoz is szeretném, de az menni fog.
Segitseget szeretnek kerni a fusion post modositasahoz. Arra van szuksegem, hogy coolantnak beallithassak levegot es elszivast is. Ezekre nincs kesz makro ahogy latom, ezekben is kernek segitseget.
Bocs | 273
2021-11-03 09:43:24
[8611]
Nagyon köszönöm! Sokadszorra segítettél. Így már azt hiszem menni fog.
Köszönöm a válaszod! Még nem írtam, szerkesztettem makrot. Ezt hol kezdjem? Hol férek hozzá az UCCNC-ben? Nem ijedek meg a tanulástól és a kihívásoktól.
Telepítettem az UCCNC 1.2049-et mert az 1.2047 elkezdte magát felfalni. Hol a kézikerék plugint törölte, hol a képernyő egy-egy gombját. Lehet, hogy windows hiba, lehet más, nem fontos, mert annyira egyszerű a telepítés, hogy nem vacakoltam a hibakereséssel.
A régi verzió is tetszett, de az újért teljesen oda-vissza vagyok. Ezer köszönet érte!
Néhány dolgot nem találok a leírásában. Örömmel használnám a 2 ingyenes parkolóhelyet (GOTO PARK 1, GOTO PARK 2), de nem találom, hogy hol kell beállítani a helyét és ha van, a mozgásokat, stb. Itt a fórumon se találok róla semmit. Pedig szívesen készítenék külső gombot is hozzá.
CNCdrive | 442
2021-11-02 14:40:22
[8606]
Semmi baj az abszolút encoderrel, de ha etherCAT-en kommunikál, akkor egyszerű illeszteni egy EtherCAT rendszerbe.
Itt egy példa a dedikált vezérlő néküli megoldásra: https://www.datron.de/en_gb/datron-cnc-machines/datron-next.html Modern alapokon, normális GUI és nincs tervük a kidásra, mert a saját gépeiket etetik vele. Na ide kellene pozicionálni az UCCNC-t.
Tulajdonképpen minden megvan már hozzá "csak" a adaptálni kell egy fieldbust az LPT helyett (úgy látom EtherCAT-ra esett a választás) és kezdetnek elég is, mert a logika már stabilan működik a szoftverben. Van itt bőven vállalkozó kedvü ember, aki örömmel tesztelne, ha közben megtanulhatja az fieldbus modulok kezelését.
Pedig, ezzel lépnétek igazán szintet! Mert ha csak marad a ún vezérlés... az nem jelent akkora előrelépést. Persze értem hogy madzagolás, szervók használata...stb És inkább ha vezérlős vagy valami is kellene, akkor arra hogy a sztenderd inkrementális, netán abszolút jeladókat lehessen használni pozícionálásra ethercat-el Biztos nem kicsi fejlesztés, de az ipar profi területére törnétek be vele....
A dedikált vezérlőt teljes egészében ki lehet hagyni. Elég a PC és az EtherCAT IO a kifejtőn. Így teljesen ipari alkatrészekre támaszkodva szoftveres lenne kizárólag az UCCNC és jelentősen megnőne a diverzitása. Elmúlik a step/dir korszak és tetszőleges fieldbuszokat lehet majd használni. Végtelen IO, API-k, és computer vision feedback, munkaközi minőségellenőrzés és még sorolhatnám Ja és a hobbistáknak is egy nagy lépés lenne tudásban. Szerintem...
Éppen olyan Beckhoff I/O modult használtunk az EtherCAT protocol fejlesztésnél. Működött. Szóval igen, lehetne I/O modult is felfűzni az EtherCAT-re, de első körben már azzal is meg leszünk elégedve ha motorvezérlőkkel működni fog.
Az EtherCAT csak egy kommunikációs protocol és ebbe van beleágyazva egy másik protocol, COE vagy Profibus szokott lenni. De ez még mindig csak a protocol, a szintaktika. Az, hogy a vezérlő ezekben az EtherCAT COE vagy Profibus packetokban milyen adatokat vár, hány adatra van szüksége az már vezérlő kérdése. Ezért nehéz általánosítva megcsinálni, hogy több féle vezérlővel is tudjon működni. Persze meg lehet csinálni többfélére, de akkor minden vezérlőhöz hozzá kell fejlszteni, hogy tudja konfigurálni és vezérelni az UCCNC. Szóval sajnos nem olyan ez mint a step/dir, hogy egy egyszerű kommunikációs szábvány és könnyű általánosan leprogramozni a kommunikációt.
A változók elnevezése (és úgy általában a g-kód szerkezete) az RS274NGC szabványban van rögzítve. Tehát lehet, csak azt már nem g-kódnak hívják.
Előzmény: hegedűs györgy, 2021-10-31 17:54:42 [8593]
hegedűs györgy | 68
2021-10-31 17:54:42
[8593]
Sziasztok! Kérdezős kedvemben vagyok. A "változós" programozást nem lehetne megkönnyíteni betű alakú változó elnevezésekkel a szám alakú helyett? Átláthatóbbak lehetnének a g-kódok. Vagy az már egy másik programozási nyelvet igényelne? Többek között. Előre is köszönöm a válaszokat. Üdv, Gyuri
Köszönöm a részletes választ. Mikor lehet tesztelni az alfa hardvereket? Szuper lenne, ha EtherCAT-os PLC lenne az IO, az LPT helyett, ezen a szinten az LPT már okafogyottá válik és lassú is. Itt egy alkalmas minta hw I/O-nak: beckhoff ek1100 Szuper lenne, ha a mozgásvezérlő "csak" bridge lenne a PC és a PLC között. A Leadshine EtherCAT különbözik valamiben a többi gyártó által használt protokolltól, vagy ez csak egy mondás a kooperáció mentén?
Az EtherCAT vezérlő egy teljesen különálló mozgásvezérlő lesz, nem kell hozzá UC300ETH. Úgy terveztük, hogy egy kis panel lesz 2db ethernet porttal, az egyik a PC-vel kommunikál (UCCNC-vel), a másik portra lehet majd felfűzni az etherCAT-es motorvezérlő kártyákat. A mozgásvezérlőn lesz még I/O, amit valószínűleg egy normál és egy bemeneti kiosztású LPT port (IDC26) lesz, hogy lehessen rá csatlakoztatni UCSB vagy UCBB elosztópanelt. Később lehet majd fejlesztünk EtherCAT-es I/O kártyával való kompatibilitást is.
A project még nagyon az elején jár, viszont egyezkedtünk a Leadshine céggel és első körben az ő motorvezérlőikkel tesszük majd kompatibilissé a mozgásvezérlőt. Vannak nekik léptető és szervó EtherCAT-es motorvezérlőik is.
2021-11-20 13:36:21
. Sokkal egyszerűbb átlátni a programot. Tudom, nem sok asztalos programoz parametrikusan, viszont van az a "termék", aminek a legyártásához egy g-kód 1000x jobb, mint egy cad program. A g-kódban van 3 sorom egy-egy értékkel, amin változtatni kell, becsukom a szerkesztőt (g-kód editort) és már aprítom is az anyagot. Nem kell ide-oda menteni meg a többi nyavalya. Előre is köszönöm a választ.
Miután a két kérdésből összesen annyi derült ki, hogy relatív mozgás kell, én ennyit írtam.
Ezer köszönet érte!