Mint már annyiszor,ismét úgy vélem,hogy sikerült urrá lennem,ezen az ablakátméretezési problémán.
Wizards-BETA

Jobban néz ki mint az enyém.

Előzmény: nyarfa, 2014-07-28 15:55:00 [797]

Ma megint próbálgattam ,hogy tényleg jól méretezi e vissza az ablakot,mikor kilépek a vrázslóból,és ma meg nem jól csinálja,mindíg kissebbre veszi,pedig előtte meg teljesen jónak látzott.
Mégis csak kelene az a makiróból lekérdezés.
Ablak pozíciója,és mérete.

Előzmény: n/a (inaktív), 2014-07-26 21:36:00 [769]

Kicseréltem egy zip-re.

Előzmény: nyarfa, 2014-07-28 15:55:00 [797]

Köszi megkaptam.

A hiba:
- "Load" az nem "Load#13"
- "End" az nem "End "

most már megy a probléma kiküszöbölve.

A könyvtár amiben találsz egy "install" könyvtárat. Letöltés és másolás.

Várom az észrevételeket a kritikát jól bírom kezelni.

Előzmény: csewe, 2014-07-28 13:47:00 [796]

Szia,magánban megírom,hogy hogyan kell használni azt a file.

Előzmény: nyarfa, 2014-07-28 11:13:00 [794]

Szia,

Az adatcsere fájlnak nincsen köze az UCCNC-hez, szerintem Csewe ebben valami adatokat tárol a programjához, nem tudom pontosan mi lehet. Ő tudná megmondani,

A lényeg amit írtam, hogy indítsd el a programodat macro-ból a process.start-al és várakoztasd. Majd a programod ha végez, zárja be magát, ettől a macro tovább fog futni. és a macro végén a loadfile(); fgv.-el töltsd be a kódot amit a programod genetált.

Gyakorlatilag ennyit kell csinálni.

Előzmény: nyarfa, 2014-07-28 11:13:00 [794]

Ezt a részét értettem, csak az adatcsere.txt-be mit írjak és melyik sorba? Próbáltam így is meg úgy is, de nekem nem volt hajlandó betölteni, de még kilépni önmagából sem. Valamit nem jól értelmezek.

A kérdés:
Hogyan működik az adatcsere? Milyen értéket kell melyik sorba írni, és erre mit kellene csinálnia?

Teljesen összekeveredtem már tegnap éjszaka.

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

A lényeg, hogy a elkell indítani az .exe fájlodat a System.Diagnostics.Process.Start -al, és a WaitForExit-el várakoztatni kell a makrót, ez addig vár, amíg a folyamat, vagyis a programod fut.
A programod kiírhatja egy fájlba a kódot, majd a makró végén ezt be kell töltetni az UCCNC-vel, ahogy Csewe is csinálta:

exec.mainform.filenametoload = "...A fájl elérési őtja/neve";
exec.mainform.loadfile();

Előzmény: nyarfa, 2014-07-28 10:35:00 [791]

Szia,

Most olvastam, de kérlek, hogy az info at cncdrive.com e-mail címre küldjétek a leveleket, azt sűrűbben olvasom, mint amit itt sikerült beállítanom e-mailnek az adatlapomon.

Azt kérdezted, hogy hogyan lehet meghívni külső programot macróból, illetve adatot visszatölteni fájlból.

Csewe makrója erre szerintem pontos választ adhat:

//==DrillCircularBoltPattern indító makró===
int betu = 92 ;
string ut1 = Application.StartupPath.Substring(0,2);
char ut2 = (char)betu ;
string ut3 = Application.StartupPath.Substring(2);
string ut4 =ut1 + ut2 + ut3 + "/Wizards/DrillCircularBoltPattern/Drill_Circular_Bolt_Pattern_.exe" ;
string ut5 = Application.StartupPath ;
string ut6 = ut5 + ut2 + "Wizards" + ut2 + "DrillCircularBoltPattern" + ut2 + "adatcsere.txt" ;
string ut7 =ut1 + ut2 + ut3 + "/Example_codes/DrillCircularBoltPattern.TAP";
string text1 = "1";
string text2 = "2";
string s1 = "1";
string s2 = "2";
string kilep = "";
string beolvas = "Load";
//MessageBox.Show(ut7);
//______________________________uccnc elrési utvonala-------------
// System.IO.File.WriteAllText("C:"+ut2+"utvonal.txt",Application.StartupPath);
//================varázsló indítása =======
System.Diagnostics.Process proc; // Declare New Process
System.Diagnostics.ProcessStartInfo procInfo = new System.Diagnostics.ProcessStartInfo(); // Declare New Process Starting Information

procInfo.UseShellExecute = true;
procInfo.FileName = ut4;
procInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Maximized;

proc = System.Diagnostics.Process.Start(procInfo);
System.IO.File.WriteAllText(ut6, text1);
proc.WaitForExit(1000);
//===========kommunikáció===========
do
{
System.Threading.Thread.Sleep(1000);
String[] lines = System.IO.File.ReadAllLines(ut6);
System.Console.WriteLine("Contents of adatcsere.txt = ");
foreach (string line in lines)
{
kilep = line;
if (line == s1)
{
System.IO.File.WriteAllText(ut6, text2);
//MessageBox.Show(line);
}
if (line == s2)
{
System.IO.File.WriteAllText(ut6, text1);
}
if (line == beolvas)
{
System.IO.File.WriteAllText(ut6, text1);
//MessageBox.Show(line);
exec.mainform.filenametoload =ut7;
exec.mainform.loadfile();
}
}
}
while (kilep != "End");
System.IO.File.WriteAllText(ut6, text1);

Előzmény: nyarfa, 2014-07-28 10:35:00 [791]

Írtam levelet olvastad?

Előzmény: n/a (inaktív), 2014-07-28 09:06:00 [790]

Sziasztok,
No, megnéztem egy másik programot hogyan működik a szubrutin hívás és ennél is ugyanúgy mint a mach3-nál, úgyhogy átírtam az UCCNC-ben is, hogy ugyanígy működjön. Így talán nem zavar majd össze senkit, mert nem különbözik a viselkedés.
Talán ezeknél a kezdeti teszteknél egyszerűbb így.
Ha esetleg a későbbiekben mégis a másik viselkedés lenne szimpatikusabb, akkor vissza lehet majd írni viszonylag egyszerűen...

A szerszámpálya számoló kódon is faragtam, optimalizáltam, most a "fakaspó" kódot hosszabbra véve (50 fogás) a Mach3 az én gépemen 2.33 perc alatt végzett. Az UCCNC 1:12. A processzorhaszálatot is néztem, a Mach3 átlagban 32%-ot, az UCCNC 40%-ot használt.

Ma még bütykölök pár dolgot, este felé majd feltöltöm az új verziót.

Előzmény: elektron, 2014-07-27 18:20:00 [785]

Azonos paraméterek mellet UCCCNC 3:15, amásik 1:00.
Persze az első próbánál még másképp futott a kó a két programon,de azóta kijavítotam.

Előzmény: n/a (inaktív), 2014-07-27 22:38:00 [788]

Csináltam egy tesztet a "fakaspó" kóddal amit küldtél, a képletfeldolgozás/szerszámpályagenerálás sebességet vizsgáltam.
Nálam 20 hullám, 5 alkatrész, 20 fogás 1.05 perc alatt dolgozza fel az UCCNC.
A Mach3 ugyanezt 1.01 perc alatt.
Az UCCNC ennél a tesztnél így 3.9%-al volt lassabb.
Majd még optimalizálok rajta.

Előzmény: csewe, 2014-07-26 14:25:00 [756]

OK, bár C#-ban a statikus annyit tesz, hogy nem példányosítható. Nincs köze az érvényességi körhöz, az a public és a private.
Lehet egy változó egyszerre static és public, ill. egyszerre static is private.

A szót egyébként nem programozói környezetben akartam volna használni, csupán arra szerettem volna utalni, a statikus-al, hogy egyszer felvett egy értéket és utána már nem változik. Illetve a dinamikussal, hogy bármikor változtathat értéket. Ahogy a Magyar nyelvben értelmezve vannak ezek a szavak.
Lehet a szóválasztás tényleg nem volt a legjobb...
Na de nagyon elkanyarodtam az eredeti témától és nem akarok Grécsi tanár urat játszani.

És köszönöm a véleményedet a témában, remélem hamarosan mások is írnak valami véleményt.

Előzmény: isvarga, 2014-07-27 18:36:00 [786]

Nekem csak annyi a gondom ,hogy továbbra is egy olyan szóval magyarázod az elérő viselkedést aminek semmi köze hozzá.(statikus - dinamikus)
Számomra ez csupán a változó érvényességi körének kérdése , vagy még annyi sem.
Lehet például ,hogy a mach inline módon fordítja a szubrutin hívást.
Számora is a mostani megoldás a szimpatikusabb.

Előzmény: n/a (inaktív), 2014-07-27 16:52:00 [781]

