Siemens
Digital Industries, Motion Control, Machine Tool Systems
8844
Follower:innenSchachtelungskonflikt in Kontrollstrukturen
21.02.2015, 11:21 Uhr
Hallo liebes Forum,
an unseren 840D sl nutze ich gerne und reichlich die Möglichkeiten, die die IF...ENDIF und
FOR..:ENDFOR Blöcke so mit sich bringen.
Leider verweigert die Steuerung hin und wieder die Zusammenarbeit und verweist auf den Alarm "Schachtelungs...".
Das Eigenartige ist, dass wenn ich den betreffenden Block komplett entferne,
(also IF bzw. FOR bis einschließlich ENDIF bzw. ENDFOR) läuft alles einwandfrei.
Weiterhin ist merkwürdig, dass alle Programme vom Postprozessor die gleiche Struktur bekommen und
99,5% der Programme laufen auch völlig problemlos.
Der Alarm taucht auch dann auf, wenn der Block nicht in anderen verschachtelt ist und für sich allein steht.
AEG bringt auch keine Abhilfe.
Im Voraus schon mal Vielen Dank für eure Hilfe.
an unseren 840D sl nutze ich gerne und reichlich die Möglichkeiten, die die IF...ENDIF und
FOR..:ENDFOR Blöcke so mit sich bringen.
Leider verweigert die Steuerung hin und wieder die Zusammenarbeit und verweist auf den Alarm "Schachtelungs...".
Das Eigenartige ist, dass wenn ich den betreffenden Block komplett entferne,
(also IF bzw. FOR bis einschließlich ENDIF bzw. ENDFOR) läuft alles einwandfrei.
Weiterhin ist merkwürdig, dass alle Programme vom Postprozessor die gleiche Struktur bekommen und
99,5% der Programme laufen auch völlig problemlos.
Der Alarm taucht auch dann auf, wenn der Block nicht in anderen verschachtelt ist und für sich allein steht.
AEG bringt auch keine Abhilfe.
Im Voraus schon mal Vielen Dank für eure Hilfe.
21.02.2015, 13:39 Uhr
Guest_guest_*
Themenstarter
Gast
Kontrollstrukturen dürfen, zumindest bei IF, nur eine Schachtelungstiefe von 8 Ebenen haben.
Du könntest theoretisch 20 Ebenen programmieren, aber im Ablauf nur 7 Ebenen durchlaufen, ohne Motze zu erhalten.
Motze gibt es erst, wenn die 9.Ebene angesprungen werden soll.
Du könntest theoretisch 20 Ebenen programmieren, aber im Ablauf nur 7 Ebenen durchlaufen, ohne Motze zu erhalten.
Motze gibt es erst, wenn die 9.Ebene angesprungen werden soll.
21.02.2015, 13:43 Uhr
OK. Aber wie ich geschrieben habe, tritt die Fehlermeldung auch bei einem in oberster Ebene
stehenden Block auf der keine weiteren Blöcke enthält. Und das ist doch äußerst merkwürdig.
Habe dazu auch schon mal den Programmierer unseres Maschinenherstellers befragt.
Der kennt das Problem auch, allerdings keine Lösung,
stehenden Block auf der keine weiteren Blöcke enthält. Und das ist doch äußerst merkwürdig.
Habe dazu auch schon mal den Programmierer unseres Maschinenherstellers befragt.
Der kennt das Problem auch, allerdings keine Lösung,
21.02.2015, 13:47 Uhr
nixalsverdruss
Level 7 = Community-Professor
Gruppe: Mitglied
Mitglied seit: 16.11.2003
Beiträge: 1.511
Mitglied seit: 16.11.2003
Beiträge: 1.511
OK. Aber wie ich geschrieben habe, tritt die Fehlermeldung auch bei einem in oberster Ebene
stehenden Block auf der keine weiteren Blöcke enthält. Und das ist doch äußerst merkwürdig.
Habe dazu auch schon mal den Programmierer unseres Maschinenherstellers befragt.
Der kennt das Problem auch, allerdings keine Lösung,
stehenden Block auf der keine weiteren Blöcke enthält. Und das ist doch äußerst merkwürdig.
Habe dazu auch schon mal den Programmierer unseres Maschinenherstellers befragt.
Der kennt das Problem auch, allerdings keine Lösung,
wenn du hin und wieder merkwürdig programmierst kann das vorkommen !
ohne das Programm zu sehen wir das in Traumdeutung enden.
21.02.2015, 13:58 Uhr
Hier mal der Anfang einer Beispieldatei. Dabei wird in N174 der Alarm gesetzt.
Nach auskommentieren der Sätze in N168-N174 lief es.
In einem anderen Fall zeigte die Alarmmeldung auf N87. Habe dort N85-N87 auskommentiert
und es funktionierte ohne Probleme.
Beispiel.mpf ( 5.16KB ) Anzahl der Downloads: 78
Der Beitrag wurde von Sacculina bearbeitet: 21.02.2015, 14:01 Uhr
Nach auskommentieren der Sätze in N168-N174 lief es.
In einem anderen Fall zeigte die Alarmmeldung auf N87. Habe dort N85-N87 auskommentiert
und es funktionierte ohne Probleme.
Beispiel.mpf ( 5.16KB ) Anzahl der Downloads: 78
Der Beitrag wurde von Sacculina bearbeitet: 21.02.2015, 14:01 Uhr
21.02.2015, 17:57 Uhr
Guest_guest_*
Themenstarter
Gast
Schachtelungs-Alarme gibt es einige...
Falls ja, hat der Interpreter eine offene Schleife entdeckt.
"12640 Kanal %1 Satz %2 Schachtelungs-Konflikt bei Kontrollstrukturen"
Fehler im Programmablauf: Geoeffnete Kontrollstrukturen (IF-ELSE-ENDIF, LOOP-ENDLOOP etc.)
werden nicht beendet oder es gibt keinen Schleifenanfang zum programmierten Schleifenende.
Beispiel:
LOOP ENDIF ENDLOOP
In deinem Programmausschnitt habe ich nichts dergleichen gefunden. Allerdings auch kein M17, M30 oder RET.
Schau dir also noch mal alle Schleifen des gesamten Programms genau an. Ich vermute mal, das irgendwo etwas beendet werden soll, das nie begonnen hat.
QUOTE
Guido B.: Gehe ich recht in der Annahme, daß der Alarm eine Nummer hat?
Robert L. : Ja
Guido B.: Gehe ich recht in der Annahme, daß es sich bei der Alarmnummer um die Ziffernfolge "12640" handelt?
Robert L. : Ja
Guido B.: Gehe ich recht in der Annahme, daß es sich bei der Alarmnummer um die Ziffernfolge "12640" handelt?
Falls ja, hat der Interpreter eine offene Schleife entdeckt.
"12640 Kanal %1 Satz %2 Schachtelungs-Konflikt bei Kontrollstrukturen"
Fehler im Programmablauf: Geoeffnete Kontrollstrukturen (IF-ELSE-ENDIF, LOOP-ENDLOOP etc.)
werden nicht beendet oder es gibt keinen Schleifenanfang zum programmierten Schleifenende.
Beispiel:
LOOP ENDIF ENDLOOP
In deinem Programmausschnitt habe ich nichts dergleichen gefunden. Allerdings auch kein M17, M30 oder RET.
Schau dir also noch mal alle Schleifen des gesamten Programms genau an. Ich vermute mal, das irgendwo etwas beendet werden soll, das nie begonnen hat.
21.02.2015, 18:24 Uhr
Ja genau diese Alarmnummer.
Ich hatte nur den Anfang des Programms eingestellt da sie 14MB groß ist, deshalb
findest du auch kein M30 oder dergleichen.
Was ja meiner Meinung nach eindeutig gegen eine offene Struktur spricht ist,
dass nach dem Auskommentieren eines IF...ENDIF bzw FOR...ENDFOR Blocks das Programm klaglos abgearbeitet wird.
Ich hatte nur den Anfang des Programms eingestellt da sie 14MB groß ist, deshalb
findest du auch kein M30 oder dergleichen.
Was ja meiner Meinung nach eindeutig gegen eine offene Struktur spricht ist,
dass nach dem Auskommentieren eines IF...ENDIF bzw FOR...ENDFOR Blocks das Programm klaglos abgearbeitet wird.
QUOTE
Hier mal der Anfang einer Beispieldatei. Dabei wird in N174 der Alarm gesetzt.
Nach auskommentieren der Sätze in N168-N174 lief es.
In einem anderen Fall zeigte die Alarmmeldung auf N87. Habe dort N85-N87 auskommentiert
und es funktionierte ohne Probleme.
Nach auskommentieren der Sätze in N168-N174 lief es.
In einem anderen Fall zeigte die Alarmmeldung auf N87. Habe dort N85-N87 auskommentiert
und es funktionierte ohne Probleme.
26.02.2015, 01:36 Uhr
Habe inzwischen ein wenig probieren können. Dabei ist mir aufgefallen, dass der Fehler scheinbar nur dann auftritt, wenn ein Programm von Extern abgearbeitet wird. (Wie gesagt nicht immer sondern nur in wenigen Fällen.) Ist es in der NC geladen wird kein Alarm ausgegeben.
STOPRE hat leider nichts gebracht.
Die angehängte Datei Schachtelung_N178.txt verweist in der Alarmmeldung auf die Zeile N178.
Dabei reicht es den in N175 stehenden WRITE Befehl auszukommentierten, damit das Programm ohne Alarmmeldung ausgeführt wird.
Schachtelung_N178.txt ( 473.98KB ) Anzahl der Downloads: 41
STOPRE hat leider nichts gebracht.
Die angehängte Datei Schachtelung_N178.txt verweist in der Alarmmeldung auf die Zeile N178.
Dabei reicht es den in N175 stehenden WRITE Befehl auszukommentierten, damit das Programm ohne Alarmmeldung ausgeführt wird.
Schachtelung_N178.txt ( 473.98KB ) Anzahl der Downloads: 41
26.02.2015, 12:54 Uhr
Guest_guest_*
Themenstarter
Gast
Ehrlich gesagt, habe ich mit dieser Art "Spaghetti-Code" so meine Probleme. Zumindest in diesem Umfang.
Das überschaut kein Mensch mehr. Nicht einmal du, wenn du nach 14Tagen eine kleine Korrektur direkt an der Maschine machen sollst.
Von EXTERN arbeitet man ja, weil das Programm nicht mehr in den NC-Speicher passt. Ansonsten macht das wenig Sinn.
Die modernen Steuerungen, zu denen ich unter anderem, auch die Sinumerik zähle , bieten ein ganz praktisches Feature: Unterprogramme.
Große Konturabläufe aus dem CAM gehören in ein Unterprogramm. Dann ist es auch möglich diese Datei von "EXTERN" nachzuladen.
Dafür ist diese Funktin auch gedacht.
Dazu sollte man auch wissen, daß die externe Datei nur sequentiell nachgeladen wird, was bei solchen "Spaghetti-Programmen" durchaus zu "Schachtel-Fehlern" führen kann, da sie eben auch nur sequentiell gelesen werden kann.
So sollte es aussehen:
Hauptprogramm im WPD-Verzeichnis ->
Das überschaut kein Mensch mehr. Nicht einmal du, wenn du nach 14Tagen eine kleine Korrektur direkt an der Maschine machen sollst.
Von EXTERN arbeitet man ja, weil das Programm nicht mehr in den NC-Speicher passt. Ansonsten macht das wenig Sinn.
Die modernen Steuerungen, zu denen ich unter anderem, auch die Sinumerik zähle , bieten ein ganz praktisches Feature: Unterprogramme.
Große Konturabläufe aus dem CAM gehören in ein Unterprogramm. Dann ist es auch möglich diese Datei von "EXTERN" nachzuladen.
Dafür ist diese Funktin auch gedacht.
Dazu sollte man auch wissen, daß die externe Datei nur sequentiell nachgeladen wird, was bei solchen "Spaghetti-Programmen" durchaus zu "Schachtel-Fehlern" führen kann, da sie eben auch nur sequentiell gelesen werden kann.
So sollte es aussehen:
Hauptprogramm im WPD-Verzeichnis ->
- Unterprogramm im WPD-Verzeichnis
- Unterprogramm im SPF-Verzeichnis
- Zyklen (Hersteller, Anwender)
- Kontur-Unterprogramme von "EXTERN" (CAM-Pfad möglichst ohne Hochsprachelemente, Sprünge und Zyklen )
26.02.2015, 19:41 Uhr
Ehrlich gesagt, habe ich mit dieser Art "Spaghetti-Code" so meine Probleme. Zumindest in diesem Umfang.
Nur weil ein Programm gross ist und viele Variablen hat ist es noch lange kein Spaghetti Code. Meiner Meinung nach eines der schöneren Programme die man hier sieht, alle Variablen haben klare Namen, alles schön mit IF, FOR... programmiert, schön eingerückt...
Das ganze GOTO und Zeug das hier stets verwendet wird ist viel mehr Spaghetti Code.
Von EXTERN arbeitet man ja, weil das Programm nicht mehr in den NC-Speicher passt. Ansonsten macht das wenig Sinn.
Die modernen Steuerungen, zu denen ich unter anderem, auch die Sinumerik zähle , bieten ein ganz praktisches Feature: Unterprogramme.
Die modernen Steuerungen, zu denen ich unter anderem, auch die Sinumerik zähle , bieten ein ganz praktisches Feature: Unterprogramme.
Du verwechselst wohl EXTERN mit EXTCALL, EXTERN dient dem Unterprogrammaufruf mit Parameterübergabe für Unterprogramme mit PROC Zeile, welche nicht in einem Zyklenordner abgelegt sind. :doch:
@Sacculina: Leider kann ich den Fehler nicht reproduzieren, hab deine Schlaife mal grob nachgebaut und lief ohne zu klagen. Hast du schon mal probiert das WRITE mit einem Beispielstring zu machen anstatt deinen Array? Weiss zwar nicht ob das was bringen wird, aber das ganze ist sowieso komisch.
--------------------
Freundliche Grüsse
DMC635V
DMC635V
26.02.2015, 20:20 Uhr
Guest_guest_*
Themenstarter
Gast
QUOTE
Du verwechselst wohl EXTERN mit EXTCALL, EXTERN dient dem Unterprogrammaufruf mit Parameterübergabe für Unterprogramme mit PROC Zeile, welche nicht in einem Zyklenordner abgelegt sind.
@DMC635V
Nein ich meine das nachladen EXTERN (ausserhalb der NC) gespeicherter Daten mitttels EXTCALL. Daran hatte wohl auch Sacculina keinen Zweifel...
Was ich meine, steht im "Programmierhandbuch Arbeitsvorbereitung". Im Unterkapitel "Externes Unterprogramm abarbeiten (EXTCALL)"
QUOTE
Hinweis
Externe Unterprogramme dürfen keine Sprunganweisungen wie GOTOF , GOTOB , CASE , FOR , LOOP ,
WHILE oder REPEAT enthalten.
IF-ELSE-ENDIF -Konstrukte sind möglich.
Unterprogrammaufrufe und geschachtelte EXTCALL -Aufrufe sind möglich.
Externe Unterprogramme dürfen keine Sprunganweisungen wie GOTOF , GOTOB , CASE , FOR , LOOP ,
WHILE oder REPEAT enthalten.
IF-ELSE-ENDIF -Konstrukte sind möglich.
Unterprogrammaufrufe und geschachtelte EXTCALL -Aufrufe sind möglich.
@Sacculina
Das eigentliche Problem sind in diesem Fall ganz sicher die FOR-Schleifen.
Wobei ich auch schon mit kurzen IF-ENDIF Blöcken in einem externen Programm Motze bekommen habe.
Das hat hauptsächlich mit dem seriellen, sequentiellen Nachladen externer Programme zu tun.
QUOTE
Nur weil ein Programm gross ist und viele Variablen hat ist es noch lange kein Spaghetti Code. Meiner Meinung nach eines der schöneren Programme die man hier sieht, alle Variablen haben klare Namen, alles schön mit IF, FOR... programmiert, schön eingerückt...
Das ganze GOTO und Zeug das hier stets verwendet wird ist viel mehr Spaghetti Code.
Das ganze GOTO und Zeug das hier stets verwendet wird ist viel mehr Spaghetti Code.
@DMC635V
Sauber programmiert... JA! ...und das ist auch nicht das, was ich kritisiere.
Die schiere Größe des Programms, macht es leider sehr unübersichtlich.
Stell dir das im Editor der Sinumerik vor...
Einzelne Sektionen in Unterprogramme auszulagern macht da, im Sinne der Übersicht, sicher Sinn.
27.02.2015, 19:18 Uhr
@DMC635V
Nein ich meine das nachladen EXTERN (ausserhalb der NC) gespeicherter Daten mitttels EXTCALL. Daran hatte wohl auch Sacculina keinen Zweifel...
Was ich meine, steht im "Programmierhandbuch Arbeitsvorbereitung". Im Unterkapitel "Externes Unterprogramm abarbeiten (EXTCALL)"
Nein ich meine das nachladen EXTERN (ausserhalb der NC) gespeicherter Daten mitttels EXTCALL. Daran hatte wohl auch Sacculina keinen Zweifel...
Was ich meine, steht im "Programmierhandbuch Arbeitsvorbereitung". Im Unterkapitel "Externes Unterprogramm abarbeiten (EXTCALL)"
Hab vor lauter Eifer nicht gesehen, dass der TE geschrieben hat, dass das Problem nur auftritt wenn das Programm von Extern abgearbeitet wird. Habe gemeint du beziehst dich auf den EXTERN Befehl zuoberst im Programm (N13), da du es ja genau so geschrieben hast
Der Beitrag wurde von DMC635V bearbeitet: 27.02.2015, 19:20 Uhr
--------------------
Freundliche Grüsse
DMC635V
DMC635V
28.02.2015, 02:10 Uhr
Erstmal für eure Antworten.
Das klingt schon mal schlüssig. Ich hatte die Hoffnung schon aufgegeben jemals eine Lösung des Rätsels
zu finden. Wobei die paar MB NC Speicher im Terabyte "Zeitalter" schon steinzeitlich anmuten, oder?
Hinweis
Externe Unterprogramme dürfen keine Sprunganweisungen wie GOTOF , GOTOB , CASE , FOR , LOOP ,
WHILE oder REPEAT enthalten.
IF-ELSE-ENDIF -Konstrukte sind möglich.
Unterprogrammaufrufe und geschachtelte EXTCALL -Aufrufe sind möglich.
Das habe ich bestimmt schon 5 mal gelesen, habe es aber nie mit meinem Problem in Verbindung gebracht.
Vielleicht weil ich immer nur die "bösen" GOTO's auf dem Schirm hatte. Meiner Meinung nach müsste es aber heißen
"Externe Programme dürfen...", da der Alarm auch auftritt wenn ein Hauptprogramm direkt vom Netzwerk abgearbeitet wird.
Mit der Übersicht hast du natürlich recht. (A propos Übersicht, kann man eigentlich keine Unterordner in den Anwenderzyklus- bzw. Unterprogrammordner
anlegen, oder übersehe ich da nur was?) Bisher habe ich mich ein wenig vor den nötigen Umbaumaßnahmen gescheut. Aber nachdem ich jetzt alles
mal überflogen hab sollte es tatsächlich möglich sein, zumindest ohne FOR...ENDFOR auszukommen. Werde das "outsourcen" mal in Angriff nehmen.
Allerdings ist eines meiner Ziele die ich mit meiner Programmierei verfolge, eben genau,
dass man keine Änderungen am NC-Programm mehr vornehmen muss. Bei kritischen Sachen (Geometrie...) muss (bei uns) eh der "Umweg"
über das CAD/CAM System gegangen werden.
Naja, und weil es bequem ist. Programm suchen - anwählen - CYCLE START - fertig.
Danke, das geht runter wie Öl. Die Kollegen sehen meist nur die "vertane" Zeit die ich in das Programmieren stecke. Die
Verbesserungen nutzen Sie natürlich trotzdem gerne.
QUOTE
Das eigentliche Problem sind in diesem Fall ganz sicher die FOR-Schleifen.
Wobei ich auch schon mit kurzen IF-ENDIF Blöcken in einem externen Programm Motze bekommen habe.
Das hat hauptsächlich mit dem seriellen, sequentiellen Nachladen externer Programme zu tun.
Wobei ich auch schon mit kurzen IF-ENDIF Blöcken in einem externen Programm Motze bekommen habe.
Das hat hauptsächlich mit dem seriellen, sequentiellen Nachladen externer Programme zu tun.
Das klingt schon mal schlüssig. Ich hatte die Hoffnung schon aufgegeben jemals eine Lösung des Rätsels
zu finden. Wobei die paar MB NC Speicher im Terabyte "Zeitalter" schon steinzeitlich anmuten, oder?
QUOTE
QUOTE
Hinweis
Externe Unterprogramme dürfen keine Sprunganweisungen wie GOTOF , GOTOB , CASE , FOR , LOOP ,
WHILE oder REPEAT enthalten.
IF-ELSE-ENDIF -Konstrukte sind möglich.
Unterprogrammaufrufe und geschachtelte EXTCALL -Aufrufe sind möglich.
Das habe ich bestimmt schon 5 mal gelesen, habe es aber nie mit meinem Problem in Verbindung gebracht.
Vielleicht weil ich immer nur die "bösen" GOTO's auf dem Schirm hatte. Meiner Meinung nach müsste es aber heißen
"Externe Programme dürfen...", da der Alarm auch auftritt wenn ein Hauptprogramm direkt vom Netzwerk abgearbeitet wird.
QUOTE
Ehrlich gesagt, habe ich mit dieser Art "Spaghetti-Code" so meine Probleme. Zumindest in diesem Umfang.
Das überschaut kein Mensch mehr. Nicht einmal du, wenn du nach 14Tagen eine kleine Korrektur direkt an der Maschine machen sollst.
Das überschaut kein Mensch mehr. Nicht einmal du, wenn du nach 14Tagen eine kleine Korrektur direkt an der Maschine machen sollst.
Mit der Übersicht hast du natürlich recht. (A propos Übersicht, kann man eigentlich keine Unterordner in den Anwenderzyklus- bzw. Unterprogrammordner
anlegen, oder übersehe ich da nur was?) Bisher habe ich mich ein wenig vor den nötigen Umbaumaßnahmen gescheut. Aber nachdem ich jetzt alles
mal überflogen hab sollte es tatsächlich möglich sein, zumindest ohne FOR...ENDFOR auszukommen. Werde das "outsourcen" mal in Angriff nehmen.
Allerdings ist eines meiner Ziele die ich mit meiner Programmierei verfolge, eben genau,
dass man keine Änderungen am NC-Programm mehr vornehmen muss. Bei kritischen Sachen (Geometrie...) muss (bei uns) eh der "Umweg"
über das CAD/CAM System gegangen werden.
QUOTE
Von EXTERN arbeitet man ja, weil das Programm nicht mehr in den NC-Speicher passt. Ansonsten macht das wenig Sinn.
Naja, und weil es bequem ist. Programm suchen - anwählen - CYCLE START - fertig.
QUOTE
Meiner Meinung nach eines der schöneren Programme die man hier sieht, alle Variablen haben klare Namen, alles schön mit IF, FOR... programmiert, schön eingerückt...
QUOTE
Sauber programmiert... JA! ...und das ist auch nicht das, was ich kritisiere.
Danke, das geht runter wie Öl. Die Kollegen sehen meist nur die "vertane" Zeit die ich in das Programmieren stecke. Die
Verbesserungen nutzen Sie natürlich trotzdem gerne.
28.02.2015, 11:14 Uhr
Dabei reicht es den in N175 stehenden WRITE Befehl auszukommentierten, damit das Programm ohne Alarmmeldung ausgeführt wird.
hast mal probiert auf den ERROR zu reagieren ?
nicht das ein ERROR in WRITE ansteht und er deswegen ein Problem mit der FOR Schleife hat.
was anderes kann ich mir nicht zusammenreimen, vor allem wenn du den WRITE Befehl ausblendest und das Programm draufhin läuft.
--------------------
Schaut doch mal rein:
Mein Youtube Kanal
Anwendungen, Zyklen, CAD/CAM
-----------------------------------------------------------------------------------------------------------------------------
Mein Youtube Kanal
Anwendungen, Zyklen, CAD/CAM
-----------------------------------------------------------------------------------------------------------------------------
28.02.2015, 14:44 Uhr
Mit der Übersicht hast du natürlich recht. (A propos Übersicht, kann man eigentlich keine Unterordner in den Anwenderzyklus- bzw. Unterprogrammordner
anlegen, oder übersehe ich da nur was?) Bisher habe ich mich ein wenig vor den nötigen Umbaumaßnahmen gescheut. Aber nachdem ich jetzt alles
mal überflogen hab sollte es tatsächlich möglich sein, zumindest ohne FOR...ENDFOR auszukommen. Werde das "outsourcen" mal in Angriff nehmen.
Allerdings ist eines meiner Ziele die ich mit meiner Programmierei verfolge, eben genau,
dass man keine Änderungen am NC-Programm mehr vornehmen muss. Bei kritischen Sachen (Geometrie...) muss (bei uns) eh der "Umweg"
über das CAD/CAM System gegangen werden.
anlegen, oder übersehe ich da nur was?) Bisher habe ich mich ein wenig vor den nötigen Umbaumaßnahmen gescheut. Aber nachdem ich jetzt alles
mal überflogen hab sollte es tatsächlich möglich sein, zumindest ohne FOR...ENDFOR auszukommen. Werde das "outsourcen" mal in Angriff nehmen.
Allerdings ist eines meiner Ziele die ich mit meiner Programmierei verfolge, eben genau,
dass man keine Änderungen am NC-Programm mehr vornehmen muss. Bei kritischen Sachen (Geometrie...) muss (bei uns) eh der "Umweg"
über das CAD/CAM System gegangen werden.
Wenn du nur Anwenderzyklen erstellen willst musst du dich vor nichts scheuen, die Kenntnisse in der Programmierung hast du ja schon. Vor allem Dinge die bei jedem Programm gleich vorkommen, wie z.B. dein WZ abfragen/anlegen... können gut als Zyklen realisiert werden. Dies hat erstens den Vorteil der Übersicht und zweitens musst du bei einer Implementierungsänderung deinen PP nicht ändern und die alten Programme haben automatisch auch die neue Implementierung. (Sofern du die Aufrufzeile nicht veränderst).
Das einzige was du tun musst, ist ein Unterprogramm mit einer PROC Zeile zu erstellen. Hier ist zu beachten, dass der Name in der PROC Zeile gleich ist wie der des Programmes. Wenn du das Programm erstellt hast musst du das Programm laden und die Maschine neustarten. Änderungen am Programm selbst sind danach immer sofort gültig, Änderungen an der PROC Zeile erfordern einen neustart.
Wenn du im Unterprogramm die gleichen Namen verwendest wie in deinem bisherigen Hauptprogramm, kannst du deine Schleifen 1zu1 kopieren.
z.B.
CUS.DIR/TOOLINIT.SPF
CODE
PROC TOOLINIT(VAR STRING[24] BEZEICHNER[], VAR BOOL WRK[], VAR INT TYP[], VAR REAL DIA[], VAR REAL PITCH[], VAR INT SCHNEIDE[], INT ANZAHL_WZG) DISPLOF SBLOF
DEF INT ERROR, HH
DEF INT EXISTSNOT = 0
DEF INT MAGAZINNOT = 0
DEF INT VERMESSENNOT = 0
; Alte Handwerkzeug Datei löschen
DELETE (ERROR, "/_N_WKS_DIR/_N_HANDWZG_SPF")
FOR HH = 0 TO ANZAHL_WZG - 1
AKT_TOOL = GETT(BEZEICHNER[HH],1)
; Nicht existierende WZ anlegen
IF AKT_TOOL==-1
AKT_TOOL = NEWT(BEZEICHNER[HH],1)
$TC_DP1[AKT_TOOL,SCHNEIDE[HH]] = TYP[HH]
$TC_DP3[AKT_TOOL,SCHNEIDE[HH]] = 0
$TC_DP6[AKT_TOOL,SCHNEIDE[HH]] = DIA[HH] / 2
$TC_TP3[AKT_TOOL] = 1
$TC_TP4[AKT_TOOL] = 1
$TC_TP5[AKT_TOOL] = 1
$TC_TP6[AKT_TOOL] = 1
$TC_TP7[AKT_TOOL] = 1
$TC_TP8[AKT_TOOL] = 66
IF ((TYP[HH] == 240) OR (TYP[HH] == 241) OR (TYP[HH] == 242))
$TC_DP9[AKT_TOOL,SCHNEIDE[HH]] = PITCH[HH]
ENDIF
EXISTSNOT = EXISTSNOT + 1
ENDIF
; Nicht vermessene WZ zaehlen
IF NOT ($TC_TP8[AKT_TOOL] B_AND 'B1000')
VERMESSENNOT = VERMESSENNOT + 1
ENDIF
; Handwerkzeuge zaehlen und in Datei schreiben
IF $A_MYMN[AKT_TOOL]==0
WRITE(ERROR,"/_N_WKS_DIR/_N_HANDWZG_SPF", BEZEICHNER[HH])
MAGAZINNOT = MAGAZINNOT + 1
ENDIF
ENDFOR
NACHRICHT = "Werkzeuge: "<<EXISTSNOT<<" angelegt. "<<VERMESSENNOT<<" zu vermessen. "<<MAGAZINNOT<<" Handwerkzeuge"
MSG(NACHRICHT)
M17
DEF INT ERROR, HH
DEF INT EXISTSNOT = 0
DEF INT MAGAZINNOT = 0
DEF INT VERMESSENNOT = 0
; Alte Handwerkzeug Datei löschen
DELETE (ERROR, "/_N_WKS_DIR/_N_HANDWZG_SPF")
FOR HH = 0 TO ANZAHL_WZG - 1
AKT_TOOL = GETT(BEZEICHNER[HH],1)
; Nicht existierende WZ anlegen
IF AKT_TOOL==-1
AKT_TOOL = NEWT(BEZEICHNER[HH],1)
$TC_DP1[AKT_TOOL,SCHNEIDE[HH]] = TYP[HH]
$TC_DP3[AKT_TOOL,SCHNEIDE[HH]] = 0
$TC_DP6[AKT_TOOL,SCHNEIDE[HH]] = DIA[HH] / 2
$TC_TP3[AKT_TOOL] = 1
$TC_TP4[AKT_TOOL] = 1
$TC_TP5[AKT_TOOL] = 1
$TC_TP6[AKT_TOOL] = 1
$TC_TP7[AKT_TOOL] = 1
$TC_TP8[AKT_TOOL] = 66
IF ((TYP[HH] == 240) OR (TYP[HH] == 241) OR (TYP[HH] == 242))
$TC_DP9[AKT_TOOL,SCHNEIDE[HH]] = PITCH[HH]
ENDIF
EXISTSNOT = EXISTSNOT + 1
ENDIF
; Nicht vermessene WZ zaehlen
IF NOT ($TC_TP8[AKT_TOOL] B_AND 'B1000')
VERMESSENNOT = VERMESSENNOT + 1
ENDIF
; Handwerkzeuge zaehlen und in Datei schreiben
IF $A_MYMN[AKT_TOOL]==0
WRITE(ERROR,"/_N_WKS_DIR/_N_HANDWZG_SPF", BEZEICHNER[HH])
MAGAZINNOT = MAGAZINNOT + 1
ENDIF
ENDFOR
NACHRICHT = "Werkzeuge: "<<EXISTSNOT<<" angelegt. "<<VERMESSENNOT<<" zu vermessen. "<<MAGAZINNOT<<" Handwerkzeuge"
MSG(NACHRICHT)
M17
Dies kannst du dann im Programm z.B. an Stelle N145 aufrufen:
N145 TOOLINIT(BEZEICHNER, WRK, TYP, DIA, PITCH, SCHNEIDE, ANZAHL_WZG)
Parameter mit VAR vorgehängt sind Call by Reference, das heisst wenn du diese um Zyklus beschreibst werden die Werte im Parameter des aufrufenden Programmes auch geändert.
Parameter ohne VAR sind Call by Value, das heisst es wird nur der Wert, welcher im Moment des Aufrufs drin steht an den Zyklus übergeben. Werteänderungen von diesen Parametern im Zyklus wirken sich nicht auf das aufrufende Programm aus.
Felder müssen mit Call by Reference aufgerufen werden.
Zudem habe ich noch zwei Befehle in die PROC Zeile geschrieben:
DISPLOF: hierbei wird die Anzeige des Zyklus unertdrückt. Die Anzeige bleibt auf dem aufrufenden Satz stehen, wie es z.B. bei den Bohrzyklen auch der Fall ist.
SBLOF: Der Einzelsatz wird ausgeschaltet, wodurch das ganze Programm bis zum M17 oder einem SBLON ausgefürt wird, auch wenn der Einzelsatz an der Maschine aktiviert ist.
PS: Der CNC Arena Editor löscht die Leerzeichen vor den Kommentaren
--------------------
Freundliche Grüsse
DMC635V
DMC635V
28.02.2015, 15:43 Uhr
Guest_guest_*
Themenstarter
Gast
QUOTE
Mit der Übersicht hast du natürlich recht. (A propos Übersicht, kann man eigentlich keine Unterordner in den Anwenderzyklus- bzw. Unterprogrammordner anlegen, oder übersehe ich da nur was?) Bisher habe ich mich ein wenig vor den nötigen Umbaumaßnahmen gescheut.
Du hast schon richtig gesehen. Die Ordnerstruktur in der NC ist ganz flach und strukturell vorgegeben. Ausnahme ist das WPD-Verzeichnis, das ja auch mehrere Werkstücke aufnehmen soll.
Grundsätzlich sollte ja auch nur das gerade zu bearbeitende Werkstück geladen sein, was auf einer MMC100.2 oder PCU20 ja nicht ganz so einfach ist... .
Denn im Standard ist die Anzahl der in der NC speicherbaren (Bei MMC103 und PCU50: geladenen) Programme auf 100 begrenzt. Das ist übrigens völlig unabhängig, vom tatsächlich zur Verfügung stehenden Speicher und sollte auch nicht verändert werden. Mitgezählt werden auch die Anwender- und Hersteller-Zyklen. Die Siemens-Zyklen sind da, glaube ich außen vor. Sicher bin ich da aber nicht .
Wissenswert ist auch, daß der Dateipfad incl. Dateiname und Trennzeichen maximal 128 Bytes lang sein darf.
Damit ist auch die flache Datenstruktur in der NC erklärt.
07.03.2015, 12:27 Uhr
So habe am Montag direkt mal alles umgebaut. Verlief auch alles problemlos bis auf "fehlendes Satzende"
Seitdem ist keine Alarmmeldung mehr aufgetaucht.
Der Postprozessor ist jetzt auch deutlich schlanker, so dass ich da so langsam auch wieder durchsteige.
Habe allerdings schon 10 dieser Zyklen "verbraucht". Vielleicht muss ich irgendwann mehrere Zyklen zu Einem zusammenfassen.
Diesem dann einen zusätzlichen Parameter übergeben der den gewünschten Teilzyklus codiert. Und schließlich in einer IF...ENDIF
Struktur in den jeweiligen Teil verzweigen. ...OH weh da war ja was mit Spaghetti...
Auf jeden Fall nochmal viele an Euch.
Seitdem ist keine Alarmmeldung mehr aufgetaucht.
Der Postprozessor ist jetzt auch deutlich schlanker, so dass ich da so langsam auch wieder durchsteige.
QUOTE
Denn im Standard ist die Anzahl der in der NC speicherbaren (Bei MMC103 und PCU50: geladenen) Programme auf 100 begrenzt.
Habe allerdings schon 10 dieser Zyklen "verbraucht". Vielleicht muss ich irgendwann mehrere Zyklen zu Einem zusammenfassen.
Diesem dann einen zusätzlichen Parameter übergeben der den gewünschten Teilzyklus codiert. Und schließlich in einer IF...ENDIF
Struktur in den jeweiligen Teil verzweigen. ...OH weh da war ja was mit Spaghetti...
Auf jeden Fall nochmal viele an Euch.
1 Besucher lesen dieses Thema (Gäste: 1)
0 Mitglieder: