UCCNC vezérlő program

[000000000]

Szia,
 
Köszi a tesztelést.
Melyik szoftver verzió van feltelepítve?  
 
Ezt a 3sec késést nem nagyon értem, nincsen valami felesleges várakozás beleírva a makróba. Olyan 300msec körüli késés a makró végrahajtásánál az előfordulhat ha hotkey-re van definiálva, mert a C# fordító valósidőben fordítja be mindig a makrót, csak így lehet azt megoldani, hogy szövegszerkesztővel bármikor át lehessen írni a makrókat és mindig a frissen átírt verziót futassa.  
G-kód program futtatáskor ez a késés nem nagyon jelentkezik, mert olyankor a sorokat puffereli a progi és már előre befordítja a makrókat, de csak akkor futtatja, amikor odaért a végrehajtás, ilyenkor a késés nulla körül kell legyen.
A 3sec az nagyon sok, ott szerintem a makróban kell valami hiba legyen ami miatt várakozik.
 
Az egyetlen dolog amibe mesterségesen beépítettünk késleltetés, az a referenciára futás, ezt kollégám kérésére lassítottuk be, mert neki nem tetszett, ha rögtön ugranak egymás után a tengelyek.
 
Egyébként volt egy hiba a progiban, azért kérdezem melyik verziót használod, amit le is írtam, hogy a .stop eseménynél benne felejtettem a debuggoláskor használt pár dolgot, ami esetleg okozhat ilyen várakozgatást. A legutolsó verzióban ez már ki lett véve.
 
Azért is gondolom, hogy talán régi verziód lehet fent, mert a hotkeys definiálásánál nekem nem joggol a legújabb verzió, úgy látom, mintha már le lenne tiltva, bár a kódot még nem néztem át...

[000000000]

Ja, még azt le akartam írni, hogy a 2800 soros progi nem szabadna, hogy gondot vagy bármilyen lassulást okozzon. Egyrészt mert a 2800 sor az nem sok, én többszázezer soros progikkal is teszteltem. A másik dolog, hogy ha tényleg olyan sok sorból áll a program, hogy az lassulást okozna, akkor automatikusan hozzá állítja a progi a frissi ciklusidejét például a 3D nézetnek, hogy ne legyen lassulás.
De a gyors hurkok, amik a mozgatást stb. végzik azok mindig 50Hz-el futnak, viszont azok nem "esznek" sokat.

[xabi]

Szia,
- 0038-at használtam.
- A 3sec nempontosan gondoltam, lehet hogy csak 0,5 sec, csak zavaró hogy nem történik semmi kényszert érzek hogy újból megnyomjam-e a gombot vagy ne. A Mach3 rögtön reagált. Lehet hogy csak szoknom kell.
- A cycle start után is gondolkodik pár másodpercet, de utána tényleg hibátlanul és gyorsan fut, ez tetszett.
 
Még csak 1 napja hsználom, majd jövőhét végére kitapasztalom, ha gondom van írok.

[dezsoe]

Volt egy ötletem, hogy mikrokontrollerrel hamar meg lehet csinálni, de amit javasoltak (PoKeys56U), az mindent tud, amire szükség lehet, kár lenne energiát fektetni bele. Csak az a probléma, hogy az UCCNC egyénileg értelmezi a gombokat, így nem lehet módosító billentyűt nyomni. (Én pl. a file betöltést szerettem volna a máshol megszokott Ctrl+O-ra rátenni, de a Ctrl-re beírt 17-et, az O már nem is érdekelte...)

[000000000]

Fogja tudni kezelni a ctrl, alt, shift módosító gombokat , ill. azok bármilyen kombinációit hamarosan. vagyis hogy pontos legyek már megcsináltam, de szoftver kiadás később lesz, mert még teszteljük az új, ill. javított funkciókat.

[dezsoe]

Köszönöm! A #1398 és #1434 egyelőre rövidre zárta a kérdést, de ha mégis szükség lesz rá, akkor még elő lehet venni a feladatot.

[000000000]

Pokeysből annakidején vettünk pár teszt példányt, vannak vele problémák. Egyik gond, hogy nagyon zavarérzékeny. A másik, hogy a mikrovezérlő lábait soros ellenállás nélkül kivezették a panelon a sorkapcsokra. Többször előfordult, hogy egyszerű érintéstől az ESD miatt szétment valamelyik bemenet vagy kimenet, mivel nem raktak még egy soros ellenállást sem ami korlátozná az ESD kisüléskor vagy hosszú kábel csatlakozásból adódó induktív túlfeszültségeket. Szóval nagyon érzékeny az áramkör, önmagában nem lehet biztonságosan használni. Amúgy funkcionálisan működött.

[dezsoe]

Nagyszerű, az jó lesz!
 
Lenne viszont néhány kérdésem, észrevételem.
- A kód színezőbe nagy meló lenne belenyúlni? Az a gondom, hogy minden, amit nem hajt végre, az piros, de nem mind hiba. Nem lehetne az Nxx sorszám pl. sárga, a megjegyzések pl. zöld színnel? Akkor messziről látszik, hogy nem hiba, csak irreleváns a futtatás szempontjából.
- Már jóval korábban is kérdezte valaki, de nem rémlik, hogy lett volna állásfoglalás arról, hogy lehetne-e valahol egy pipa, hogy a hibás kód futtatható legyen-e. Én biztos bepipálnám.
- Lehet-e belső változókat olvasásni G-kódból (pl. G31 után #2002 a Mach3-ban)? Ha nincs ilyen funkció, akkor legalább a tengely pozíciókat meg lehetne-e oldani a változókhoz hasonlóan mondjuk #X, #Y stb. módszerrel? (A példában levő G31 utáni Z olvasás kéne nagyon.)

[000000000]

Szia,
 
Kérdésekre a válasz:
 
1.) A kód szinezését még az elején megcsináltuk, de sajnos a Flashplayer annyi proci időt zabál a szinezésre, hogy nem igazán jó. Utánaolvastam és arra jutottam, hogy nincsen rá egyelőre megoldás. Az, hogy csak pirosra szinezi a nem végrehajtható kódokat, gyakorlatilag ez a művelet zabálja fel a teljes proci idő (amit az UCCNC használ) kb. 30-40%-át ami azért eléggé durván sok. Ha minden szinezve lenne különböző szinekkel, akkor több proci időt eszik maga a szinezés, mint a program egész többi része. Ez szerintem nem működő megoldás így. Talán valamikor az Adobe a Flashpalyerben megoldja majd, hogy a szines sztringek ne zabáljanak ennyit.
2.) Ha hibás egy kód, akkor az nem futtatható, hiszen hibás.
3.) Van ilyen, ismeri a parametrikus programozást az UCCNC, az amit írsz, hogy # változókból vegye az adatokat, azt tudja a program, sőt képleteket is tud számolni, sőt sin, cos, tan, abs, stb. függvényeket is ismeri. Viszont a G31-nél nem teszi el változóba a mérés eredményét, ez még nincs megcsinálva.
Több infó a parametrikus programozásról, a rendelkezésre álló függvényekről stb. a dokumentációban.

[dezsoe]

Huh! Köszönöm a gyors választ!
 
1.) Ez durva...
2.) Ezt úgy gondoltam, hogy ha van a betöltött g-kódban legalább egy olyan mondat vagy bármi, ami hibás (tehát kihagyná), akkor ne lehessen az egészet futtatni.
3.) A számítások rendben vannak, csak az a fránya Z... Viszont a #1431 nagyon hasznos volt, mert kiderült belőle, hogy csak egyszer fordítja a makrókat, így most meg tudom oldani a Z kiolvasását egy M310 makróval, ami egy sor: exec.ivars[9]=exec.GetZpos();, majd használom a #9-et. Csak a sebessége miatt aggódtam, de #1431 megnyugtatott.

[000000000]

2.) Szóval arra gondolsz, hogy ha van hibás kód, akkor jelezze és semmi ne fusson, el se induljon ciklus start-ra? Vagy legalábbis választható legyen egy ilyen opció?
 
3.) Igen, amit leírtál megoldást, azzal a módszerrel kitudod olvasni a Z mérési eredményt és utána a változó értékét feltudod használni.

[000000000]

Szia,
 
OK, köszi az infókat.
Kérlek majd ha használod többet a szoftvert és találsz bármi problémát még, vagy ami esetleg nem tetszik, akkor írd le ide vagy nekem e-mailben és akkor elgondolkodunk rajta.

[dezsoe]

2.) Igen, pontosan erre gondoltam, kapcsolhatóan. Akkor akár a színezés is kikapcsolató lehet, hogy ne zabálja a procit, hiszen elég akkor megnézni, hogy mi a gond, ha nem futtatható a kód.

[svejk]

Az a Pokeys, meg a többiek ránézésre is tök gagyik.
 
Ha Te csinálsz egyet és valami probléma lesz, akkor lesz kihez fordulni segítségért.
És hidd el nem hagynánk, hogy vackot adj ki a kezedből!

[svejk]

Ez viszont tényleg jó hír, legvégsősoron feltuningolok hardveresen egy billentyűzet elektronikát.