Egy pár kapcsolóval lehet váltani a különféle szabványok közt, valami setup ablakban és akkor mindenki azt használja belőle amit akar.

Nagy ötlet! Ott a pont megint.

Bár félek nagyon eltérünk a végén a "kompatibilisség" alapelvétől. Az találom rossznak ebben a dologban, hogy ha nagyon program specifikus G kódokat fogunk kreálni, akkor másokat megviccelhetünk akik nem ezt a programot használják. Persze a többség nem képleteket használ, hanem konkrét legenerált utakat. Nem is ismerek olyan CAD/CAM programot ami képleteket gyárt.

Előzmény: csewe, 2014-07-27 18:00:00 [782]

Én amondó vagyok,hogy maradjon így ahogy van.
Puszta véletlen volt,hgoy később is ugyan azt a változót alkalmaztam,más feladatra,nem szoktam ilyet csinálni,csak mivel külön sorba kellett írni az értékadásokat,hamar átírtam,és így sikerült kétszer ugyan azt a változót más más feladatra használnom.
Majd odafigyelek jobban.

Előzmény: n/a (inaktív), 2014-07-27 16:49:00 [780]

Ez nagyon klassz,akkor lehet 'While' ciklust csinálni.

Előzmény: n/a (inaktív), 2014-07-27 16:16:00 [774]

Még annyit, hogy a Mach3 az első megoldást, vagyis a statikus viselkedést csinálja. Én egyébként ezt látom a rosszabik megoldásnak, mert így némileg csorbul a programozó (mármint aki a G-kódot írja) szabadsága.

Előzmény: n/a (inaktív), 2014-07-27 16:49:00 [780]

A kérdés rövidre fogva és a tőlem telhető legrövidebben megfogalmazva:

Ha egy alprogramot meghívunk M98 P.. L.., ahogy az L paraméter egy változó. Akkor az első híváskori L számszor hívjuk meg az alprogramot és ne vegyük figyelembe, ha az L paraméterben megadott változó menet közben megváltozik.
Mintegy statikusan viselkedjen?

Vagy pedig vegyük figyelembe ha az L változik és akkor a hívások száma is dinamikusan változzon ahogy a változó értéke megváltozik.

Ezt kellene eldönteni, mert nem egyértelmű számomra, hogy melyik a jobb megoldás.
Mindkettőben látok előnyt is és hátrányt it.

Előzmény: isvarga, 2014-07-27 16:37:00 [778]

Köszi, értem amit mondassz, de nem igazi veremről beszélek. Csak a szemléltetés kedvéért írtam vermet. Ez végülis egy Lista. A lista tulajdonképpen egy olyan tömb, aminek a mérete gyorsan dinamikusan változtatható. Elemek egyszerűen kiszedhatők és berakhatók. Nagyjából úgy mint egy veremnél a .push és a .pop utasítással.

Szóval ez nem egy igazi verem, csak egy lista, amit úgy kezelünk, változtatunk, mintha egy verem volna. Vagyis csak a kezelés logikája teszi olyanná, mintha egy verem volna.

Amikor M98 hívás történik, akkor a hívó program sora bekerül a listába (veremszerűségbe), mintha egy .push utasítás lenne. Amikor M99 hívás van, akkor a legutolsónak berakott elemet kiolvassuk és töröljük a listából. Mintha egy .pop utasítást hajtanánk végre egy vermen.

Egyébként C#-ban van statikus és dinamikus változó is.

Előzmény: isvarga, 2014-07-27 16:37:00 [778]

Talán nem gond , hogy jelzem.....
statikus változó a veremben (stack),
dinamikus változó a kupacon (heap) jön létre.
Gondolom a C# -ban is a java-hoz hasonlóan csak dinamikus változó van . (gondolom a garbage collector miatt)

Előzmény: n/a (inaktív), 2014-07-27 16:16:00 [774]

Kérnék véleményeket, hogy ki szerint melyik a helyes megoldás?

Ha az L paraméter változást figyelembe vesszük?
Vagy ne vegyük figyelembe?

Mindkét megoldás megvalósítható, de a kérdés, hogy melyik a jó/jobb?

Előzmény: n/a (inaktív), 2014-07-27 16:26:00 [776]

Szerintem egyébként az a helyes ahogy az UCCNC kezeli ezt a dolgot.
Amikor az M99-el visszatér a program végrehajtás az M98-ra akkor szerintem mindig figyelembe kell venni az 'L' paraméter értékét. Ha menet közben a program változtatta, akkor azt kell végrehajtani szerintem.
A Mach3 nem így csinálja, ha változik a paraméter, ha nem, akkor is az első híváskori értéket veszi figylembe. Szerintem nem így kéne...

A kódban amit küldtél egyszerűen megtudod oldani, hogy jól működjön, úgy, hogy az első M98 hívásánál az L paramétere egy másik változó legyen, ami nem változik a program futása során.
Például így:

#903 = #902
M98 P1 L#903

Előzmény: csewe, 2014-07-27 13:54:00 [773]

Szia,

Megnéztem a kódodat.
Az a gond, hogy a #902 változó szerepel az első M98 hívás L paraméterénél. Menet közben a programod változtatja a #902 változó értékét.
Első hívásnál a #902 értéke 5, viszont a program végrehajtás során felmegy egészen 10-ig.

Az UCCNC-ben az M98/99 úgy működik, hogy egy verembe kerül eltárolásra a hívások száma és mindig a hívó M98 'L' paraméterével kerül összehasonlításra egy számláló, amit minden hívásnál növelünk.
Így a változó bár először 5 értékű, de menet közben a programban változik, mikor visszatér az M99-el erre az első hívásra akkor a végén már 10 értékű az L paraméter (#902) és ezzel történik az összehasonlítás. Így összesen hiába van mondjuk 5db kör beállítva, 10-szer hívódik meg az alprogram.
Nem tudom mennyire érthető amit írok?!

Szerintem a Mach3 valahogy máshogy kezelheti az alprogram hívás számlálást, gyanítom, hogy fixen elmenti a hívások számát.
Az UCCNC-ben ez dinamikus és ha változik a paraméter menet közben, akkor azt figyelembe veszi.

Előzmény: csewe, 2014-07-27 13:54:00 [773]

Email elment.

Szia, OK, várom a kódot e-mailben, ha megkapom, akkor debuggolom...

Előzmény: csewe, 2014-07-27 13:38:00 [771]

Valami még mindíg nem az igazi,bár már nem az acos lessz a ludas.
Most ilyen lett.
Tíz kör helyet,legalább huszat csinált.
De a másik programban,ha husz kört csinálok,akkor sem így náz ki.
Küldöm a kódot emailban.

Előzmény: n/a (inaktív), 2014-07-26 14:27:00 [758]

Elkészült az UCCNC 1.0026 verziója.

Az újdonságok, módosítások:

1.) Arkusz szögfüggvények javítása.
2.) Elkészültek a G92/G52 átmeneti eltolások.
3.) Az M98 szubrutin hívásnál, ha az L paraméter értéke 0, akkor most már nem hívja meg az alprogramot, javítás.

Előzmény: n/a (inaktív), 2014-07-26 21:36:00 [769]

Szia, elkezdtem próbálgatni az új verziót.
A kliens ablak mérete most jó lett.
Egyelőre hibát nem látok, de még nyüstölöm, tesztelgetem.

Előzmény: csewe, 2014-07-26 17:24:00 [762]

Miattam ne fáradj vele, főleg ha a többieknek és Neked megfelel az eredeti.

Előzmény: csewe, 2014-07-26 19:52:00 [767]

Akkor maint időm engedi,készítek ilyen külsejű verziókat is,aztán ki ki azt használja,amelyiket akarja.

Előzmény: svejk, 2014-07-26 19:49:00 [766]

Nekem egyértelműbb, igen jobban tetszik.

Előzmény: csewe, 2014-07-26 19:35:00 [765]

Igen,mert közben felhívtáka figylememet néhány hibára,de abbana verzióban nem javítottam ki ezeket.
Így nézne ki.

Előzmény: svejk, 2014-07-26 19:21:00 [764]

Eltűnt a file.
visszavontad?

Előzmény: csewe, 2014-07-25 20:24:00 [750]

Köszönöm Nagaoka az alapos tesztelést,a továbbiakban is szólj kérlek,ha találsz valami hibát.

Előzmény: nagaoka, 2014-07-25 23:50:00 [751]

Mégsem win api bug.
Ti húztatok csőbe :=)
Az ablak mérete ugyanis nem az ablak mérete,hanem a kliensé.
Át kellett írnom,az ablak pozícióa az ablaké,de a méret a kliensé.

Itt vannak az új verziók,rmélem már nem lessz bennük hiba.
Wizards-BETA

Előzmény: n/a (inaktív), 2014-07-26 16:36:00 [760]

értelmezési tartományt akartam írni...

Előzmény: n/a (inaktív), 2014-07-26 16:36:00 [760]

Volt egy ilyen sejtésem, hogy befejezetlen kód lehet az m19999, mert a .exe fájlt elindítottam és láttam, csak félig van kész.

