UCCNC vezérlő program

[000000000]

Szia István,
 
Nem, nem kaptam levelet tőled. Ha fórumon írtad üzenetben, azt az e-mail címet nem olvasom, megváltoztatni pedig nem tudom hogyan kell, itt a fórum motorban, nem látok rá lehetőséget.
Légyszi küld el a levelet az info@cncdrive.com e-mail címre, azt állandóan figyelem.

[pisti73]

Ok, küldöm oda azonnal... Köszönöm szépen...

[000000000]

Szia Gábor,
 
Szerintem Homovits Miki nem használ UCCNC-t, gondolom Mach3-al történt amit írsz?!
 
Az Xbox vezérlő nem billentyűzetként kapcsolódik a PC-re (ha ez volt a kérdés), hanem spéci HID eszközként, ami a Windows-ban egy szabványos "joystick/joypad" ként jelenik meg és ezt le lehet kérdezni különböző API-kon keresztül, például DirectX és OpenGL tartalmazza a megfelelő függvényeket, hiszen ezek játékok kifejlesztésére szolgáló feljesztőeszközök, beléjük van építve a joystick/joypad kezelése mint alapfunkció.
Az UCCNC-ben mivel OpenGL-t használunk a szerszámpálya megjelenítésre, a legkézenfekvőbb az volt, hogy az OpenGL beépített függvényein keresztül olvassuk az Xbox joypad-et és erre írtunk egy plugint, hogy a gombokat joystickeket amik a vezérlőn vannak hozzá lehet rendelni UCCNC funkció hívásokhoz.A gombok/joy-ok egyenként szabadon hozzárendelhetők a kb. 400db rendelkezésre álló funkció bármelyikéhez.
 
Nem tudom, hogy Mikinek milyen problémája volt pontosan a billenytű emulátorral, vagy hogy a szoftver része a Mach3-nak ezt hogyan kezeli, talán ott lehetett valami gond.
 
Zavarvédelemről nem tudok nyilatkozni, a gyártó (Microsoft) erről nem közölt adatokat.

[Miki2]

Szerintem Homovits Miki nem használ UCCNC-t, gondolom Mach3-al történt amit írsz?!  
 
Persze, így van.
Decsak azért, mert az UCCNC még mindíg nem tud esztergálni!
 
 

[ANTAL GÁBOR]

 Értem A válasz egyértelmű : nem egy pótlólagos billentyű hanem valami valószínűleg jobban átgondolt eszköz.  Ja és lehet hogy a Mach is ludas a dologban . Azért feszegetem mert egy másik emulátorral ( nem fórumos ) nálam is előjött már a hiba . Szeretek úgy menetet vágni a Mach hal ( G32 )   hogy én adom a fogást ( nekem dupla keresztszános  a TOS om ) nagyon gazdaságos és gyors módszer de a ciklus startnak atombiztosan kell működnie.  Hát volt már úgy hogy lefagyott ( a screen designerrel egy hotkeyt definiáltam amit az emulátorral hozok létre a szánszekrényen elhelyezett nyomógombbal  )  Így nem kell fogyasztanom az UC 100 as értékes bemenetét Az UCCNC t még én sem használom esztergára

[dezsoe]

Szia!
 
Két kérdésem volna.
 
1. A program induláskor felolvassa a pluginokat, ez OK. Miután a Getproperties_event-en keresztül lekérdezi a lekérdezni valókat, meghívja az Init_event-et is. Akkor is, ha a plugin nincs bekapcsolva. (A korábbi verziókban is így ment, de csak most vettem észre, mert hiba volt az init-ben.) Van ennek érdemi oka, vagy véletlen?
 
2. Tudom, nem kardinális kérdés, de továbbra sem fér ki a nevem a plugin config ablakban.

[hyuekyh7a]

Windows CE -en megy az UCCNC?

[000000000]

Szia Csaba,
 
Még nem nagyon használtam WinCE-t, de ha jól tudom mobil eszközökre van kitalálva és szerintem az OpenGL nincs benne a szolgáltatásai között. Illetve nem tudom a Flashplayer-t tudja-e futtatni például?
 
Szóval nem nagyon értek a CE-hez nem nagyon van vele tapasztalatom, de vannak kétségeim, hogy fut-e rajta az UCCNC. Ha tippelnem kéne azt mondanám, hogy nem.
 
Azt viszont biztosan tudom, hogy a Windows RT verziójával, ami okostelefonokra és egyéb smart eszközökre lett kitalálva, azon nem fut.

[000000000]

Szia Csaba (dezsoe),
 
Úgy emlékszem, hogy ez direkt így lett megcsinálva, hogy mi értelme van, az egy jó kérdés.
Nem tudom pontosan mi is járhatott a fejemben amikor így lett megcsinálva...
 
És igen, valóban, a név rublika a pluginoknál tényleg nem lett még megnyújtva, most felírtam magamnak, hogy a következő verzióra meglegyen fejlesztve.

[dezsoe]

Szia!
 
Elképzelni nem tudom, hogy egy be nem töltött plugint miért kell inicializálni... Mert, ha legalább előbb hívná az init-et, és utána a property-t, akkor mondhatnánk, hogy valamit csak így tud visszaadni, de ráadásul fordítva van. Mindegy, majd kezelem valahogy.
 
Más. Ahogy másoknak is itt a fórumon, nekem is van vesszőparipám. Várható-e végleges állásfoglalás (netán program módosítás!) a G82 P paraméter öröklődésével kapcsolatban?
 
És még valami. Emlegetted a csak profilban állítható, "rejtett" paraméterek esetleges bevezetését. Igen kellemes meglepetés lenne, ha bekerülne ide egy olyan kapcsoló, ami (megint egy vesszőparipa) azt állítaná, hogy a várakozások (G04, G82 P stb.) s vagy ms alapúak. Nem is tudtam, de itt valaki felhívta rá a figyelmemet, hogy a Mach3-ban is kapcsolható, de nem is ezért érdekes, hanem azért, mert ott másodperc az alapértelmezés (meg a javasolt, G kód szabványról szóló doksikban is), és a különböző kódgeneráló programok (pl. pcb-gcode) is erre számítanak, másodpercben generálnak.

[000000000]

Szia Csaba,
 
Hát ja, majd átkell néznem a plugin inicializálást, egyelőre én sem tudom, hogy miért hívódik meg ha nincs engedélyezve a plugin, de úgy rémlik valami oka volt.
 
A G04 msec/sec állíthatóságát megfogom csinálni hamarosan.
 
A G82 P öröklődésének utána kell nézzek, most nem tudom, hogy kell-e öröklődnie vagy sem, de jó volna a szabványokat követni. Tudom beszéltünk már róla, de most hirtelen nem tudom, hogy hogyan kell működnie szabvány szerint...
 
 
 

[frkdv6dyr]

Terveztetek közvetlen kommunikációs lehetőséget RS485 vagy RS422 eszközökkel?
 
Az ötletem egy inverter vezérlése amire nem kimeneteket meg PWM-analóg jeleket akartam felhasználni, hanem egy plugin segítségével közvetlen programozni az eszközt futási időben, de persze vannak más létező ki és bemeneti eszközök amiket ezzel a módszerrel használni lehetne. Mivel gyakorlatilag C# segítségével bármi megoldható, csak a hardveres soros portot kellene használni programból hozzáférve a beállításokhoz is.
 
 
Egy ötlet csak

[000000000]

Szia,
 
Pluginból meglehet csinálni amit írsz. A programozott főorsó sebesség mező és az M3/M4 LED-ek is lekérdezhetők pluginból. C#-al pedig egyszerűen megoldható a soros kommunikáció.  
 
A komplikáltabb része a dolgoknak a frekvenciaváltó hardveres illesztése, általában Modbus protokol-al beszélgetnek, szóval kellene egy RS232 vagy USB/RS485 illesztő és le kellene programozni a modbus protocol-t.
Ja és kell hozzá frekiváltó ami tud így kommunikálni és kell ismerni a pontos utasításait és válaszait.
Nem tudom mennyire van ez szabványosítva manapság, de arra tippelek, hogy ahány gyártó, annyi féle képpen kommunikálnak.
Persze lehetne írni egy általános/konfigurálható Modbus plugint és akkor a felhasználó hozzá hangolhatná a frekiváltójához.
Az biztos, hogy nem egy "hétvégi" projekt.

[frkdv6dyr]

No de nem egy hétvégi alkalmazáshoz kell.
 
Arra gondoltam, hogy trükkök nélkül közvetlen sorost mahinálni amire a felhasználó maga teszi fel az illesztést. Vannak eszközök amik sorosak, vannak 422 és 485, no meg a bánat tudja mennyi illesztési lehetőség amit a mikrovezérlő soros portjára fel lehet baggatni. A hardveres soros a programozottal szemben előnyben van, mert nem kell kérdezgetni, simán szól ha kommunikáció van.  
 
A protokol szintén változó ahogyan azt írtad is, de ez megint legyen a felhasználó dolga. Persze egy keret rendszert fogadó illesztés nem lenne hátrány.  
 
No de ennyit a fantáziáról, csak arra voltam kíváncsi, hogy terveztetek-e valami hasonlót, vagy oldja meg maga mindenki az illesztést a szokásos ki és bemenetek segítségével és PWM fordulat szabályozással.

[dezsoe]

Szia, Balázs!
 
Hogy ne kelljen keresned, összeszedtem három, azaz két dolgot. Már nem emlékeztem, hogy bő fél éve meddig jutottam, így újraolvastam a fórum elejét, meg a kézikönyvben is ellenőriztem, hogy tényleg az RS274-hez próbálunk igazodni. A legfrissebb verzió az RS274NGC_3.pdf, igaz, hogy 2000-es kiadás, de nem láttam frissebbet. Ebből idézek:
 
30. oldal ezt írja az öröklődő paraméterekről (G82 P téma): "For canned cycles, we will call a number “sticky” if, when the same cycle is used on several lines of code in a row, the number must be used the first time, but is optional on the rest of the lines. Sticky numbers keep their value on the rest of the lines if they are not explicitly programmed to be different."
 
33. oldal, G82 a s/ms kérdésről: "3.5.16.3 G82 Cycle
The G82 cycle is intended for drilling. Program G82 X… Y… Z… A… B… C… R… L… P…
0. Preliminary motion, as described above.
1. Move the Z-axis only at the current feed rate to the Z position.
2. Dwell for the P number of seconds.
3. Retract the Z-axis at traverse rate to clear Z."
A 2. pontban egyértelműen másodperc van.
 
25. oldal, G4, s/ms: "3.5.4 Dwell — G4
For a dwell, program G4 P… . This will keep the axes unmoving for the period of time in seconds specified by the P number. It is an error if the P number is negative."
 
(Érdekesség, hogy a két problémába egyszerre futottam bele: mikor elkészült a G82, kipróbáltam. Fúrt szépen, csak nem állt meg az alsó pozícióban. Némi keresgélés után rájöttem, hogy ms-ban várja a paramétert. (Tehát megállt, csak 0.2ms-ra, ami nem volt látványos.) 1000-es szorzó után már látszott, hogy megállt, de nem öröklődött a P a következő G82-re. Mivel az M3 és M5 késleltetése állítható a programban, sosem használtam G4-et, nem derült ki, hogy nem másodpercben számolunk. Az egész mizéria nálam a pcb-gcode-hoz köthető: ha a G82 P és a s/ms kérdés rendeződik, akkor már nem kell módosítani a pcb-gcode-on (lásd: #1691), hogy panelt lehessen vele marni, hanem mehet a Mach3-as beállításokkal. Lesz ugyan benne szintaktikai hiba egy sor végi megjegyzésnél, de azt az AutoLeveller javítja.)