Közbe arra jutottam, hogy a G-kód generálásánál X-Y és A-B tengelyekre érdemes generálni a két profilt, így a Mach legalább az egyik oldalit helyesen fogja megjeleníteni (X-Y)!

Előzmény: SquirrelTech, 2009-05-01 00:58:00 [359]

Ezt sajnálattal olvasom (csak reménykednit utdok, hogy nem én voltam a kedvromboló)!

Előzmény: n/a (inaktív), 2009-04-30 23:03:00 [358]

Szia Géza!

Folyamatban van nálam, illetve próbálok egy rugalmasabb megoldást kieszközölni erre. Nem feltétlen csak az általad említett ok miatt, de egyelőre nem lesz publikálva.

Sziasztok!
Csak annyit, hogy én több mint egy éve közreadtam egy olyan saját (primitív, de futó) habvágó progit, melynek segítségével Dat szerű formában megadott szárnyprofilokat, habfigurákat lehet vágni. igaz csak 2 D-ben. Megcsináltam ugyan a 2D 2D változatot is de érdeklődés híján annak és az egész téma fejlesztésével leálltam. Valakitől ui. még kioktatást is kaptam, hogy sokkal jobb progik vannak. Persze pénzért.....

Még annyi, hogy .NET alatt oda-vissza lehet VB és C# kódot átalakítani, a fejlesztőrendszer támogatja.

A megvitatás alatt azt értem ,hogy így sok év után egységesítsük ezt elsőként és akkor próbáljunk meg egy közös nyelvet használni...
Legyen mondjuk egy a "fórum által preferált nyelv" és akkor az legyen is eztán fix...

Igen, azt hiszem így lesz. (Újra) belekezdek. Párszor már belekezdtem (delphiben), de szükségem van és lesz is segítségre.
Ilyen projekttel minden körülmények közt is legjobb csak holtidőben foglalkozni...
Mi az általatok támogatott nyelv?
A VB részemről nem lenne gond, de inkább a C#-ot javallanám.
(Ám akár ez már most megvitatható, hogy mi legyen)

Én sajnos a C++-t (és magár a PC C-t) nem ismerem/használom. Csak VB6-ban szoktam prograsmozni (erre a feladatra bőséges lenne ez is). Mivel jelentős elfoglatságom van, ilyen projectet csak nagyon-nagyon holtidőben tudnám végezni.
Én ha belekezde(né)k, bitos VB6 alapon és mindnet magam végezné, majd a rész forrást közzétéve várnám mások módosítását, fejlesztéseit, amit beintegrálva vinném tovább.
A teljes "demokráciában" könnyen káosz lenne, muszály valamilyen irányba terelni a dolgokat.

Ha gondolod, kezdjél bele és ha közzéteszed (álatalunk is támogatott/ismert nyelven), akkor időről-időre bővíthetjük, javítgathatjuk! Szívesen teretadok neki a weblapon és a Fórumon is!

Előzmény: SquirrelTech, 2009-04-29 15:13:00 [350]

A személyedről őszintén? Elsőre valóban visszataszítónak tűnt, másodjára már persze nem annyira, de ezt magad is jól tudod, hogy az ilyen fórumokon döntő többségben ez nem így szokott alakulni.
Én a magam részéről (másik topikban tapasztaltak) teljességgel visszakoztam, beismerve a tévedésem, hogy a fától nem láttam az erdőt (és nem te voltál a fa). Többet erről nem óhajtok regélni.
Dógozzunk' inkább valamit...

Ilyen együttgondolkodás félét én is javasoltam.
Gondolom a személyem miatt el sem kezdődött a dolog.
Én ennek csak örülni tudok.
Egy másik próbálkozás hátha eredményre vezet.

A felvázoltakról, kivételesen megtartanám a véleményemet.

Előzmény: SquirrelTech, 2009-04-29 15:13:00 [350]

Szerintem én eddig sem vittam, hogy használják.
Mivel, mindenre jó, ezért igazán kényelmes alkalmazást nehéz összehozni vele.

Egyáltalán nem vagyok benne a szárnytervezésben. Ezért csak saccolom, hogy egy G-kódú program, csak G01-ek végtelene. Tehát, nem egy nagy durranás.

Előzmény: SquirrelTech, 2009-04-29 14:25:00 [349]

Magát a programot külön alkalmazásként megírva, ezt az ötletet támogatnám én is leginkább.

A tapasztalataim elég sokrétűek ennek kapcsán, amit most megpróbálok összefoglalni.

Nyelvek:

Nem csak a kommentek fontosak, hanem a nyelv támogatta modularitás is. Ha külön modulokba, library-kba szervezhető a program vagyis az őt építő "kövek", akkor az egész program áttekinthetőbbé, szervezhetőbbé válik.

Elmehetnénk addig a bizonyos "az igazi programozó" c. írásig, hogy mi jó s mi nem jó, de azt hiszem leszögezhetem: nem vagyunk programozók . Hogy ettől még csináljuk, vagy csinálni akarunk ezt-azt, ez más területeken is magától értetődő...

Konkrétan a nyelvekről:
Alacsony-, Magas szintű, strutúrált, struktúrálatlan, obejktumorientált, 4...5. generációs... Lassacskán ahogy az életben egy beszélt nyelv kihal, 5 új programnyelv jön létre helyette az informatikában (vagyis kb. hetente v. naponta). És mégis ugyanarról szólnak mint az összes többi: nagyon erős valamiben (nagyon erősen támogat valmit) és nagyon gyenge valami másban. Ekkor persze csak a nyelv filozófiáját néztem, mert ott van a program írója is, fontos az is hogy ő miből mit tud kihozni.

Kód visszaovlasása:
Kiemelhetnék egy Perl nevű nyelvet - amit hívnak szintaxissal nem rendelkező nyelvnek is. Szeretik, alkalmazzák, de ennél a leggyakoribb gyakori, hogy az adott programot a program íróján kívül más nem tudja elolvasni (vagy később ő maga sem, esetleg egy Perl-guru).

A fórum vagyis a mi tekintetünkben:
Az elmúlt években én azt a megállapítást tettem, hogy lenne a fórumtársak részéről is jócskán kedv az alkotásra, de pont etéren esik szét a dolog. VB, Delphi (object pascal), C, Assembly... Sokan sok féle módon sok jó dolgot csinálnak. De ha ki lehetne találni erre valami egységet, akkor még ennél is jobbakat lehetne.
Azért írom ezt ennyire feltételesen, mert erre is számos (de lehet számtalan) lehetőség kínálkozna. Ragozhatnám...

Leírom ehelyett, hogy én mit gondolok erről, vagyis, hogy miként lenne ebből projekt.
Lehetőség szerint legyen minden kikötve és definiálva és hogy ki mely feladatokat vállalja (melyik modulnak ki a gazdája). Következeetesen az egész gyakorlatilag egy 0-t képző vázra épüljön, modulokból. "Központilag" legyen menedzselve és dokumentálva a dolog. Csakmert "én itt egy pici ezt, te ott egy picit azt" és az egész nagyon hamar szét is esik...

Válasszunk egy közös nyelvet.
Javallat szerűen C#.
(ezért csillant fel a szemem korábban a FoamCutter-en is)
Sorolva a miértjeit:
- Néha csodásan, néha borzasztóan ötvözi a C, a VB a Delphi és a Java nyelvjárásait.
- Támogat mindent. (Talán windows driver fejlesztést nem, de ami késik...)
- Ingyenes a fordító és a fejlsztőkörnyezet is.
- Moduláris, meseszép komoponensek is vannak hozzá és fejleszthetőek is benne.
- Akik itt vagyunk, szerintem kb. egyformán beszéljük illetve nem beszéljük ezt a nyelvet, úgyhogy kb. mindenkinek egyforma erőfeszítést jelentene bővíteni az ismereteit etéren. A C jelölés meg ne vezessen félre senkit, mert ez már messze nem C nyelv

Így szerintem mindenki hozzá tudná tenni a magáét.

A műszaki élet során számtalan esetben használatos az excel pl. adatgyűjtő rendszerek klienseként (data acquistion) még a legmenőbb cégeknél is. Rengeteg a neten fellehető szárnytervező, -elemző munkalap is. Ezek után g-kód output sem hangzik szerintem túl elrettentően...

Előzmény: n/a (inaktív), 2009-04-29 08:43:00 [339]

Ez a .dat fájl dolog még valamikorra a hőskorra vezethető vissza. Amikor pl. Eppler profersszor és társai is már számítógép irányába fordultak, de még ezt fortran nyelven tették. A fortran esetében magától értetődő volt a lyukszalag, és ez a .dat fájl esetén is látszik .

Előzmény: n/a (inaktív), 2009-04-29 07:12:00 [337]

Igen, rájöttem az éjszaka, hogy teljesen rossz irányba indultam el! Vagyis én arra jutottam magamban, hogy az F érték mindig a legnagyobb (leghosszabb) paramétert kapott tengelyre érvényesül.
A mach grafikus megjelenítése sokszor egy 10 soros G-kód esetén is képes elég érdekes képet produkálni. Az S érték az tiszta és minden szempontból adott.
Részletektől mentesen írom ezt, de a körítésekkel is adódhat jó sok probléma.

Előzmény: n/a (inaktív), 2009-04-29 07:05:00 [335]

Úgy látom az eddig talált legkomolyabb modeltervező sem tudja azt amit mi szeretnénk (csak 3D frofil konturmarásra képes G-kód szinten)!

Compufoil 3D

Eddig úgytűnik lenne értelme egy ilyen programnak (2D+2D G-kód konveráló)...

Egy szárnyprofil DAT file formátuma:

CLARK Y AIRFOIL
1.000000 .000599
.987006 .003678
.966920 .008408
.946295 .013187
.925289 .017938
.904009 .022631
.882540 .027250
.540183 -.017485
.561775 -.016692
.583370 -.015900
.604966 -.015107
.626562 -.014314
.648158 -.013521
.669753 -.012728
.691346 -.011935
.712936 -.011142
.734521 -.010349
.756098 -.009557
.777662 -.008765
.799207 -.007973
.820723 -.007183
.842195 -.006395
.863601 -.005609
.884907 -.004826
.906066 -.004049
.927006 -.003280
.947633 -.002522
.967816 -.001781
.987384 -.001063
1.000000 -.000599

Így már én is jártam, szürnyű! Azóta kicsit jobban kommentálok (magamnak).

Előzmény: n/a (inaktív), 2009-04-29 09:20:00 [343]

Ezzel csak egyet lehet érteni.
Biztosan butaság, de jártam már úgy, hogy saját, néhány éve írt forráskódomat kénytelen voltam félre tenni és elölről kezdeni, mert nem volt kommentezve és nem voltam képes felvenni a fonalat.

Előzmény: n/a (inaktív), 2009-04-29 09:06:00 [342]

Megmondom őszintén, ha valaha is belefogok egy ilyen projectbe, akkor 0-ról indítom, mert nekem sokkal több idő és energia egy meglévő forráskód megértése, mint magamtól megírni valamit. Teljesen belekel érezni ilyenkor a szerző logikájába és ez néha lehetetlen (főleg hiányos kommentek esetén, nem azonos tudásszint mellett).

Előzmény: n/a (inaktív), 2009-04-29 08:59:00 [341]

Persze, hogy nem ingyenes.
Csak néha annak látszik, mert ha már úgyis megvan…
Az Office-t megveszi az ember, mert az mindig kellhet. Minden ami több, mint szövegszerkesztés, táblázatkezelésen felül van, már „ajándék”.

Valóban fából vaskarikának tűnik. Csak tippelni tudok, de szerintem úgy indulhatott a dolog, hogy eleinte csak számolásra használta az Excelt. Később rájött, hogy az adatokat „közvetlenebbül” is tudná hasznosítani. Aztán úgy megszokhatta, hogy neki már „így esik kézre”.
Egyáltalán nem biztos, hogy így volt.

Ahogy írtad, megvan a forráskód. Gondolom, azzal azt kezdesz, amit akarsz. Tovább tudod fejleszteni VB-ben is, ha úgy kedvezőbbnek látszik.

Előzmény: n/a (inaktív), 2009-04-29 08:48:00 [340]

Igen. Szerencsére ismerem (valamilyen szinten) a VB-t (VB6-ban írok minde Win32-es alkalmazásaimat), ezért is inkább ebben gondolkodnék, mint wizárdban (melyett szintén VB-ben kell programozni).
De az Exeles "fejlesztői környezet" nekem akkor is fából-vaskarika (ez sem ingyenes, és nem erre lett optimalizálva).

