boecce 2012. aug. 01. 14:15 #117
Mi okozhatja a következőt?:
Adott egy program, ami tartalmazza a pozicióit több körüregnek, pl
L X50 Y100
CC ;;; körívközéppont
CALL PGM 233
majd meghív egy olyant amiben csavarvonal mozgással végrehajt úgy, hogy Q paraméterekkel van megadva a kezdő- növekmény- és befejező Z érték, amik a klasszikus
LBL 1
CP IPA +360 Z-Q1 DR+ mozgással mélyül
LBL 0
körönként, hogy meddig, azt az
FN 11: IF Q1 GT Q3 GOTO LBL 1 vezérli.
Ez működött is több hónapon át, majd vészes jelenséh ütötte fel a fejét: amikor a főprogram meghívta a helikálist, az megtette az első lépéseket, majd az első újraszámított mélyítés helyett nem ismételt, hanem egy VÉLETLENSZERŰ-nek tűnő sort hajtott végre, egyik esetben ez a sor
L Z+58 FMAX látszott a kijelzőn
és ehelyett végrehajtott egy egyenes elémozdulást X0 Y0 helyzetre, pedig neki még csavarvonal-mélyítést kellett volna tennie.
Kiderítettem, hogy csak egyetlen olyan program volt a könyvtárban, ami Z58-as FMAX parancsa volt, ennek semmi köze nem volt a fő-és helix programhoz.Ezt kitöröltem, hogy nem találja meg a LBL-ismétlő utasítás, erre egy másik véletlenszerű program véletlenszerű sorát akarta végrehajtani. Viszonylag olcsón megúsztam a jelenséget, egy selejtes kilépés volt egy körüregből az aktuális Z-0.5 -nél, de történhetett volna bármi géptörés. Azóta sem tudom használni a makrót.
Segít az ha valamennyi programot kitakarítom és csak a pozicionáló meg a helix-makró marad bent? TNC 155-ről van szó
Alprogram hívási probléma
Re: Alprogram hívási probléma
Tímár Tibor 2012. aug. 13. 17:13 #118
A kissé zavaros leírásodból és a beillesztett programsorokból nem sok derül ki.
A hibajelenség - ha jól értelmezem a szöveget - elég érdekes. Hasonlóval soha nem találkoztam.
De van egy halovány tippem.
Az LBL0 az adott helyen felesleges. Javaslom töröld ki és úgy próbáld futtatni.
A vezérlő belső működését nem ismerem, de az ilyen hiba (felesleges LBL0) a vissztatérési vermet jól meg tudja kavarni. Ha az alprogramhívás (CALL LBLxx) és a programhívás (CALL PGM yyyy) azonos vermet használ, akkor ez életveszélyes.
Tanuld meg a ciklusszervezés és az alprogramhívás technikáját, mert anélkül a vezérlő eme hatékony eszközeit nem fogod tudni használni!
A 155-ös vezérlő 32 programot tud tárolni. Szerintem egy ilyen egyszerű feladattal kár plusz helyet elfoglalni. Egy programban is könnyen és röviden megoldható.
Hasonló feladatot én így szoktam megoldani:
0 BEGIN PGM 12345678 MM
1 BLK FORM 0.1 Z X-100 Y-100 Z-20
2 BLK FORM 0.2 X+100 Y+100 Z+0
3 TOOL DEF 1 L+0 R+12.5
4 TOOL CALL 1 Z S1400
5 FN 0: Q1 =+65
6 FN 0: Q2 =+60
7 CALL LBL 1
8 FN 0: Q1 =+28
9 FN 0: Q2 =+10
10 CALL LBL 1
11 FN 0: Q1 =-70
12 FN 0: Q2 =+35
13 CALL LBL 1
14 FN 0: Q1 =-35
15 FN 0: Q2 =-25
16 CALL LBL 1
17 FN 0: Q1 =+20
18 FN 0: Q2 =-70
19 CALL LBL 1
20 M5
21 L X-200 Y+200 Z+100 F5000 M30
22 LBL 1
23 CC X+Q1 Y+Q2
24 L X+Q1 Y+Q2 Z+10 F5000 M3
25 Z+2 F2222
26 Z+0 F800
27 LP PR+12 PA+0 F500
28 LBL 2
29 CP IPA+360 IZ-2 DR+
30 CALL LBL 2 REP6
31 CP IPA+360 DR+
32 LP PR+0 F1000
33 Z+10 F5000
34 LBL 0
35 END PGM 12345678 MM
A kissé zavaros leírásodból és a beillesztett programsorokból nem sok derül ki.
A hibajelenség - ha jól értelmezem a szöveget - elég érdekes. Hasonlóval soha nem találkoztam.
De van egy halovány tippem.
Az LBL0 az adott helyen felesleges. Javaslom töröld ki és úgy próbáld futtatni.
A vezérlő belső működését nem ismerem, de az ilyen hiba (felesleges LBL0) a vissztatérési vermet jól meg tudja kavarni. Ha az alprogramhívás (CALL LBLxx) és a programhívás (CALL PGM yyyy) azonos vermet használ, akkor ez életveszélyes.
Tanuld meg a ciklusszervezés és az alprogramhívás technikáját, mert anélkül a vezérlő eme hatékony eszközeit nem fogod tudni használni!
A 155-ös vezérlő 32 programot tud tárolni. Szerintem egy ilyen egyszerű feladattal kár plusz helyet elfoglalni. Egy programban is könnyen és röviden megoldható.
Hasonló feladatot én így szoktam megoldani:
0 BEGIN PGM 12345678 MM
1 BLK FORM 0.1 Z X-100 Y-100 Z-20
2 BLK FORM 0.2 X+100 Y+100 Z+0
3 TOOL DEF 1 L+0 R+12.5
4 TOOL CALL 1 Z S1400
5 FN 0: Q1 =+65
6 FN 0: Q2 =+60
7 CALL LBL 1
8 FN 0: Q1 =+28
9 FN 0: Q2 =+10
10 CALL LBL 1
11 FN 0: Q1 =-70
12 FN 0: Q2 =+35
13 CALL LBL 1
14 FN 0: Q1 =-35
15 FN 0: Q2 =-25
16 CALL LBL 1
17 FN 0: Q1 =+20
18 FN 0: Q2 =-70
19 CALL LBL 1
20 M5
21 L X-200 Y+200 Z+100 F5000 M30
22 LBL 1
23 CC X+Q1 Y+Q2
24 L X+Q1 Y+Q2 Z+10 F5000 M3
25 Z+2 F2222
26 Z+0 F800
27 LP PR+12 PA+0 F500
28 LBL 2
29 CP IPA+360 IZ-2 DR+
30 CALL LBL 2 REP6
31 CP IPA+360 DR+
32 LP PR+0 F1000
33 Z+10 F5000
34 LBL 0
35 END PGM 12345678 MM
Re: Alprogram hívási probléma
boecce 2012. aug. 14. 10:12 #119
Köszönöm a választ!
Az LBL0 abból a megfontolásból került oda ahol van, hogy az LBL1 lefutását követő újraszámítást és ugrásutasítást ne a ciklusmag tartalmazza, arra gondolva, hogy az ugrás után úgyis olvassa ezeket. De valóban, épp tegnap kísérletképpen a ciklus zárását minden szükséges számítás utánra téve már jól működött a program.
Hogy erre miért van szükség a lehetséges 32 programhely mellet? Azért, mert az a CAM szoftver amivel dolgozunk nem tud csavarvonalas körinterpolációval programozni, és ahogy Te is írtál egy mintaprogit, esetenként sok sok sorból álló eredményt kapok helyette. (még ha használ is alprogramot, úgy is) Így viszont a CAM-mel megkapom a körüregek pozícióját, amit csak ki kell egészítenem a helix- programhoz tartozó adatokkal és máris készül a darab. Így bármely alkatrészhez kevés munkával (pár sor, ami a kezdő- befejező- fogásvétel- érték és a körsugár Q-paraméterrel való megadása. ).
Visszatérve az LBL- utasításhoz: úgy tudtam, ha nyitok egy LBLxxx programot, azt le is kell zárni valamikor LBL0-al.. Kvázi zárójelként fogom fel, ami ha nem párban van, akkor egyéb szoftverek alapból hibaként jeleznek. Úgy tűnik ez itt másként van.
Köszönöm a segítségedet!!!
Köszönöm a választ!
Az LBL0 abból a megfontolásból került oda ahol van, hogy az LBL1 lefutását követő újraszámítást és ugrásutasítást ne a ciklusmag tartalmazza, arra gondolva, hogy az ugrás után úgyis olvassa ezeket. De valóban, épp tegnap kísérletképpen a ciklus zárását minden szükséges számítás utánra téve már jól működött a program.
Hogy erre miért van szükség a lehetséges 32 programhely mellet? Azért, mert az a CAM szoftver amivel dolgozunk nem tud csavarvonalas körinterpolációval programozni, és ahogy Te is írtál egy mintaprogit, esetenként sok sok sorból álló eredményt kapok helyette. (még ha használ is alprogramot, úgy is) Így viszont a CAM-mel megkapom a körüregek pozícióját, amit csak ki kell egészítenem a helix- programhoz tartozó adatokkal és máris készül a darab. Így bármely alkatrészhez kevés munkával (pár sor, ami a kezdő- befejező- fogásvétel- érték és a körsugár Q-paraméterrel való megadása. ).
Visszatérve az LBL- utasításhoz: úgy tudtam, ha nyitok egy LBLxxx programot, azt le is kell zárni valamikor LBL0-al.. Kvázi zárójelként fogom fel, ami ha nem párban van, akkor egyéb szoftverek alapból hibaként jeleznek. Úgy tűnik ez itt másként van.
Köszönöm a segítségedet!!!
Re: Alprogram hívási probléma
Tímár Tibor 2012. aug. 14. 11:02 #120
A CAM program melyik, már ha publikus?
Az LBL nem nyit semmit. Az angol Label (cimke) szó rövidítése. Azért kell alkalmazni mert a Klartext programozásnál nincsenek sorszámok és az ugrásoknál egyébként nincs mire hivatkozni. Nem kell lezárni, nincs itt semmi zárójelhez hasonló kényszer. Tökéletes és hibamentes programot lehet írni akár 30 LBL-el egyetlen LBL0 nélkül is.
Ha helyesen akarod használni az alprogramokat, akkor azokat minden esetben a programtörzs után kell elhelyezni. (M02 vagy M30 után.)Tehát a programtörzsön belül LBL0-nak nincs helye!
Az alprogram kezdődik a bevezető cimkével (LBLxx) és végződik az azt lezáró LBL0-val.
Előfordulhat olyan eset, hogy az egyik alprogram ráfut egy másikra (a mögötte lévőre). Ilyenkor pl. 3 alprogramhoz elegendő lehet 2 LBL0-is. (Csak, hogy bonyolódjon a helyzet.)
A CAM program melyik, már ha publikus?
Az LBL nem nyit semmit. Az angol Label (cimke) szó rövidítése. Azért kell alkalmazni mert a Klartext programozásnál nincsenek sorszámok és az ugrásoknál egyébként nincs mire hivatkozni. Nem kell lezárni, nincs itt semmi zárójelhez hasonló kényszer. Tökéletes és hibamentes programot lehet írni akár 30 LBL-el egyetlen LBL0 nélkül is.
Ha helyesen akarod használni az alprogramokat, akkor azokat minden esetben a programtörzs után kell elhelyezni. (M02 vagy M30 után.)Tehát a programtörzsön belül LBL0-nak nincs helye!
Az alprogram kezdődik a bevezető cimkével (LBLxx) és végződik az azt lezáró LBL0-val.
Előfordulhat olyan eset, hogy az egyik alprogram ráfut egy másikra (a mögötte lévőre). Ilyenkor pl. 3 alprogramhoz elegendő lehet 2 LBL0-is. (Csak, hogy bonyolódjon a helyzet.)
Re: Alprogram hívási probléma
boecce 2012. aug. 14. 13:00 #121
@ Tímár Tibor:
EdgeCam a progi.De sztem bármi is lenne, olyant egyik sem produkál, ami 4-8 sort akár végtelenszer is ismételne, helyette vagy sok sok egyenesre bontva 3 tengely mentén mozgat, vagy egy síkon egyszerű kört mozog le egy alprogramba zárva, majd a kezdőpontra visszatérve fogásokat vesz sokszor (ami újabb sorok generálása), pont úgy ahogy a te példád csinálja.
A mostani hozzászólásodban javasolt módszerrel csak annyit vitatkoznék, hogy valóban biztonságosabb használni a címkéket a pr-törzs után, ellenpéldaként eddig csak akár az EdgeCam, akáR a MasterCam "gyári" megoldását hoznám : ahor az első fogás után egy LBL-be teszi azonnal a konturt, majd LBL0-al lezárja, hogy később a CALL LBLxxx- el csak a két címke közti részt használja. Újabb kontúr természetesen újabb címke a sorban, újabb LBL 0-al Természetesen valóban ajánlatosabba módszeredet követni. (ahogy szinte kizárólagosan láttam ezektől eltérő vezérlések esetében., pl Gildemeister EP, itt nem is lehet meghatározni más helyre, csak a végére, vagy külső alprgként, és a programtörzsben a klasszikus makróként van paraméterezve a híváskor)
Szép napot, mennem kell a "gyakorlati" felhasználó területre
(munkába)
@ Tímár Tibor:
EdgeCam a progi.De sztem bármi is lenne, olyant egyik sem produkál, ami 4-8 sort akár végtelenszer is ismételne, helyette vagy sok sok egyenesre bontva 3 tengely mentén mozgat, vagy egy síkon egyszerű kört mozog le egy alprogramba zárva, majd a kezdőpontra visszatérve fogásokat vesz sokszor (ami újabb sorok generálása), pont úgy ahogy a te példád csinálja.
A mostani hozzászólásodban javasolt módszerrel csak annyit vitatkoznék, hogy valóban biztonságosabb használni a címkéket a pr-törzs után, ellenpéldaként eddig csak akár az EdgeCam, akáR a MasterCam "gyári" megoldását hoznám : ahor az első fogás után egy LBL-be teszi azonnal a konturt, majd LBL0-al lezárja, hogy később a CALL LBLxxx- el csak a két címke közti részt használja. Újabb kontúr természetesen újabb címke a sorban, újabb LBL 0-al Természetesen valóban ajánlatosabba módszeredet követni. (ahogy szinte kizárólagosan láttam ezektől eltérő vezérlések esetében., pl Gildemeister EP, itt nem is lehet meghatározni más helyre, csak a végére, vagy külső alprgként, és a programtörzsben a klasszikus makróként van paraméterezve a híváskor)
Szép napot, mennem kell a "gyakorlati" felhasználó területre
(munkába)Re: Alprogram hívási probléma
Tímár Tibor 2012. aug. 15. 09:31 #122
Abban teljesen igazad van, hogy a CAM programok nem generálnak optimális kódot. De ez nem is céljuk. A nevesebbek azonban tudnak helix interpolációt, ha a posztprocesszor fel van rá készítve.
Vitatkozni nem akarok, csak javaslom, hogy ne egy CAM kimenetéből tanuld a manuális programozás technikáját. Attól, hogy valami működőképes, még lehet helytelen.
Ha ismered a CAM programok működését, akkor tudod, hogy a kimenetért jórészt a posztprocesszor felel. Azt bárki írhat és arra sincs garancia, hogy az alaprendszerrel települőek hibátlanok. Erre fel is szokták hívni a figyelmet a felhasználói szerződésben.
Abban teljesen igazad van, hogy a CAM programok nem generálnak optimális kódot. De ez nem is céljuk. A nevesebbek azonban tudnak helix interpolációt, ha a posztprocesszor fel van rá készítve.
Vitatkozni nem akarok, csak javaslom, hogy ne egy CAM kimenetéből tanuld a manuális programozás technikáját. Attól, hogy valami működőképes, még lehet helytelen.
Ha ismered a CAM programok működését, akkor tudod, hogy a kimenetért jórészt a posztprocesszor felel. Azt bárki írhat és arra sincs garancia, hogy az alaprendszerrel települőek hibátlanok. Erre fel is szokták hívni a figyelmet a felhasználói szerződésben.