UCCNC vezérlő program

[Fli4l]

Ja és miután így belassult az utasításokat vagy nem is csinálja meg vagy később.

[svejk]

Lenne két javaslatom az UCCNC módósítására.
-Ha normál módban fut a G-kód, akkor le kellene tiltani a főorsó kikapcsolásának a lehetőségét.
(ez ugye tuti szerszémtörést okoz)
 
- A másik meg a Single line gomb.
Az ipari gépeken ha be van kapcsolva ez a funkció akkor is a "zöld" gombbal kell a sorokat egyesével futtatni és nem a Single line gombot kell nyomogatni.
 

[000000000]

Szia Svejk,
 
Köszi a javaslatokat.
A single line gombot azt hiszem valaki, talán Béni már javasolta, de a sok teendő mellett még nem érkeztem megcsinálni, egyelőre fel van írva a teendők listájára, amint tudom meg lesz csinálva.
 
A főorsó kikacsolás tiltásával nem biztos, hogy 100%-ig egyetértek, mert mi van ha valaki csak üresjáratban teszteli a kódot, akkor muszáj legyen a főorsónak végigzajongani az egész pályát? Vagy akkor ha nem lehetne kikapcsolni ilyenkor a főorsót, akkor ilyen esetekben ki kéne törölnie a felhasználónak a program elejéről az M3-at, ami szintén körülményes szerintem, főleg ha több helyen is van kapcsoltatva a kódban.
 
Polgárdi Balázzsal arról beszéltem a minap, hogy már kezd olyan bonyolultságú lenni a progi és olyan sok ilyen jellegű spécinek mondható kérés érkezik, hogy szerintünk lehet érdemes volna ezeket a spéci beállításokat csak a profilban szerkeszthetőre megcsinálni.(persze dokumentálnánk ezeket a kulcsokat) Vagyis ezek a speciális dolgok nem lennének a képernyőn állíthatók, hanem a profilban kulcsok értékét lehetne átírni és így átállítani a funkciókat, paramétereket.
Azért gondoltunk erre, mert félünk attól, hogy az egyre nagyobb bonyolultság miatt eljutunk oda, ahová a Mach3-asok, hogy a sok opció miatt már szinte átláthatatlan, hogy melyik beállítás hol van és mit csinál, az átlag felhasználó jó ha ezeknek a 10-20%-át használja.
Szóval az ilyen egyedi igényeket is szívesen megcsináljuk, de talán nem lenne célszerű ezeket mindet felrakni a képernyőre.
Mit gondolsz, gondoltok?

[svejk]

A tesztelésre ott van az Offline mód.
Végül is a program nem a géptesztelőknek, hanem a felhasználóknak szól, a felhasználói igényeknek kell jobban megfelelni.
Ha valaki nagyon tesztelni akar akkor kiveszi a motor biztosítékát
 
Sajnos a bonyolultság és az egyre több funkció velejárója a dolognak, én eddig is csodálkozom, hogy még bírtátok követni.
De alapvetően a mach3-nál sem a beállítások összességével, hanem inkább a megbízhatóságával van a gond.  
No meg, hogy nem tudunk kérdezni, javaslatot tenni a konstruktőröknek.
 
Esetetekben egyelőre ez a legnagyobb ütőkártya, a gyors és hatékony termék támogatás!
No és nem mellékesen már elég jól használható is a program.
 
A szoftver bonyolulttá válásától függhet az egyre több embernél előforduló USB kapcsolatvesztés?
Vagy csak már sokkal többen használjuk, ezért tűnik soknak ez jelenség?
 
 

[xabi]

Nem mintha számítana, de plazmánál hasznos-fontos hogy ki/be tudjam kapcsolni a "főorsót".

[svejk]

No igen...Mindenre van ellenérv.
 
Talán a más-más felületek is megoldást hozhatnának, no de kinek van rá ideje és szakértelme.

[000000000]

Igen, ez igaz, hogy ott az offline mód, na de akkor nem ad ki jeleket a mozgásvezérlő.
A tesztelést nem csak a tesztelők, hanem a felhasználók is végeznek, gondolom neked is volt már, hogy mielőtt anyagba engedted a gépet előtte levegőben legalább egy-egy részletet lefuttattál, hogy lásd nagyjából, hogy mi fog történni. Persze lehet csak magamból indulok ki és lehet más ilyet nem szokott csinálni?!
 
És igen, tényleg, plazmánál fontos a ki be kapcsolgatás lehetősége akár menet közben is.  
 
Hát ja, nehéz követni a dolgokat és mindig mindent figyelembe venni, észben tartani egy egy funkció kifejlesztésekor.
 
Kapcsolatvesztés: Nem, az UCCNC-nél nem sűrűn hallottam még olyanról, akinél kapcsolatvesztés történt volna, pedig már több mint 1000 kiadott license kulcsnál járunk. Mach3 aminél előfordult többeknél, de ez is orvosolható. Mach3-nál elég buta módon van megoldva az egész plugin dolog, mert valami alacsony prioritású szálban fut a mozgásvezérlő szál, ráadásul valahogy mintha a GUI egyes részeivel összefüggene vagy csak a prioritásuk megegyezik. Ezért is kell Mach3-nál egy több mint 1 sekundumos puffer, mert a Mach3-at könnyen megzavarhatják, megakaszthatják magasabb prioritásos programok, például vírusírtók.
 
UCCNC-nél ez teljesen máshogy működik. A mozgásvezérlő szál egy magas prioritású natív kódként fut, ami csak akkor akad meg, ha a Windows már tényleg teljesen megfagyott 100% proci terheléssel.
Így az UCCNC-nél a legtöbb PC-n már 50msec pufferrel is működik megbízhatóan, ezért sokkal hamarabb reagál például ha UC300-al külső potméterrel vezérelsz FRO-t, SRO-t stb.
 
Egyébként szemezgetünk már a Mach4-el is plugin tekintetében, ott sokmindent nagyon hasonlóan csináltak meg mint mi az UCCNC-ben, a vezérlés részének a belsejét tekintve.
Igaz a Mach4-ben még mindig nincsen néhány fontos dolog megoldva, ami a mach3-nál sem volt, például "deviation" beállítás, vagyis, hogy mekkora hibát csinálhat a gép maximum. Szóval kicsit most úgy néz ki mi előrébb járunk az UCCNC-vel sok tekintetben (legalábbis a legfontosabb részeket tekintve), mint az Artsoft a Mach4-el, na de ez még változhat, meglátjuk majd ki hogyan halad a fejlesztéssel.

[hyuekyh7a]

Azt tervezitek,hogy lesz menetemelkedési hiba kompenzáció?  Lézergépeknél nagyon hasznos!

[svejk]

Köszönöm a válaszokat, további lelkesedést és kitartást!!
 
 
 

[csg67]

"-Ha normál módban fut a G-kód, akkor le kellene tiltani a főorsó kikapcsolásának a lehetőségét."
Lenne is nagy csodálkozás mondjuk menetfúrásnál, kiesztergálásnál, stb...
Komolyra fordítva a szót; amíg a főorsó el nem éri a programozott fordulatszámot (nem kell feltétlenül forgójeladó a főorsóra/főmotorra, a főhajtásoknak szokott lenni n=ns jelük az n=0 jel mellett), addig az előtolást kell tiltani (ugye indulásnál is meg kell várni, hogy felpörögjön az orsó). Természetesen a gyorsjáratot nem kell tiltani, ott nem érdekes, hogy forog-e az orsó, vagy sem. Ezen felül szokott lenni egy olyan (M) kód, ami után álló orsóval is lehet előtolással menni. Persze ezeket a feladatokat nem az NC rendszerszoftvere látja el, hanem az integrált PLC program, amit a gépgyártó/gépépítő ír meg, hiszen nincs két egyforma gép és a legegyszerűbb így "személyre szabni" a rendszert. És igen, szokott lenni egy alap PLC program, amit a vezérlés gyártója ad, és egy átlagos gépet lefed, így csak a különlegességeket kell a gépgyártónak beleírnia...

[svejk]

Valószínű félreértetted, vagy nem használtad még ezt a progit.
 
Ami a felvetés volt az az, hogy fut a program, majd nekitámaszkodok a főorsó ki-be gombnak és ekkor a az előtolások megállása nélkül leáll a főorsó.
Ilyen esetben vagy álljon le minden, vagy ne legyen aktív a gomb.
 

[svejk]

Még egy kérdés, ha elkészül az UC300 Ethernet-es változata, akkor azt az  UCCNC is le fogja majd kezelni?

[csg67]

Nem értettem félre, az első mondat után azért van a szmájli.
 
Ami a többit illeti; az ilyesmit a PLC programnak kell kezelnie, különben az ezernyi változat előbb vagy utóbb (inkább előbb) elhozza a teljes káosz állapotát (mind a program, mind a beállítási lehetőségek felől szemlélve a dolgot).

[svejk]

Valóban!
 
A PLC-s dologban is igazad van, csak sajnos ez hobby körökben nem nagyon oldható meg a tudás hiánya miatt.
 
A Mach3 épp ezzel az agyonra konfigurálható tulajdonságával tudott tért hódítani az amatőrök közt, nem kell tudni PLC-t írni, plusz hardvert beépíteni csak "pipálgatni".
Illetve a mach3-ban még a brain Control lenne erre hivatott, de ez meg már megint szinte PLC tudást igényel.
Persze mindent meg lehet tanulni...
 
Én amit lehet azt általában megoldom hardveresen az I/O kártyával, csak ugye ezt nehéz konfigurálni és sajnos általában utólag jönnek az igények.
 
 

[csg67]

A sok beállítási lehetőség ("az átlag felhasználó jó ha ezeknek a 10-20%-át használja") egyrészt felesleges, másrészt olyan fejlesztésektől vonja el az erőforrásokat, amik sokkal hasznosabbak lennének. Ha egyszer egy szoftver beáll abba az irányba, ahol csak fel kell paraméterezni a rendszert (mindegy, hogy pipálgatással, vagy más módon), akkor mindig lesz újabb és újabb kérés a felhasználóktól. Ezeket beilleszteni a rendszerbe egyre nagyobb feladat, egyre átláthatatlanabbá teszi a programot, gyakran önellentmondásokat generál.
 
A másik megoldásnál sem kell minden hobbistának PLC-t írnia. Szerintem lenne itt is néhány ember, akik elmerülnének ebben a "szakmába" és örömmel segítenének másoknak a gépépítésben, beállításban. Egy idő után a sok pipálnivalót sem érti majd a felhasználók zöme, sokkal egyszerűbb és egyértelműbb lesz a géphez igazított PLC program.
Persze nem mindent a PLC csinál az ipari gépeknél sem, ott is vannak gépi paraméterek is, és a kettő együtt lesz hatékony.