Előzmény: n/a (inaktív), 2009-04-29 08:43:00 [339]

„Hát mitmondja? Ilyet még nem láttam!
Exel-el CNC-t vezérelni 2D+2D-ben?! „

Valójában semmi egetverő nincsen benne.
Ettől még az ötlet eredeti.
Az Excel makró nyelve a Visual Basic, mint az Autocad-é is és sok más alkalmazásé.
Annyi a szerepe az Excelnek, hogy az a fejlesztői környezet.
Az Excelt elhagyva, csak simán VB-ben kényelmesebb a dolog.
Persze, ízlések, pofonok …
Akinek sikerül levetkőznie a Basic iránti előítéleteket, meglepően tágas, szép, új világba léphet.
Ugyan úgy lehetne Pascal, vagy bármi is a makró nyelv, csak elhatározás kérdése.

Az Autocad-ban sem egy nagy mutatvány egy makró, ami kigyűjti a pontlistát. Esetleg egy G-kódú programot is generál hozzá. Ciklusokkal, meg mindenfélével.
Néha csinál magának az ember ilyet saját használatra. Ugyanis a belé fektetett munkát senki nem akarja megfizetni.

Előzmény: n/a (inaktív), 2009-04-27 12:30:00 [273]

Esetleg, ha valaki tud, ismer free .dat bemenetű(modellező) CAD programot aminek van szabványos G-kód kimenete, az jelezhetné (így ezt használnánk és nem kezdenénk bele egy esetleges fejlesztésbe feleslegesen)!

Pontosan! Ez egy "primitív" és így jól adaptálható forma! Kár, hogy nincs közvetlen .dat-G-kód szerkesztő (illetve van a lentebb belinkelt CAD program, de az meg fizetős).

Előzmény: Balu, 2009-04-28 21:03:00 [330]

A lényege az lenne, hogy a modellezők által használt össze profil és törzs szerkesztő CAD program használható (file importálható) lenne a Mach3 részére (mivel a Mach3 motorkezelését és egyéb szolgáltatásait egyik modelvágó program még meg sem közelíti)!
Így kapcsolat lenne a modellezők .dat és egyéb file-jai és a Mach3 között (magyarul a JediCut felület és a Mach3 motorkezelés között)!

Előzmény: svejk, 2009-04-28 19:26:00 [325]

Húúúúúú! Messze túlkomplikálod!
Az eltérő sebességekkel (szárnytő és szárnyvég), minek foglakozól?! Ezt remekül megoldja a Mach lineáris interpolátora!
Pont az a lényege ezeknek az egyszerű technikáknak, hogy a két profil ponthalmaza számszerüleg megeggyezik, csak a profol mérete (vektor szorzói) változnak vagy/és a pontok helyei (profil alakja, helye). Ezért egy G-kódsorban leírható az összetartozó és időben egyszerre elérendő koordináták! A lényege, hogy a megadott pontba mindkét vége egyidőben érjen a vágószál (ezt végzi el a lineáris interpolátor). A G-kód sor elején F-el beállítod a vágási sebességet, S-el a PWM-es fűtés értékét (ha használod), oszt mehet a vágás G1-el!
Szerintem ez pofon egyszerű, itt inkább a két profil (X-Y és Z-A) grafikus megjelenítése gond (csak a Z-A), mert a Mach3 erre nincs alapból felkészítve (illetve ezeket máshogy értelmezi). Ezért most már inkább egy különálló VB programba gondolkozok, ahol én ábrázolom a grafikát és a program kimenete szabványos G-kód lenne (ezt a Mach3 csak végrahajtaná 4 tengelyen és kész)!
Ami plusz munka (de ez sem nagy durranás) a körítések megírása (belépő vágási magasság+hossz, törcs kezelés, sűlyesztékek vágása a profilba, stb.), ez már csak koordináta és file kezelés kérdése.

Előzmény: SquirrelTech, 2009-04-28 19:12:00 [322]

És nem csak sárkány meg heli... Itt pislognak rám eléggé elanyátalondva pl. a csörlő alkatrészei is, hogy nagyon szeretnének már összeállni egy egységgé...

Szia Géza!

