Mach3-ban lehet van egy digitális szűrő az MPG-n, csak tippelek... pontosan nem tudom, de majd megkérdezem Balázst. Mindenesetre, ha van lehetőséged rá kipróbálni egy pici RC szűrővel a csatornákon, az jó lenne.

Előzmény: svejk, 2014-11-04 10:10:00 [1485]

Balázs ezt múltkor letesztelte, de szerintem nem írtam le, hogy mikor mondtad ezt a hibát, akkor ő ellenőrizte a multi módot és 50kHz felett téved csak el, az a határfreki. Ha mondjuk 100-as encodered van 4x-es (quadratura) módban dekódolva akkor annyira gyorsan tutira nem tekered, mert az 50kHz az 125 Hz-es tekerést jelent.
Azt javasolta Balázs, hogy tegyél egy RC filtert a csatornákra, mert mivel tutira nem tudod túllépni az 50kHz-et kézi tekerési sebességgel, így csak prell zaj lehet a probléma.

Előzmény: svejk, 2014-11-04 10:10:00 [1485]

A kombinációs Hotkey-ek jól működnek.

Előzmény: n/a (inaktív), 2014-11-03 20:16:00 [1480]

MPG multi módban továbbra is eltéved a szerkezet.

Ugyanezen hardver a Mach3-nál mindig visszatalál ha az MPG kereket visszatekerem 0-ra.

Előzmény: n/a (inaktív), 2014-11-03 20:16:00 [1480]

Az szuper lenne, köszi!

Előzmény: svejk, 2014-11-03 21:43:00 [1483]

Holnap délelőtt megpróblok időt szakítani az MPG tesztekre.

Előzmény: n/a (inaktív), 2014-11-03 20:17:00 [1481]

Előzmény: n/a (inaktív), 2014-11-03 20:16:00 [1480]

Annyi megjegyzés még, hogy az MPG dolgoit az összetettsége miatt jó lenne ha most tovább tesztelnétek és ha találtok még benne hibát, akkor kérlek jelezzétek.

Előzmény: n/a (inaktív), 2014-11-03 20:16:00 [1480]

Sziasztok,

Elkészült az UCCNC 1.0040-es verziója.
A letöltés: UCCNC 1.0040

Hibák javítása:

- MPG hibáinak a javítása.
- A 3D nézőkét eddig csak a fő (legfelsőbb szintű) tab oldalakra lehetett feltenni, most már bermelyik aloldalakra is.
- A körök rajzolásának a felbontás számításba került egy hiba, így nagy méretű köröknél előfordult, hogy nem rajzolta ki a kört.
- UC100-nál az enable jelek a felső biteken, a 14., 16., 17. pineken nem jól működött.
- A toolpath oldalon az FRO és SRO + és - gombok pozíciója a képernyőn fel volt cserélve.
- A run from here gombnál ha a run from here sor előtt is körív kód (g2/3) állt és ha ebben nem volt Z koordináta, akkor nem jól számolta ki az előzetes mozgás Z koordinátáját. (A Z előzetes koordináta elveszett.)
- A DRO-kból kilépéskor a jobbra/balra nyíl gombok nyomására visszaugrott a DRO-ba a kurzor, ezt letiltottam, illetve a TAB gomb kijelölős ugrálása is letiltásra került a Flash-ben.

Új dolgok:

- Hotkey-ek a ctrl + alt + shift módosító billentyűket is elfogadja, ileltve ezeket bármilyen kombinációját is.
- A tab oldalak kaptak kimeneti LED kódokat és hozzárendelhetők a kimenetekhez.

Szia,

OK, így már értem.
Az Altgr = Ctrl + Alt, vagyis két kódot is visszaad, a 17-eset és asszem a 18-asat vagy a 16-osat, most ebben nem vagyok biztos, hogy melyiket...

Előzmény: dezsoe, 2014-11-03 16:21:00 [1478]

Szia!
A sorkapocs azért is praktikus, mert a méreténél fogva elférnek a nem SMD alkatrészek is. Az SMD nekem már túl kicsi, nem látom... Persze, ha kész lesz és beválik a teszteken, akkor még mindig át lehet tervezni picire.
Az AltGr példa arra utal, hogy pl. egy funkciót a @-ra konfigolok, akkor az magyar billentyűzeten AltGr-V. Az UCCNC-ben az AltGr-ig jutsz el, kapsz egy 17-es kódot és kész. A #1434-ben már írtam, hogy ugyanígy kiesett a Ctrl-O kombináció is. (Most vettem észre, hogy a Ctrl és az AltGr egyformán 17-et ad vissza.)

Előzmény: n/a (inaktív), 2014-11-03 14:18:00 [1477]

Szia,

