UCCNC vezérlő program

[xfg6v697j]

Valami még mindíg nem az igazi,bár már nem az acos lessz a ludas.
http://www.kepfeltoltes.hu/140727/100948967n_vtelen_www.kepfeltoltes.hu_.jpg" TARGET=_fnew>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.

[000000000]

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

[xfg6v697j]

Email elment.

[000000000]

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.

[000000000]

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

[000000000]

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

[000000000]

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?

[wcsxp0uxa]

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)

[000000000]

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.

[000000000]

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.

[000000000]

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.

[xfg6v697j]

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

[xfg6v697j]

É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.

[frkdv6dyr]

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.

[s7manbs8]

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.