Az MHSZ-es újságokra céloztam én is a hozzászólásomban. Annyit volt módom látni, hogy milyen leépülés ment végbe a Cavalloniban - és ez csak az elmúlt másfél évtized. Benedek Gyuri bácsival soha egyetlen egyszer sem (!) sikerült összefutnom - és sajnos többé már nem is fogok...
NACA többszáz oldalas kiadványait beszkennelték és föltöltötték a netre, nagyon hasznos dokumentumok, de enyhén tömények is egyben.

Akinél ilyen aggyuram' mód kezdődik a modellezés, azoknál általában az első repítés követte első töréssel be is fejeződik ugyanilyen tempóban. De mondhatom erre, hogy ez rendjén is van így...?
HHH-n slusszba már le vannak tiltva a kibicek mert veszélyesnek minősítették őket a levegőben tartózkodókra. Sokszor valóban azok.

Én még anno IGRA építődobozokkal kezdtem.

Előzmény: n/a (inaktív), 2009-04-28 21:23:00 [332]

Szia Tamás!
Pedig nagyon sok ilyen könyv van. Én csak tudom, mert már 50 éve modellezek. A régi profilok gyüjteményét a hajdani MHSZ kiadványaiban ill. könyveiben találhatod meg. ( itt szerepelnek a legendás magyar Benedek és egyéb külföldi pl. Jedelsky profilok). Sajna Ti újabb srácok már jóformán nem is tudjátok, hogy idehaza milyen pezsgő modellező élet folyt ill. folyik még ma is mindenféle támogatás nélkül és, hogy a magyarok a különféle világversenyeken milyen nagy sikerrel szerepeltek ill. szerepelnek még ma is, főleg az un. szabadonrepülő kategóriákban. Az új profilokat (NACA, EPPLER, Girsberger, Hepperle, stb.) pedig pl. a német MTB (Modelltechnik Berater) füzetek írják le. Azaz a modellezés nem ott kezdődik, hogy van egy rádióm amihez sárkány ill. heli kell amit megveszek, hanem ott, hogy van némi anyagom és abból modellt építek.....

Előzmény: SquirrelTech, 2009-04-28 21:10:00 [331]

Szíves s örömest forgatnék profillal foglalkozó könyveket a kezemben, de sajnos egy sincs, sőt még látásból se találkoztam itthon ilyennel.
A NACA pdf-jei fellelhetőek a neten, azokban már elég sokat kotorásztam, de esetleges hazai kiadású íráshoz (egy-két folyóiraton kívül) még nem volt szerencsém.

Előzmény: Balu, 2009-04-28 21:03:00 [330]

A .dat fájl szabvány a hagyományos szárnyprofil leírásból ered! Annak idején amikor még híre hamva sem volt a habvágó cnc-nek, ugyan ilyen számsor alapján szerkesztettük ki a profilt! A szárnyszelvény hosszának százalékában van megadva a felső és alsó ív! Ennyi az egész, ha megnézel egy profilkönyvet ott is így lesz leírva, így könnyen meg tudod csinálni bármely profilt akár dat fájlba.

Előzmény: SquirrelTech, 2009-04-28 19:12:00 [322]

Nem voltak azok fölöslegesek...

Ja,ha hobby akkor egy szót sem szóltam, azt is csak halkan )
Ej de sok fölösleges dolgot összeforrasztottam már én is életemben...

Előzmény: SquirrelTech, 2009-04-28 19:34:00 [327]

Szoftveres szempontból? Miért kéne versenybe kelni egy olyan team-mel ahol jólfizetett programozók hivatásszerűen foglalkoznak ezzel? Magam részéről ezt játéknak tudom be, ahogy más a keresztrejtvéynfejtést.

Hát elsősorban a párszáz esetleg párezer dollár árkülönbséggel biztos hogy jobb lenne + az alkotás örömével.

Én a Ti beszélgetésetekből nem sokat értek, de ha 1-2 szóban elmondanátok konyhanyelven,hogy miért nem jó, vagy mivel lesz jobb a saját munkátok mint pl. a OneCNC-Wire huzalszikrája+Mach párosítás, azt megköszönném.

Előzmény: n/a (inaktív), 2009-04-28 18:15:00 [321]

G01 X... Y... F1 Z... A... F2 sajna felejtős, nem komálja a mach3 semmilyen formában...

