Siemens
Siemens

Digital Industries, Motion Control, Machine Tool Systems

Schachtelungskonflikt in Kontrollstrukturen

Beitrag 21.02.2015, 11:21 Uhr
Sacculina
Sacculina
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 13.01.2010
Beiträge: 114
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.
   
Beitrag 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.
   
Beitrag 21.02.2015, 13:43 Uhr
Sacculina
Sacculina
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 13.01.2010
Beiträge: 114
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,
   
Beitrag 21.02.2015, 13:47 Uhr
nixalsverdruss
nixalsverdruss
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 16.11.2003
Beiträge: 1.511
QUOTE (Sacculina @ 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,



wenn du hin und wieder merkwürdig programmierst kann das vorkommen !

ohne das Programm zu sehen wir das in Traumdeutung enden.
   
Beitrag 21.02.2015, 13:58 Uhr
Sacculina
Sacculina
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 13.01.2010
Beiträge: 114
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.

Angehängte Datei  Beispiel.mpf ( 5.16KB ) Anzahl der Downloads: 74


Der Beitrag wurde von Sacculina bearbeitet: 21.02.2015, 14:01 Uhr
   
Beitrag 21.02.2015, 17:57 Uhr
Guest_guest_*
Themenstarter
Gast


Schachtelungs-Alarme gibt es einige...

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?


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. wink.gif
   
Beitrag 21.02.2015, 18:24 Uhr
Sacculina
Sacculina
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 13.01.2010
Beiträge: 114
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.

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.
   
Beitrag 26.02.2015, 01:36 Uhr
Sacculina
Sacculina
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 13.01.2010
Beiträge: 114
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.

Angehängte Datei  Schachtelung_N178.txt ( 473.98KB ) Anzahl der Downloads: 39
   
Beitrag 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 wink.gif , bieten ein ganz praktisches Feature: Unterprogramme. thumbs-up.gif
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. tounge.gif
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 )
Viel Erfolg!
   
Beitrag 26.02.2015, 19:41 Uhr
DMC635V
DMC635V
Level 6 = Community-Doktor
******
Gruppe: Mitglied
Mitglied seit: 12.08.2010
Beiträge: 844
QUOTE (guest @ 26.02.2015, 12:54 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.

QUOTE (guest @ 26.02.2015, 12:54 Uhr) *
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 wink.gif , bieten ein ganz praktisches Feature: Unterprogramme. thumbs-up.gif

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
   
Beitrag 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... wink.gif
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.


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


@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.
   
Beitrag 27.02.2015, 19:18 Uhr
DMC635V
DMC635V
Level 6 = Community-Doktor
******
Gruppe: Mitglied
Mitglied seit: 12.08.2010
Beiträge: 844
QUOTE (guest @ 26.02.2015, 20:20 Uhr) *
@DMC635V
Nein ich meine das nachladen EXTERN (ausserhalb der NC) gespeicherter Daten mitttels EXTCALL. Daran hatte wohl auch Sacculina keinen Zweifel... wink.gif
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 sorry.gif

Der Beitrag wurde von DMC635V bearbeitet: 27.02.2015, 19:20 Uhr


--------------------
Freundliche Grüsse
DMC635V
   
Beitrag 28.02.2015, 02:10 Uhr
Sacculina
Sacculina
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 13.01.2010
Beiträge: 114
Erstmal danke.gif für eure Antworten.

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.

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.

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.
   
Beitrag 28.02.2015, 11:14 Uhr
Hexogen
Hexogen
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 29.09.2004
Beiträge: 1.813
QUOTE (Sacculina @ 26.02.2015, 02:36 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





-----------------------------------------------------------------------------------------------------------------------------
   
Beitrag 28.02.2015, 14:44 Uhr
DMC635V
DMC635V
Level 6 = Community-Doktor
******
Gruppe: Mitglied
Mitglied seit: 12.08.2010
Beiträge: 844
QUOTE (Sacculina @ 28.02.2015, 02:10 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.


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


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
   
Beitrag 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... wink.gif .
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 wacko.gif .
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.
   
Beitrag 07.03.2015, 12:27 Uhr
Sacculina
Sacculina
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 13.01.2010
Beiträge: 114
So habe am Montag direkt mal alles umgebaut. Verlief auch alles problemlos bis auf "fehlendes Satzende" wacko.gif
Seitdem ist keine Alarmmeldung mehr aufgetaucht. spitze.gif

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

Auf jeden Fall nochmal viele danke.gif an Euch.
   
1 Besucher lesen dieses Thema (Gäste: 1)
0 Mitglieder: