Programmiervorschläge für Problem beim Netzwerkeinfügen(AWL)

Sandra Siegrist · 13 Februar 2004

Hallo

Für Anlagen im Chemiebereich mache ich oft Schrittketten in AWL. Diese baue ich wie folgt auf:

Code:

*****************
Netzwerk 3: 
*****************
exec: SET   

      AUF   DB    40
      UN    DBX  396.0
      SPB   di01                         // NW 1
      UN    DBX  396.1
      SPB   di02                         // NW 2
      UN    DBX  396.2
      SPB   di03                         // NW 3
      UN    DBX  396.3
      SPB   di04                         // NW 4
      UN    DBX  396.4
      SPB   stop                         // NW stop
BEA
*****************
Netzwerk4:
*****************
di01: U     M      8.4
      SPB   d041

      L     DB40.DBB  870
      T     AB    16                    // Init syringe 1

      L     DB40.DBB  880
      T     AB    17                    // Init syringe 2


      L     0                           // Timer initialisieren
      T     DB40.DBD  408               // TimeCnt1
      SET   
      =     M      8.4

d041: L     DB40.DBD  408               // tmp
      L     60                          // 6 s
      >D    

      =     DBX  396.0                  // Gesetzt, wenn Netzwerk ausgeführt
      NOT   
      =     M      8.4

BEA

Das Netzwerk 4 ist nur ein Beispiel. Es würden noch weitere nachfolgen, sind aber alle etwa so aufgebaut.
Zu meinem Problem:
Wenn ich nun ein Netzwerk dazwischen einfügen will, verschieben sich die Sprungmarken und auch die Bits die ich setze aus Netzwerk 3. Dies ist dann immer ein grosser Aufwand, das ganze fehlerfrei in allen nachfolgenden Netzwerken zu ändern.
Hat jemand von Euch eine elegantere Lösung?
(Kann auch in SCL sein)

Vielen Dank
MfG,
Sandra

michi · 13 Februar 2004

Hallo Sandra,

Ich bin ganz begeistert bei Schrittkettenprogrammierung
den Sprungverteiler einzusetzen. Was haelst du hier von :

Code:

 LAR1  P#M 8.0   //Start offset 
      L     #netzNr // Aktuelle SchrittNr (0...8)
 

// *************************************************
      +AR1    // Pointer addressieren
    

// dann der Sprungverteiler

     L     #netzNr // 0....256
      SPL   end
      SPA   ne0
      SPA   ne1
      SPA   ne2
      SPA   ne3
      SPA   ne4
      SPA   ne5
      SPA   ne6
      SPA   ne7
end:  SPA   zue