G01 X... Y... F1 Z... A... F2
Ezt akartam írni pontosítva.

Igen, van sok konstatálható dolog.

- Mindig a szárnytőnél mélyebb a szárny, vagyis ott hosszabb a profil. (Szárnyvég felé növelni a mélységet, elvi aerodinamikai okok miatt értelmetlen.) - ez kettőnél több részes szárnyakra is érvényes.

- A rövidebb profilon (kisebbik szárnymélység) a huzalnak elvben lassabban kéne mennie. Vagyis
egy egy ilyesmi: G01 X... Y... F1 Z... A... F1 - vagy ennek bármilyen alternatívája.

- A .dat fájl szabányos!
Jó bonyolult
1. sor fejléc (String) (el kell szépen hagyni)
2. sortól x.xxxxxx y.yyyyyy
1-től 0-ig halad, majd innen megint 1-ig.
Nem merem biztosra állíani, hogy mindig minden esetben elmegy-e 0-ig, vagy 0.00xxx a belépőél utolsó legkisebb pontja.(?)
Lényeg, hogy a Legkisebb X érték a sorban,
a felső ív utolsó pontja, onnantól az alsó következik. Habvágás szempontjából fontos elkülöníteni a kettőt.
A kilépőéltől (1-től) kezdi el definiálni a profilt.

A fenti F1-F2 értékhez kapcsolódóna, már ha működőképes lenne, akkor simán lehetne csinálni egy olyasmit, hogy:
L1 = sqrt((P1x1 - P1x2)^2 / (P1y1 - P1y2)^2)
L2 = sqrt((P2x1 - P2x2)^2 / (P2y1 - P2y2)^2)
- Két "vektor" nagysága kell csak nekünk (a profilt alkotó egyenes-párokból)
A = 1 / (L2 / L1) (->azonos profilok esetén mindig A<1, ez egy arányt képez a két vektorunk hosszából)
- megnézzük hogyan aránylanak egymáshoz
F2 = F1 * A - Vagyis a kisebbik profilon arányosan levennénk a sebességet az előtolást a fentiek szerint...

És némi fejtörésre ad megint okot a dolog (kellene-e feleslegesen számolni minden vektort vagy elég lenne egyszer?):
Ha a kisebbik profil hossza N-ed része a nagynak, akkor szummázva a vektorainak átlaga is vajon N-ed része-e a hosszabbik vektorainak átlagával? Mert ekkor csak a két profil hosszát kéne osztani, és nem kellenek semmilyen vektorok...
Persze lehet, hogy ezzel feleslegesen messzire megyek...

Én is ezen agyalok...
A JediCut sem enged meg eltérő kulcspontú profilokat, itt is ragaszkodni kell a totál szinkronhoz!
Én úgy csinálnám, hogy a Mach3 X-Y lenne a törzszöz közelebbi profil, a Z-A lenne a szárnyvég és így a G-kódban totális szinkront lehet készíteni:
Pl: G1 X11.00 Y0.34 Z11.00 A0.22
Ez egyszerre írja le mindkét profil 1-1 kulcspontját. A .dat file úgylátom egy 0-1 közötti koordináta rendszer, melyet fel kell szorozni a kért profil méretre és a 0.000 0.000 tól jobra és balra írja le a felső és alsó profil ívek koordinátáját. Ez elég egyszerű nyelvezet, már csak fel kell cicomázni.

Előzmény: SquirrelTech, 2009-04-28 18:08:00 [320]

Nagyon töröm a fejem ezen a szárnyprofil-habvágó wizardon. Egész pontosan azon a részén, hogy két különböző profil a szárnyvégeken, trapéz szárny esetén.
Hát nagyon nincs ötletem. Vagyis konkrét, mert elgondolás az annyi van, hogy már kezdek belezavarodni...

Most épp azon gondolkozom, hogy legelső lépésként a két .dat fájl tartalmát egy ~600x4-es valós tömmbe töltöm, de még ez nem garantál semmilyen szinkronizációt, mivel koránt sem biztos, hogy két profilt pontosan ugyanannyi koordinátapár definiál.
(Először egy fájlba akartam mindentösszefésülni, de ezt egyelőre félretettem.)
És ugye két profillal szinkronban kéne dolgozni valahogy 1. prof. X-Y tengelyen, egyidőben ezzel a 2. prof. a Z-A tengelyen. (vegyük úgy, hogy most így vannak elrendezve a tengelyek).
Egy G01 egyszerre léptet XYZA tengelyt, de ezeknek paramétert kell adni.

Az elvet nagyon leegyszerűsítettem: A huzal két végének egyszerre kell be belépne a habanyagba és egyszerre is kell kilépnie abból, amikor kész. És ami a kettő között van, azt kéne valahogy feldolgozni...
Ott tartok, hogy még a globális változókkal is hadilábon áll a scriptelés. Márpedig az említett a tömbnek globálnak kéne lennie, mert már a két fájl betöltése is ezen bukhat, ha mindig csak egy gombhoz adhatok egy lokális scriptet...

(Túrom picit a külső makrók lehetőségével kapcsolatos infókat is, hátha az még ad valami pluszt.)

A profilgeometria tekintetében pedig a variációk száma épp, hogy csak nem a végtelen felé közelít... Nem mondom, hogy rossz ez a wizard dolog, de ekkora falathoz szerintem kissé korlátolt (vagy nagyon sokmidnent kell még benne fejtegetni), mert túldokumentálva sincsen.

Ötleteket, tippeket, elgondolásokat szívesen látok! Észrevételeket is.

Na ezek jó hírek! Köszi!
Új távlatokat nyithat fejlesztésekhez (4D habvágás)!!!
Én is le foghom tesztelni...

Előzmény: SquirrelTech, 2009-04-28 14:21:00 [317]

Hopppsz! Elkezdtem írni egy wizardot és eközben vagy a mach, vagy a screendesigner odavarázsolt egy set.def fájl. Hogy melyik és mikor azt meg nem tudom mondani, de nem is lényeg. Következésképp, ha szükségét érzi valamelyik program, akkor az létrehozza magától...

No végigcsináltam most egy tesztet.

- Machon belül Addon mappába, ha "mill" wizard lesz, TurnAddons mappába ha "lathe" wizard lesz (utóbbiba dolgoztam) új mappa pl. a wizardunk nevével.
- screendesigner3... Author - Desc Labelek + tettem egy exit gombot, mást nem.
- elmentettem az előbb létrehozott mappába.

mach indít, pick wizard, ott van a listában az én wizardom, az Author és a Desc cimkéből kiemelte, amiket beírtam, lefutott, visszatért a standard képernyőhöz...

def fájl miatt egy mukkot nem szólt...

Ezek szerint tényleg csak ennyi!

A def fájl kérdésére nem ad ez sem választ választ, de http://www.machsupport.com/docs/Mach2_6.11_Custom.pdf az 5. fejezet viszonylag hosszan fejtegeti.

A #299-ben tett feltételezésmrre ezt írja [5.3.1]:

"A wizard is simply a screen which is used for data entry by the user and has some buttons to start using data when it is complete. Most wizards generate G-code to be run after leaving the wizard screen. While it is possible for wizard to actually run G-code, this is an advanced use of wizard and it is not recommended for inexperienced wizard writers."

Vagyis egyéb híján screendesigner a "fejlesztői környezete".

Ami még kérdés volt számomra az is most derült ki ebből:

"The first thing to do is tell the program who wrote this wizard." ... Author és Desc kezdetű címkék kellenek - ezek nem fognak megjelenni a wizard ablakban... "they are only used for the wizard selector dialog."
Vagyis a pick wizard esetén ennek a két címkének a szövege kerül a wizardok listájába.

Előzmény: n/a (inaktív), 2009-04-28 07:04:00 [313]

A kondival kapcsolatban az adok-veszek vagy privátban írjatok.Köszi.

Az Adok-Veszekbe jobb helyen lenne.

Előzmény: nyiszi, 2009-04-27 21:21:00 [304]

Ebben igazad van (forrás hozzáférhető az objektumoknál, de minden?)!
Csak azt az 1 file-t nem értem (pedig mindegyik wizárdban ott van)...
A neten nem találok leírást a wizárdkészítésről ( a Wikipédia is üres e témában).

Előzmény: SquirrelTech, 2009-04-27 21:10:00 [302]

Ezek újak? Ha igen, 5db érdekel engem is kipróbálom...

Előzmény: nyiszi, 2009-04-27 21:21:00 [304]