Az átméretezést majd megnézem, hogy miért nem megy makróból, valahogy biztosan meg lehet majd oldani.

Megnéztem az acos fgv.-t és valóban nem jó, sőt egyik arkusz függvény sem. Csak mechanikusan másolgattam a függvényeket, nem vettem figyelembe az érték készletet ... hamarosan javítani fogom.

Előzmény: csewe, 2014-07-26 14:34:00 [759]

az m19999 véletlen maradt benne,próbáltam egy választóablakot csinálni,de nem felyeztem be.
Az átmértezés/viszaméretezési hibát én is láttam,de nem tudok vele mit kezdeni.
Elmentem átméretezés előtt az abalk adatait eg TRect tipusu változóba,és hozzá sem nyulok,míg visza nem kell állítani,ekkor ugyan azzal a változóval visszaállítom,és mégsem ugyan akkora lesz.
Már ptóbáltam kimenteni belőle egyes váltoókba is,de az sem segített.
Ez talán egy win Api bug lehet.
A makróból viszont nem tudom átméretezni.

Előzmény: n/a (inaktív), 2014-07-26 14:25:00 [757]

OK, köszi, le fogom ellenőrizni az acos függvényt.

Előzmény: csewe, 2014-07-26 14:23:00 [755]

Szia,

Tesztelgettem a wizard új kiadását, most úgy néz ki jól működik a circular pocket Tibor paramétereivel is.
Amiket észrevettem hibának tűnő dolgokat:

1.) Előfordul, hogy amikor kilépsz exit-el a wizard-ból utána az UCCNC ablakját nem jól méretezi vissza, úgy látom, hogy nagyobbra hagyja mint amekkora a wizard meghívása előtt volt.

2.) Az M19999, a választás makró nálam nem működik, script hibát jelez az UCCNC. Elég hosszú a kód, így nem volt még időm átnézni, hogy hol lehet a hiba a benne, de lehet te rögtön tudni fogod.

Előzmény: csewe, 2014-07-26 12:22:00 [754]

Ja,és tízszer annyi ideig számolja a pályát,mit a másik program,bár ez nem hiba.

Előzmény: csewe, 2014-07-26 14:23:00 [755]

Kipróbáltam egy kódot,amiben
abs
acos
cos
sin
függvényeket használok,és az 'acos' szeritnem nem úgy működik,ahogy kellene.


A körbefutó hullámos vonalak osztókörét számolja az 'acos' felhasználásával.
Tíz kör helyett,cask egyet rajzol ki,illetve valósznű egymásra rajzolja.
A G kód minden sorát értelmezi,nem pirosít ki semit.

Köszönöm,hogy ilyen alapossan teszteled a varázslókat.
Kijavítottam,és aátnéztema másikakat is,és lekezeltem bennűk a hasonló eseteket.
Wizards-BETA

Előzmény: nagaoka, 2014-07-25 23:50:00 [751]

Egy kis teszt relief marás UCCNC-vel:

Előzmény: n/a (inaktív), 2014-07-26 00:56:00 [752]

Szia Tibor,

Érdemes volna ilyenkor a kódot, vagy kódrészletet megmutatni.
Kipróbáltam amit mondtál, Circular pocket: 20mm, szerszám 10mm, átfedés 50%.
Valóban erre rossz kódot generál a wizard.
Kód részlet:

G0 G49 G17 G40 G50 G80 G90 G94
M6 T0(TOOL DIA.10)
G21 (mm)
M3 S1000

G0 Z1
X0 Y0
Z0
G1 Z-2 F100
Y0 X5 R3105930
Y0 X-5 R5
Y0 X5 R5
G1 X0 Y0
G1 Z-4 F100
Y0 X5 R3105927,5
Y0 X-5 R5
Y0 X5 R5
G1 X0 Y0
G1 Z-6 F100
Y0 X5 R3105925
Y0 X-5 R5
Y0 X5 R5
G1 X0 Y0
G1 Z-8 F100
Y0 X5 R3105922,5
Y0 X-5 R5
Y0 X5 R5
G1 X0 Y0
G1 Z-10 F100
Y0 X5 R3105920

Az látszik, hogy hatalmas rádius-t generál és a G2-t lehagyja a sor elejéről.
Értelemszerűen ezt az UCCNC nem tudja végrehajtani, mert szakaszoknak van rádius deklarálva.
Megjegyzem ezt a mach3 sem tudja végrehajtani, a kód értelmetlen a szakasz->rádiusz megadása miatt.

Előzmény: nagaoka, 2014-07-25 23:50:00 [751]