Jól hangzik a dolog.
A SW szűrés is nagyon jó, de hardveres is legyen benne szerintem mindenképpen 1 soros ellenállat + egy kis kerámia kondi a jel és föld közé minden bemenetre.
A panelt ha van rá mód SMD-re tervezd, ha már az olcsóságnál tartunk, akkor az olcsón akár tömeggyártható is, de kis szériában is olcsóbbak az SMD alkatrészek általában.

Talán 2 oldalt volna érdemes rakni sorkapcsokat és hosszúkásra tervezni a panelt és akkor egy alj lemezzel és egy DIN hüvellyel akár DIN sínre is kényelmesen felpattintható, sorolható lehet.

A szoftver új verziót most már tényleg hamarosan kiadjuk.
Az AltGr dolgot amit írtál azt nem teljesen értem.

Előzmény: dezsoe, 2014-11-03 12:25:00 [1476]

Szia!
Igen, HID billentyűzet lesz, megfelelő HW és SW szűréssel. Azért is várom a hotkey kezelés módosítását, amit korábban írtál, mert egy gombhoz akár AltGr-es kódot is lehet rendelni (egy fizikai gomb, de kettőt lát a gép), így a normál billentyűket lehet arra használni, amire valók, nem ütköznek a vezérlővel.
A cél az, hogy megbízható legyen, de pici-ócó alkatrészekből is össze lehessen rakni, elvégre hobbizunk.

Előzmény: n/a (inaktív), 2014-11-03 11:23:00 [1475]

Sziasztok,

Svejk: Igen, UC100-nál is használható a 48db hotkey.

Dezsoe: gondolom olyan mikrovezérlővel csinálod, aminek van beépített USB portja és HID eszközként ismerteted fel a PC-vel és úgy külöd át a billentyű kódokat?
Majd ne felejts el a bemenetekre egy-egy RC tagot felpakolni zavarszürés, áram korlátozás és prellmentesítés miatt. A pokeys megbízhatósága végülis ezen bukott el, hogy ezen akartak spórolni...
Kíváncsian várom a fejleményeket, ha alakul majd a projekt.

Előzmény: svejk, 2014-11-03 11:16:00 [1474]

Nem semmi!

Biztos vagyok benne, hogy lesz rá fizetőképes kereslet, mert azért az UC300 48 trigger bemenete is gyorsan el tud fogyni.

Balázséktól kérdezem, hogy ugye jól gondolom, hogy az UC100-hoz is használható lenne ez a 48 Softkey funkció?

Előzmény: dezsoe, 2014-11-03 10:17:00 [1472]

Bocs Úgy értelmeztem hogy el lett halasztva . Írok magánban legföljebb este látod . üdv

Előzmény: dezsoe, 2014-11-03 10:17:00 [1472]

Szia! Nem futott spam-re, elvileg #1436-ban válaszoltam is rá. Azóta annyi változott, hogy Balázs írta, hogy a Pokeys nem az igazi, így mégis elővettem a feladatot. Tegnap este próbapanelon odáig jutottam, hogy egy jobbra és egy shift már remekül működik. Már "csak" annyi van hátra, hogy a megfelelő zavarszűréssel a Svejk által kért (#1398) 48 bemenetet tudjam kezelni. Kitartás, dolgozom rajta!

Előzmény: ANTAL GÁBOR, 2014-11-03 06:26:00 [1471]

Dezsoe!A napokban ment egy mail . Lehet hogy spamra futott? Légy szives klickelj rám és adj egy elérhetőséget .

Előzmény: dezsoe, 2014-11-02 14:50:00 [1468]

Ezt a charge pump kezdeti bekapcsolást is amit leírtál megfogom hamarosan vizsgálni.

Előzmény: dezsoe, 2014-11-02 14:50:00 [1468]

Megtaláltam a hiba okát. Valóban UC100-nál nem jól volt lekezelve az enable jel a felső biteken, vagyis a 14., 16., 17. lábon csak bekapcsolni kapcsolta be és úgy is maradt, ahogy leírtad. Ezt most javítottam. A következő kiadásban már jól fog működni.

Előzmény: dezsoe, 2014-11-01 15:40:00 [1458]

Annyi haszna mindenképpen volt a hibának, hogy megépítettem egy charge pump érzékelőt, így végre nem okoznak problémát a beragadt szintek.
Megfigyeltem, hogy induláskor egy pillanatra bekapcsolja a cp-t akkor is, ha nincs bejelölve a charge pump always on. Utána már a Reset-tel kapcsolható rendesen. (Szerencsére ilyenkor már a többi jel - főleg a marómotoré - jó szinten van, így nem okoz bajt.)

Előzmény: n/a (inaktív), 2014-11-01 18:12:00 [1461]

Köszi! Az ötlet jó, de az M0/M6 előnye, hogy Cycle start-tal tudok továbbmenni.

Előzmény: csewe, 2014-11-01 20:14:00 [1466]

Tedd ezt a makróba az exec.stop helyett.

MessageBox.Show("Továbblépéshez nyomja meg az OK gombot.");

Amíg nem kattintassz a felugró ablakban az OK gombra,addig állni fog a programod futása.

Előzmény: dezsoe, 2014-11-01 19:15:00 [1465]

Előre is köszönöm!
Kicsit a #1460-hoz is kapcsolódva, már akartam kérdezni, hogy az M0 nincs tervbe véve? Most M6-tal pause-olok, de a pause az mégsem szerszámcsere. (Próbáltam M0 makróból exec.Stop-ot, de nem az igazi a kérdései miatt.)

Előzmény: n/a (inaktív), 2014-11-01 18:12:00 [1461]

Mach3 -nál csak kipróbálásig jutottam, nekem ennyi elég volt…
Mint már írtam, nekem csak pár ipari vezérléssel volt dolgom, és
Linux CNC -vel. UCCNC – is egy ígéretes Windows -os rendszernek
tűnik, és remélem így is lesz !

Előzmény: n/a (inaktív), 2014-11-01 18:20:00 [1463]

Igen, ez valóban így van, illetve Mach3-nál is így van ... próbáld ki. És az aszinkron működésből adódik, illetve a pufferelés miatt van. Vagyis mert a programnak előre látnia kell a kódsorokat az előrenézés miatt, így előre betölti azokat, a változók értéke már előre megváltozik és ha megállítod a program futását, akkor visszafelé nem lehet ezeket visszaszámolni, annyi lesz az értékük, amennyi az előrenézett programban volt.
Szóval ez a működésből adódik, mach3-nál LPT porttal is így van.
Ílletve már kitaláltam rá a megoldást az UCCNC esetében a későbbiekben meg fogjuk csinálni, hogy ne így legyen. Mach3-nál viszont így van, annál nem lehet megcsinálni, hogy ne így legyen se LPT porttal, se UC100-al.

Előzmény: fektiforg, 2014-11-01 17:50:00 [1460]

Nincsen. A profil fáhlban át kell írni a screenset file nevét ahhoz, hogy a profil azt a screenet-et töltse be, így vannak összerendezve.

Előzmény: csewe, 2014-11-01 16:18:00 [1459]

megfogom nézni mi lehet.

Előzmény: dezsoe, 2014-11-01 15:40:00 [1458]

Még egy tapasztalás részemről : paraméteres programot futtatok, futásközben ciklusstopot
nyomok ( pl. kivágás közben félrebillen az anyag és útban van, muszáj megállítani a futást)
Újra ciklusstartra összevissza, kiszámíthatatlanul „koricál” , mintha az aktuális változók
törlődnének, ez szerintem így nem jó. Más általam ismert vezérlőknél, ez a dolog csak M30
hatására történik.

Van lehetőség őj profilhoz másik screenset betőltésére,anélkül,hogy a profil file-ba bele kellene írni?

Gondom van.

UC100-am van, UCCNC 1.0039, a leírtakat az X, Y és Z tengelyen is próbáltam. Ha az Enable a 14-es, 16-os vagy 17-es lábon van, akkor nem működik rendesen. A lábat 0-ból 1-re tudja váltani, ha előzőleg 0 volt, de vissza nem kapcsolja. Független az Active low kapcsolóktól. Más lábon ezt nem tapasztalom (O1, O8, O9-en próbáltam, a többin tengely van). Először az én elektronikámra tippeltem (az egész saját tervek alapján épült, ezért minden lehet...), de miután alaposabb tesztnek vetettem alá a programot, kiderült, hogy UC100 demó módban is így megy, a diagnosztika fülön lehet nézegetni.
(Természetesen az elektronika a 17-esen negálva várja az Enable jelet...)

A Getlabel tökéletesen működik.

Én viszont tényleg olyan drot akartam felraki,amit nem tud a felhastznló módosítan,mert ccsak kijelzésre hastználnám.
Úgy tűnik,hogy lényegében már minden utasításrt értek a screenset-ben.
A makróhoz meg az UCCNC.exe file-ból lesem ki a szükséges utasításokat,bár néha kell kicsit kísérletezni,és ojkor nem találom ami kell.

Előzmény: n/a (inaktív), 2014-11-01 12:13:00 [1454]

Mint friss uc 300 tulajdonos kérdezem, hogy miként lehet egy bemenetre Pl? 1 port 15 pin
több funkciót is hozzárendelni. x++,home,y--. stb.

Igen, a ToDouble a ludas, ahogy mondod, mert egy label-t töltesz fel a képernyőre és egy input mezőt olvasol ki. A kettő fajta objektum nem ugyanaz, így nem is jön létre 20000-es számú input mező. A Getinputlabel üres stringgel ("") tér vissza, ami nem konvetálható double értékké, ezért van a hiba.

Előzmény: csewe, 2014-11-01 12:10:00 [1453]

Egyetlen probléma van csak a kóddal, a screenset-re feltöltés a probléma, nem a double string konverzió.

A Sendlabeltoscreen az egy olyan címkét készít, ami a képernyőn csak olvasható, de nem szerkeszthető, ez a fajta teljesen más, mint az input mező. Ez a fajta mezőt a Getlabel(); függvénnyel tudnád kiolvasni, nem a Getinputlabal();-el, de szerintem neked nem ilyen mező kell, hanem amit a user tud szerkeszteni a képernyőn.

A következő függvényre cseréld ki a Sendlabeltoscreent:

public void Sendinputtoscreen(string labeltext, string labelfont, string textalign, int fontsize, int fontcolor, int posX, int posY, int intextboxwidth, string type, double min, double max, int labelnumber, int parentnumber)

Például:

AS3.Sendinputtoscreen(" ", "Arial", "center", 22, 0, 100, 100 , 80, "fieldnb", 0, 300, 20000, 36);

Előzmény: csewe, 2014-11-01 11:51:00 [1452]

Mikor csak ezt a sot hagytam a makróban,akkor is megékezett a hibaüzenet,tehát tévedtem,és nem a tostring függvény a ludas,hanem a todouble:
double a = Convert.ToDouble(exec.mainform.AS3.Getinputlabel(20000));

Tehát módosul a kérdésem.
Hogyan kérdezzem le és alakítsam számmá a dro-k értékét?

Előzmény: n/a (inaktív), 2014-11-01 10:50:00 [1451]

Alap módon működik,de valódi dro kiolvasánál hibát ad.
A sreenset-ben így helyeztem el a dro-t:
AS3.Sendlabeltoscreen("1230", "Arial", "right", 25, 35535, 110, 520, 20000, 49);//

És így olvasom ki:
double a = Convert.ToDouble(exec.mainform.AS3.Getinputlabel(20000));//1.23;
string b = Convert.ToString(a);
MessageBox.Show(b);

Őgy tűnik,hogy több paraméterel kellene ellátni a "Convert.ToString" függvényt,de nem találtam elég jó példát rá.

hibaüzenet.

Előzmény: n/a (inaktív), 2014-11-01 10:50:00 [1451]

Szia, menet válasz.
Ide is bemásolom, hátha valaki mást is érdekel.
double szám konvertálása string-é makróban, példa:

double a = 1.23;
string b = Convert.ToString(a);
MessageBox.Show(b);

Előzmény: csewe, 2014-11-01 10:42:00 [1450]

Szia Balázs,ment egy levél kérdéssel.

A "Jöszi" az "Köszi" akart volna lenni.

Előzmény: n/a (inaktív), 2014-10-31 21:08:00 [1448]

Szia,

Jöszi a hibajalentést.
Azt szeretném kérni, hogy most várjátok meg légyszi a következő kiadást. Addig most felesleges MPG további bugokat jelenteni, mert az MPG-ben a hibákat éppen javítjuk és így most mégegyszer át lesz nézve teljesen. Illetve a javításnál mindent újra tesztelünk. Szóval az új kiadás ami a 1.0040-es lesz (hamarosan), majd az után kérnénk szépen újra MPG-vel kapcsolatos hibajelentéseket.

Előzmény: lari, 2014-10-31 20:49:00 [1447]

Ma a következő hibajelenséggel találkoztam.MPG gomb bekapcsolva, Kézikereket forgatva, közben a Cont. gombot megnyomva a tengely bizonyos sebességgel tovább mozog.Reset gomb, vagy a végállás kapcsoló állítja meg.

Helyes, fő a minőség!
Igyekszem mielőbb tesztelhetőt alkotni.

Előzmény: svejk, 2014-10-31 16:31:00 [1444]

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

Előzmény: n/a (inaktív), 2014-10-31 09:30:00 [1435]

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!

Előzmény: dezsoe, 2014-10-31 09:27:00 [1434]

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.

Előzmény: n/a (inaktív), 2014-10-31 10:28:00 [1441]

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.

Előzmény: xabi, 2014-10-31 06:24:00 [1433]

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.

Előzmény: dezsoe, 2014-10-31 10:18:00 [1440]

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.:)

Előzmény: n/a (inaktív), 2014-10-31 09:55:00 [1439]

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.

Előzmény: dezsoe, 2014-10-31 09:44:00 [1438]