//********************************************
ne0:   U      [AR1,P#0.0]  // Start Netzwerk = Schritt 0
      ...
      ...

      = [AR1,P#0.0]

 // jetzt muss die NetzNr erhoeht werden, wenn du es nicht
// wo anders machs
      L     #netzNr 
       INC
       T    #netzNr 
      spa end 
//*************************************
ne1: U      [AR1,P#0.0]  // Start Netzwerk = Schritt 1


 // und soweiter

mfg

Michael

Sandra Siegrist · 16 Februar 2004

Hoi Michi

Vielen Dank für die Antwort. Deine Lösung ist viel eleganter als meine. Ich werde sie also ab sofort einsetzen.

MfG,
Sandra

Anonymous · 16 Februar 2004

Warum überhaupt Merkerschrittketten???

Wenn schon schon mit Sprungverteiler, dann kommt doch gleich von den ärgerlichen Merkerschrittketten weg.

L #SNR // Schrittnummer
SPL CLR // Sprungziel bei SNR>max
SPA CLR // 0-Schritt, RESET
SPA S1 // Startschritt
SPA S2
SPA S3
SPA S4
SPA S5

CLR: L 1 // CLR : Ablauf löschen, RESET
T #SNR // Schrittnummer auf Startschritt

SET // VKE = 1
// hier die bei RESET zu löschenden Merker eintragen

SPA END

NEXT: L #SNR // NEXT : Schrittnummer auf nächsten
+ 1 // Schritt
T #SNR
END: BEA
// für Codeausführung nach der SRK, END hinter das letzte Schritt-NW stellen

S1: U E1.0
U M10.0
= M11.0
SPB NEXT
SPBN END // oder alternativ BEA

S2: U E2.0
U E2.1
SPBN END

L DB20.DBW0
L DB20.DBW1
+ I
T DB20.DBW2
SPA NEXT

Zottel · 16 Februar 2004

Na ja, Sandra sprang in Abhängigkeit von ihren Merkern.
Das Hochzählen der Schrittnummer funktioniert natürlich nur wenn die Kette ausschliesslich linear (ohne Alternativzweige) durchlaufen wird. Es kann natürlich stattdessen (statt INC) die Nummer des nächsten Zielnetzwerks direkt eingetragen werden.
Das bedeutet abe schon wieder Schwierigkeiten beim Aufrücken.

Ein Sprungverteiler auf der Basis einzelner Merker könnte auch so aussehen:

Code:

U M 10.0
SPB ne0
U M 10.1
SPB ne1
U M 10.2
SPB ne2
...u.s.w.
SPA fehler

ne0:
    U E 6.5 // irgendeine Weiterschaltbedingung
    R M10.0 // fertig mit diesem Schritt
    S M10.1 // weiter mit Schritt 1 
    U E 6.6 // irgendeine andere Weiterschaltbedingung 
    R M10.0 // fertig mit diesem Schritt
    S M11.2 // weiter mit Schritt 11 
    BE  	// ohne Weiterschaltbedingung bleibt es bei
              //diesem Schritt

Statt BE kann auch ein SPA ende stehen.
Durch Austausch der Zielschritte lässt sich hier jede beliebige
Schrittfolge einstellen. Die Weiterschaltbedingung kann natürlich auch viel komplizierter sein.

Anonymous · 16 Februar 2004

Schrittketten mit Sprungverteiler

Ich verwende seit 10 Jahren für Schrittketten nur Sprungverteiler (selbst bei S5). Dies ist viel einfacher änderbar. Ein riesen Vorteil ist die Übersichtlichkeit. Wenn richtig Kommentiert wurde kann ich sofort erkennen was hier geschieht.

Der Kopf der Schrittkette sieht dabei immer gleich aus. Es wird immer nur der Code des jeweiligen Schritts ausgeführt.
Dieses System bietet die besten Voraussetzungen für Ereignisorientiertes Programmieren.
D.h. Zuweisungen für Antrieb Ein werden nicht wie bei Merkerschrittketten üblich mit

O Schritt1
O Schritt2
O SchrittX
= AntriebEin

erledigt, sondern im Schritt wird ein Merker AntriebEin gesetzt und in einem spätern Schritt wieder gelöscht. Der Eintrag im CLR-Zweig
R AntriebEin
löscht den Merker bei Durchlauf oder Initialisierung der Schrittkette automatisch. Stehen bleibende Merker gehören somit der Vergangenheit an. Änderungen müssen nur im Schritt selbst und nicht in einer Verknüpfung irgendwo im Programm durchgeführt werden.

Man kann sich zusätzlich noch einen Programmweiten Merker für Schrittketten Reset machen. Diesen bearbeitet man im Netzwerk vor dem Kopf.

Code:

         UN RESET
         SPBNB _001
         L 0
         T #SRN
_001: NOP 0

Code:

      L     #SNR                        // Schrittnummer
      SPL   CLR                         // Sprungziel bei SNR>max
      SPA   CLR                         // 0-Schritt, RESET
      SPA   S1                          // Startschritt
      SPA   S2
      SPA   S3
      SPA   S4
      SPA   S5

CLR:  L     1                           // CLR : Ablauf löschen, RESET
      T     #SNR                        // Schrittnummer auf Startschritt

      SET                               // VKE = 1
// hier die bei RESET zu löschenden Merker eintragen
      R M1.0                          // Antrieb Aus

      SPA   END

NEXT: L     #SNR                        // NEXT : Schrittnummer auf nächsten
      +     1                           // Schritt
      T     #SNR
END:  BEA   
//  für Codeausführung nach der SRK, END hinter das letzte Schritt-NW stellen

Die einzelnen Schritte können dann je nach Anforderung unterschiedlich aussehen. Jedenfalls benötigt man außer einem Schrittzähler keine weiteren Schrittmerker:

Code:

S1:   U E1.0
      U E1.1
      S M1.0                         // Antrieb Ein
      SPB NEXT
      SPA END

S2:   U E2.0
      U E2.1
      SPBN END

      // Ausführungsteil Schritt 2
      R M1.0                         // Antrieb Aus
      L 10
      T DB10.DBW0

      SPA NEXT        // Zähler auf nächsten Schritt

usw.

Zottel · 16 Februar 2004

Re: Schrittketten mit Sprungverteiler

SPS-GURU schrieb:
...
NEXT: L #SNR // NEXT : Schrittnummer auf nächsten
+ 1 // Schritt
T #SNR
END: BEA

[/code]

Ich sehe wieder, dass die Schritte weitergezählt werden. Einfügen ist leicht, solange es nur einen möglichen Folgeschritt gibt. Ansonsten musst du die Nummer direkt laden und beim Einfügen (die nummern der nachfolgenden Netzwerke) neu nummerieren.
Da könnte es einfacher sein, statt zu zählen gleich immer die Nummer de Nachfolgenetzwerkes zu laden und zum Einfügen unbenutzte Nummern zu wählen a la:

Code:

NW4->NW5 wird erstezt durch: NW4->NW10000->NW5

Das erspart dann das Neunummerieren.
In einem Punkt halte ich Nummern für besser als Merker:
Prinzipbedingt kann bei Programmierfehlern eine Merkerbasierte Schrittkette mit n Merkern 2 hoch n Zustände annehmen, von denen die meisten illegal sind.
Da habe ich schon etliche Maschinen gesehen, die man aus einem seltsamen Betriebszustand nur durch Abschalten Not-Aus oder Stop der SPS wieder zum "Leben" erweckt.
An dieser Stelle trägt aber dein "begleitendes" speicherndes Ein- und Ausschalten der Verbraucher nicht zur Übersichtlichkeit bei:
Wenn es mehr als eine Folgezustand gibt, musst du immer sicher sein, dass jedes auch das komplementäre "R" oder "S" enthält.

Anonymous · 17 Februar 2004

An dieser Stelle trägt aber dein "begleitendes" speicherndes Ein- und Ausschalten der Verbraucher nicht zur Übersichtlichkeit bei:
Wenn es mehr als eine Folgezustand gibt, musst du immer sicher sein, dass jedes auch das komplementäre "R" oder "S" enthält.

Was heist mehr als ein Folgezustand. Mehr als Ein/Aus gibts weder bei Ventilen noch bei Antrieben.

Das komplementäre "R" (also AUS) ist automatisch immer vorhanden, sonst funktioniert dein Programm nicht. Ebenfalls müssen alle Merker die in der Schrittkette gesetzt werden im "CLR-Zweig mit 'R' stehen". Somit ist auch bei undefinierten Abbrüchen sichergestellt, daß ich wieder einen definierten Startzustand habe.

Zugegeben, die Methode entspricht in keinster Weise, das was man aus Büchern, in Schulungen oder bei Siemens-Kursen gelernt bekommt. Die erste Reaktion auf diese Programmierweise ist immer Ablehnung (und zwar solange bis man es kapiert hat).

Ich habe mit meinen Kollegen über die letzten etwa 10 Jahre festgestellt, daß wir mit dieser Methode mindestens doppelt so schnell in der Programmierung sind. Dann vergleich noch die Fehlersuche im Status, bis du mit Merkerschrittketten die einzelenen Netzwerke durch hast und endlich weist wo die Anlage steht, bin ich mit der Sprung-Schrittkette längst fertig. (Vor allem Step 7 glänzt nicht gerade durch Geschwindigkeit im Status). Wir Programmieren und warten mit 3 Mann Anlagen, für die in Anderen Firmen/Abteilungen ein Vielfaches des Personals benötigt wird. Für uns sind Merkerschrittketten definitiv ausgestorben. Wenns ein Kunde speziell haben möchte, dann muß er dafür extra bezahlen!

Graph 7 braucht man überhaupt nicht, da die Aktionen leserlich im Klartext im Programm stehen. Vor allem sind diese Sprungverteiler um ein Vielfaches schneller als die Graph 7 Konstruktionen (vom Preisvorteil mal ganz abgesehen). Weiterhin kann man mit Visualisierungstools direkt die Schrittnummer verarbeiten und z.B. direkt dazu Textlisten hinterlegen, so hat man sofort den aktuellen Schrittstatus im Klartext (z.B. "Warten auf Produkt", "Fahre zu Punkt x/y") ...)

Ich sehe wieder, dass die Schritte weitergezählt werden. Einfügen ist leicht, solange es nur einen möglichen Folgeschritt gibt. Ansonsten musst du die Nummer direkt laden und beim Einfügen (die nummern der nachfolgenden Netzwerke) neu nummerieren.
Da könnte es einfacher sein, statt zu zählen gleich immer die Nummer de Nachfolgenetzwerkes zu laden und zum Einfügen unbenutzte Nummern zu wählen a la:

Zuerst wird während der Entwicklungsphase der Ablauf so runterprogrammiert, wie man meint, dass es funktioniert. Dann werden Schritte eingefügt mit Sprungmarken wie etwa S1a, S1b. Wenn dann alles funktioniert kann man wegen der Übersichtlichkeit nochmal durchgehen und per Hand die Sprungmarkennummern anpassen (S1, S2, S3 ...), das läßt sich leider nicht ganz vermeiden. Aber bedenke dabei, was du bei Merkerschrittketten alles ändern mußt ( - da wird man wahnsinnig!)

Zottel · 17 Februar 2004

Anonymous schrieb:
Was heist mehr als ein Folgezustand. Mehr als Ein/Aus gibts weder bei Ventilen noch bei Antrieben.

Zum Vergrößern anklicken....

Dass auf einen Schritt 1 abhängig von Prozessvariablen ein Schritt
2a oder 2b oder 2c folgen kann.
Vielleicht wird in Schritt 1 ein Produkt in eine Station zur Erkennung gefördert.
Je nachdem, was dort erkannt wird geht es so, so oder anders weiter.

Anonymous · 17 Februar 2004

Schrittketten mit Sprungverteiler

An dieser Stelle trägt aber dein "begleitendes" speicherndes Ein- und Ausschalten der Verbraucher nicht zur Übersichtlichkeit bei:
Wenn es mehr als eine Folgezustand gibt, musst du immer sicher sein, dass jedes auch das komplementäre "R" oder "S" enthält.

Was heist mehr als ein Folgezustand. Mehr als Ein/Aus gibts weder bei Ventilen noch bei Antrieben.

Das komplementäre "R" (also AUS) ist automatisch immer vorhanden, sonst funktioniert dein Programm nicht. Ebenfalls müssen alle Merker die in der Schrittkette gesetzt werden im "CLR-Zweig mit 'R' stehen". Somit ist auch bei undefinierten Abbrüchen sichergestellt, daß ich wieder einen definierten Startzustand habe.

Zugegeben, die Methode entspricht in keinster Weise, das was man aus Büchern, in Schulungen oder bei Siemens-Kursen gelernt bekommt. Die erste Reaktion auf diese Programmierweise ist immer Ablehnung (und zwar solange bis man es kapiert hat).

Ich habe mit meinen Kollegen über die letzten etwa 10 Jahre festgestellt, daß wir mit dieser Methode mindestens doppelt so schnell in der Programmierung sind. Dann vergleich noch die Fehlersuche im Status, bis du mit Merkerschrittketten die einzelenen Netzwerke durch hast und endlich weist wo die Anlage steht, bin ich mit der Sprung-Schrittkette längst fertig. (Vor allem Step 7 glänzt nicht gerade durch Geschwindigkeit im Status). Wir Programmieren und warten mit 3 Mann Anlagen, für die in Anderen Firmen/Abteilungen ein Vielfaches des Personals benötigt wird. Für uns sind Merkerschrittketten definitiv ausgestorben. Wenns ein Kunde speziell haben möchte, dann muß er dafür extra bezahlen!

Graph 7 braucht man überhaupt nicht, da die Aktionen leserlich im Klartext im Programm stehen. Vor allem sind diese Sprungverteiler um ein Vielfaches schneller als die Graph 7 Konstruktionen (vom Preisvorteil mal ganz abgesehen). Weiterhin kann man mit Visualisierungstools direkt die Schrittnummer verarbeiten und z.B. direkt dazu Textlisten hinterlegen, so hat man sofort den aktuellen Schrittstatus im Klartext (z.B. "Warten auf Produkt", "Fahre zu Punkt x/y") ...)

Ich sehe wieder, dass die Schritte weitergezählt werden. Einfügen ist leicht, solange es nur einen möglichen Folgeschritt gibt. Ansonsten musst du die Nummer direkt laden und beim Einfügen (die nummern der nachfolgenden Netzwerke) neu nummerieren.
Da könnte es einfacher sein, statt zu zählen gleich immer die Nummer de Nachfolgenetzwerkes zu laden und zum Einfügen unbenutzte Nummern zu wählen a la:

Zuerst wird während der Entwicklungsphase der Ablauf so runterprogrammiert, wie man meint, dass es funktioniert. Dann werden Schritte eingefügt mit Sprungmarken wie etwa S1a, S1b. Wenn dann alles funktioniert kann man wegen der Übersichtlichkeit nochmal durchgehen und per Hand die Sprungmarkennummern anpassen (S1, S2, S3 ...), das läßt sich leider nicht ganz vermeiden. Aber bedenke dabei, was du bei Merkerschrittketten alles ändern mußt ( - da wird man wahnsinnig!)

Anonymous · 17 Februar 2004

Graph

Graph gibt auch die Schrittnummer aus. Und wer Graph schon mal benutzt hat schätzt die Vorteile. Ich denke es gibt 3 Gründe wieso ihr kein Graph nehmt

1. ihr habt keine Ahnung

2. ihr knausert wegen paar ¤ aber seht nicht dass ihr euch das Leben damit schwer macht

3. wegen eurem Geiz habt ihr euch nur Software von Trittbrettfahrern gekauft die kein Graph haben

Ingo dV · 17 Februar 2004

Schrittkette

@Sps Guru

Ich programmiere meine Schrittketten ähnlich.
Das Feedback vom Servicepersonal und die einfachen Erweiterungsmöglichkeiten geben dieser Art zur Projektieren recht.

Programmiervorschläge für Problem beim Netzwerkeinfügen(AWL)

Sandra Siegrist

Level-1

michi

Level-1

Sandra Siegrist

Level-1

Anonymous

Guest

Zottel

Level-3

Anonymous

Guest

Zottel

Level-3

Anonymous

Guest

Zottel

Level-3

Anonymous

Guest

Anonymous

Guest

Ingo dV

Level-2

Similar threads

Wir schützen deine Privatsphäre