Was haltet Ihr von Step7 V5.2

[casius]

Zuviel Werbung?
-> Hier kostenlos registrieren

:evil: Also ich habe neulich ein neues Notebook bekommen und habe dann erst mal die neue Step7 V5.2 installiert.
Hätte ich das doch bloß nicht gemacht!
Ich kann nur jeden warnen der mit dem Gedanken spielt auf die neue Version umzusteigen!!! Last die Finger davon!!!!!!!!!!

Welcher Idiot hat da eigentlich bei Siemens diese Verschlimmbesserungen zu verantworten?
Die Lokalvariablendefinition kann man jetzt voll verbrennen. Übersichtlicher soll das sein? Einfacher? Da geht ja gar nichts mehr.

Die Funktion "Suchen und Ersetzen" kann jetzt z.B. nicht mehr auf die Lokalvariablen angewendet werden.
Mehr als eine Variable kann man auch nicht mehr markieren und kopieren.

Wenn ich könnte würde ich noch heute den mist wieder vom Rechner schmeißen und die alte Version 5.1 installieren.

Welche Erfahrungen habt Ihr mit der neuen Version gemacht? Bin ich der Einzige der sich über die neue Version aufregt? Weiß jemand einen Trick wie man doch wieder Vernünftig mit den Lokalvariablen arbeiten kann?

 

[Martin Glarner]

Hallo zusammen,
Für alle die ausschliesslich in AWL programmieren, kann ich die Quellenprogrammierung empfehlen. Wir haben dadurch viel weniger Probleme mit neuen Version, wie z.B. die Version 5.2.

Leider hat die Firma Siemens in der Version 5.2 den Quelleneditor vom SCL für die AWL-Programmierung übernommen. Dies hat den grossen Nachteil, dass die Tabulatoren in Space umgewandelt werden. Bei Aenderungen müssen die Leerzeichen dauernd angepasst werden, was mit Tabulatoren viel weniger der Fall war.

Den Symbolikeditor fand ich schon immer schlecht, darum schreiben wir alle Symboltabellen in Excel
Die Datenbausteine schreiben wird ebenfalls im Excel.

Ich habe aus unserem Firmenhandbuch das Kapitel zur Quellenprogrammierung kopiert.


6 Quellenprogrammierung
Die optimale Programmiermethode für umfangreiche Programme ist die Erstellung einer Quelldatei. Sie eignet sich besonders für die Erstellung von (eigenen) Standardbausteinen mit symbolischer Programmierung zur mehrfachen Anwendung. Diese Methode ist sogar die einzig mögliche, um Ihr Programm mit einem Ausleseschutz (KNOW_HOW_PROTECT) zu versehen.

6.1 Vor- / Nachteile der Quellenprogrammierung
6.1.1 Vorteile
· Die Quelldateien können während der Bearbeitung zu einem beliebigen Zeitpunkt gespeichert werden auch wenn noch nicht alle Symbolnamen in der Symboldatei eingetragen wurden.
· Instanz-DBs können automatisch aktualisiert werden
· Sehr grosse Zeitersparnis beim editieren der Bausteine.
· Namen und Parameter von Bausteinen können in die Zwischenablage kopiert werden
· Ein Umverdrahten von Programm entfällt, da die absolut Adressen der Operanden einfach in der Symboldatei geändert werden und die Quelldatei neu übersetzt wird.
· Einzelne Quelldateien können sehr einfach aus dem Step7 exportiert oder importiert werden.
· Standardbausteine können als einfache Quelldatei auf einem Server verwaltet werden.
· Datenbausteine können vom Excel in die Quelle importiert werden.
· Einzelne Bausteine können per eMail versendet werden.
· Bausteine können geschützt werden. (KNOW_HOW_PROTECT)
· Keine Datenkonsistenzprüfung nötig.
· Schnelleres Arbeiten im Netzwerk in multiuser Projekten
· Doppelte Sicherheit da Quellen und Bausteine in Projekt vorhanden sind.


6.1.2 Nachteile
Folgende Punkte können nicht direkt in der Quelldatei genutzt werde.

· Es kann nur in AWL programmiert werden.
· Keine Auswahlhilfe für Operanden und Befehle.
· Bausteinaufrufe in den AWL-Quellen müssen selber aufgebaut werden. (Ausnahme SCL)
· Es kann keine Referenzliste benutzt werden. (z.B. Gehe zu Verwendungsstelle)
· Der Baustein kann nicht direkt aus der Quelle in die Steuerung geladen werden.
· Die AWL-Quelle kann nicht beobachtet werden.

 

[casius]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für den Tipp, funktioniert ganz gut.
Ich habe aber bisher kaum die Quellenprogrammierung genutzt, muss ich mir wohl jetzt mal genauer ansehen.
Bei der guten alten Version 5.1 war das auch nicht nötig, da konnte man das gleiche Ergebnis auch mit dem normalen AWL Editor erreichen.

 

[Ulrich Klakow]

Einseitig

Ich arbeite mit der V5.2 schon eine längere Zeit und war nur mit der aller ersten Version (ohne Hotfix) nicht zufrieden. Seit Hotfix3 finde ich sie gut, und mit SP1 sehr gut.
Warum:
Das mit den Lokaldaten ist nur ein sehr kleiner Bereich in dem sich die
Änderungen auswirken, was für mich viel wichtiger ist, das ich jetzt im Variablenteil Zugriff auf ALLE Variablen habe bis hinunter zu einzelnen Bit's in einer Instanzvariablen.
Wer hier immernoch an Stellen, an denen zu einem Programmteil statische Daten benötigt werden, mit FC's und DB's benutzt hat immer noch nicht kappiert wo die wesendlichen Unterschiede zu S5 liegen.
Erzeugt doch mal z.B. einen FB (z.B. FB10) in dem Ihr einen drei Instanz-FB's für die Steuerung von z.B. drei Motoren in der Var.Tabelle einfügt.
Etwa so:

OB1:

CALL "AnsteuerungMotoren",iFB10 // CALL FB10,DB10
...
BE

im FB10
Var.Tabelle
Motor1 FB11
Motor2 FB11
Motor3 FB11

Programmteil:

Call Motor1
...
(Parameterlister vom FB11 für Motor1)
...

Call Motor2
...
(Parameterlister vom FB11 für Motor2)
...
Call Motor3
...
(Parameterlister vom FB11 für Motor3)
...
BE

Ende vom Beispiel

Wenn du jetzt z.B. aus dem FB10 auf eine Variable für der Motor3 zugreifen willst, dann kannst du Sie einfach aus der Tabelle kopieren.

Das sind bei weitem nach nicht alle Vorteile der neuen Version, aber für
mich bedeuten Sie einen erheblichen Gewinn an Zeit!

Gruß, Ulrich

 

[casius]

:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
Das du erkannt hast das es um Statische Daten geht ist ja schon ganz gut, aber ich fürchte den Rest hast völlig falsch verstanden.

Noch einmal für Ulrich, auch ganz langsam.

1. Es wird ein FB geschrieben mit zugehörigem Instanz DB. (Der wird automatisch generiert.)

2. Das Programm wird als Standart ausgelegt und ist etwas komplizierter. (Von wegen Motoren, das ist ja lächerlich).

3. Da das Programm als Standart ausgelegt ist, sind alle Bezeichnungen noch vorläufig und nicht endgültig.
Beispiel: Es sollen mehrere Zylinder mit je zwei Endlagen und zwei Ventilen gesteuert werden. Die Lokaldaten sehen dann etwa wie folgt aus.

S_A01 BOOL Sensor: A01
S_A02 BOOL Sensor: A02
S_A03 BOOL Sensor: A03
S_A04 BOOL Sensor: A04
A_A01 BOOL Ausgang: A01
A_A02 BOOL Ausgang: A02
A_A03 BOOL Ausgang: A03
A_A04 BOOL Ausgang: A04

4. Wenn jetzt das eigentliche Programm geschrieben wird, braucht man nur noch die Platzhalter z.B. "A01" durch einen vernünftigen Kommentar ersetzen, z.B. "Hubzylinder oben". Wenn man das für alle Platzhalter durchführt hat man in Handumdrehen ein fertiges Programm, mit Verriegelungen, Handbetrieb, Störmeldungen etc.

5. Und darum geht es, dass ist in der neuen Step7 V5.2 nicht mehr so einfach möglich. Nur dem Umweg über die Quelle funktioniert noch.

6. Also bitte das nächste mal etwas überlegen, bevor man so Sachen schreibt wie, da hat do jemand den Unterschied nicht kapiert. Lieber erst mal vor der eigenen Türe kehren.
:idea:

 

[Ulrich Klakow]

Zuviel Werbung?
-> Hier kostenlos registrieren

Antwort an casius

Danke für deine Erklärungen,

bloss haben wir uns offensichtlich nicht verstanden.

zu 1) Was ich geschrieben habe bezog sich erstmal auf die V5.2
im allgemeinen.

zu 2) Ich habe den Motor-FB nur als Implementierungsbeispiel genommen, was mit einem FB gemacht wird und wie komplex der ist,
hat damit NICHTs zu tun.

zu 3+4) Ich habe selber einen Baustein geschrieben der unteranderem
z.B. solche Zylinder steuern kann. Offensichtlich veränderst du die lokalen Variablen einer FB-Programmvorlage so,
das für jedes Gerät eine neuer FB entsteht der gerätespezifische Var.Namen hat.
Das bedeutet, das du für jeden Gerätetype einen eigenen FB mit DB oder als Multiinstanz benötigst.
Du hast offensichtlich noch nicht verstanden das mit Step7 ein erster
Ansatz zur Objektorientierung in die Automatisierung einzug gehalten hat.

Du schreibst das dein Baustein z.B. Verriegellungen, Handbetrieb, Sörmeldungen usw. macht,
kannst du mir mal erzählen wie sich die Steuerungsanforderungen eines z.B. Zylinders zwischen Handbetrieb und Automatikbetrieb ändert?
Der braucht nur zu wissen, ob Er oben oder unten sein soll.
Er soll sich natürlich um seine Meldesignale kümmern und soll natürlich auch Störungsmeldungen erzeugen,
aber die Anlagenbetriebsart hat in so einem Baustein NICHTs verloren.

zu 5) Das es hier Einschränkungen mag sein, schreib das doch mal
an Siemens.

zu 6) Ich habe sehr wohl verstanden um was es dir geht, ich schreibe selber seit 15 Jahren SPS-Programme.

Denn FB den du geschrieben hast behandelt Geräte mit zwei stabilen Endlagen.
Wenn man die Zustände solch eines Gerätes in einem Programm abbilden will (Abbildung=Programm),
dann kann man hierfür eine Geräteklasse deklarieren (=Steuerungsobjekte) die durch eine Statemachine mit vier Zuständen dargestellt wird.
Solch eine Geräteklasse kann man jetzt durch einen FB abbilden.

Ich habe mit der S5 vor ca. 13 Jahren angefangen solch einen Ansatz zu realissiern. Als S5-Version gibt es hiervon drei Vorläufer und als S7-Version bin ich derzeit in der zweiten Version.

Dem FB ist es egal ob hierdurch ein Zylinder, ein Motor ein Ventil eine Förderstrecke eine Verriegellung oder sonstwas gesteuert wird.
Es ist so flexibel, dass es mit jeder Art Gerät das sich durch dieser Geräteklasse beschreiben läst zurechtkommt.

Die Abarbeitung des FB's ist so schnell, dass sich mit einer 412 bei ca. 50 Geräten und sehr komplexen Zusatzfunktionen eine Zykluszeit <6ms einstellt.

Kannst du mit deinem Baustein feststellen wie lange er beim wechsel seiner Betriebslage z.B. zu hochfahren eines Zylinders gebraucht hat?

P.S. Vor meiner Tür wird regelmässig gekehrt, schlieslich habe ich 9-Jahre im Schwabenland gewohnt!

 

[casius]

Nein ich glaube wir haben uns immer noch nicht verstanden.

Der Baustein ist sehr viel fortschrittlicher als du glaubst. Es vollständig objektorientiert, noch objektorientierter geht es nicht mehr.

Aber jetzt noch mal vom Anfang an.
Von einer großen CPU kann ich nur träumen, für gewöhnlich bekommen ich eine 313, 314, 315 oder auch mal ein C7 Gerät. Das heißt jetzt leider nicht das die Maschinen die damit gesteuert werden einfach sind, im Gegenteil meist sind die Kisten recht kompliziert. Um was macht man da? Platz sparen, also alle Schrittketten zu fuß, für Speicherplatzfressende Tools habe ich leider keine Verwendung. So damit ist die Katze aus dem Sack, der Baustein stellt eine Schrittkette dar, und diese müssen nun mal immer an die Maschine angepasst werden.

Die Betriebsart und noch einige andere Daten werden dem Baustein von extern vorgegeben. Alle Sensoren und Aktoren werden erst mit dem Bausteinaufruf übergeben. Das hat den extremen Vorteil, dass die Schrittkette bereits geschrieben werden kann, während die Hardware und damit die ZL noch lange nicht fertig sind. Auch auf das beliebte Monteurspiel: „Wir habe die E/A in den andren Klemmenkasten verschoben weil das leichter war“ kann man sehr leicht reagieren. Querzugriffe unter den Bausteinen gibt es nicht, die Sachen werden sauber getrennt. Absolute Adressierung gibt es nur in einem Baustein, dort wo die Aufrufe gestartet werden. Im FB (Schrittkette) gibt es keinerlei absolute Adressierung, Adressen, Timer, Ausgänge oder sonst was. Wen das nicht objektorientiert ist, weiß ich auch nicht mehr wie das noch objektorientierter gehen soll. (Da bin ich aber wirklich gespannt.)

Jetzt weißt du auch warum ich im Baustein zwischen Handbetrieb und Automatikbetrieb unterscheide. Außerdem weißt du warum es so wichtig ist, das ich meine Platzhalter „Suchen und Ersetzen“ lassen muss, was man nicht mit umverdrahten verwechseln sollte!

Was die Zykluszeit angeht, ich glaube das war deine Frage, da liege ich bei einem Einfachen Programm bei etwa 4-6ms. Wenn ich eine 315 voll schreibe habe ich eine Zykluszeit von etwa 8-12ms, so genau weiß ich das nicht, Probleme mit der Reaktionszeit hatte ich noch nie. Ich denke damit bin ich deutlich schneller als mit einer konventionellen Schrittkette, die mit Graph7 erstellt wurde, auf jeden Fall brauche ich deutlich weniger Platz
Falls du wirklich gemeint hast wie lange so ein Zylinder fährt, das hängt vom Zylinder, dem Druck und der Masse ab, darauf habe ich keinen Einfluss.

Tja, das Leben ist hart, jetzt weißt du wenigstens wie man bei armen Leuten programmieren muss.

 

[Ulrich Klakow]

Platzprobleme

Moin Casius,

schön das du Schrittketten machst, ein großen Schritt in die richtige Richtung um schnelle und kurze Programme zu bekommen.
Ich mache sowas mittels Zustandsmachinen die ich in AWL Programmiere, das sieht etwa so aus:

      L     #Anstellzustand
      SET   
      SPL   sdef                        //State|Frei-| Bemerkungen
//                                      //     |gabe | 
//                                      //________________________________________________________________________________________________________________
      SPA   sdef                        // s0: |nein | Init
      SPA   s1                          // s1: | ja  | Einlauf erkennen (min. 50% der SOLL-Anzahl müssen Belegt sein)
      SPA   s2                          // s2: | ja  | Einlauf: Signalerzeugung durch gefilterte LT-Signale (bis 400mm nach Blecheinlauf ab 50% belegt)
      SPA   s3                          // s3: | ja  | Vorbereitung auf Normalbetrieb warten bis >=80% der LT's belegt sind. Anstellvorgang wie in S5
      SPA   s4                          // s4: | ja  | Normalbetrieb: LT-Anstellsignale über (Maske ODER LT-FiltInputSignale) erzeugen
      SPA   s5                          // s5: | ja  | Abstellphase:  Signalerzeugung durch gefilterte LT-Signale
      SPA   s6                          // s6: |nein  | Es sind weniger als 20% vom SOLL der Blechsensoren belegt, es werden alle PK's abgesteuert
sdef: L     1
      T     #Anstellzustand
      BEA

und dann (Code für Zustand S1

is1:  L     1
      T     #Anstellzustand

s1:   S     #Anstellfreigabe            // PK' dürfen angestellt werden/sein

//---------------- Anzahl der Belegten LT's bestimmen -------------------------------
      L     #PG0_3_Fillt_LT
      CALL  "get_Nr_of_set_Bits" , "iFB55"
      T     #R0b

      L     #PG4_7_Fillt_LT
      CALL  "get_Nr_of_set_Bits" , "iFB55"
      L     #R0b
      +I    
//-------------------------fin----------------------------------------------------------

//--------- Wenn hier mehr als 3-LT's der PK's belegt, so wird die Rückwährtfahrt gesperrt wenn nicht alle PK's unten sind -----
      L     2
      >I    
      U     #Alle_PKs_unten             // Wenn nicht alle PK's unten sind wird sperrflag gesetzt
      =     #NoBackMove
      TAK                               // wir benötigen die Anzahl der LT's nochmals in Accu-1

//------------------sind genug belegt?------------------------------------------
      L     #Anzahl_genutzter_PKs
      SRW   1                           // 50%
      <I    
      BEB                               // nicht genug ...

und dann (Code für Zustand S2

is2:L     2
      T     #Anstellzustand

//.................. Innerhalb der ersten 400mm werden belegte LT's in die Anstellmaske übernommen ......
      S     #Anstellfreigabe            // PK' dürfen angestellt werde/sein

s2:   U     #Alle_PKs_unten             // Wenn nicht alle PK's unten sind wird sperrflag gesetzt
      =     #NoBackMove

//------------------ >400mm nach Blecheinlauf (PWA) oder 1900mm (PWB)-----------------------------------------------
      L     400
      L     #BlechSize
      >=D                               // 
      BEB                               // noch keine 0,4m nach Ref-Point
      ...  // Weiter mit Zuand s3

Das ist extrem schnell und sehr leicht zu pflegen. Die Sprungliste ist gleichzeitig ein Teil der Anlagendokumentation.

Das mit der Zeit hat folgenen Hintergrund: Wenn z.B. Zylinder neu ist, braucht er sagen wir mal 550ms zum hochfahren und 370ms zum runterfahren. Wenn man sauber Programmiert muß man den Zylinder ständig überwachen und beim verfahren kontrollieren ob er in sagen wir mal in spätesden 750ms hochgefahren ist und in 500ms runtergefahren ist. Um diese Überwachungszeiten bei der IBN festzulegen benötige ich eine Information wie lange die Verfahrzeiten den sind?! Habe ich sie ermittelt dann trage ich sie mit eine Zeitreserve ein. Wenn der Zylinder jetzt z.B. wegen Verschleis immer langsammer wird kann ich rechtzeitig
eine Wartung ansetzen bevor das Teil nichtmehr zu gebrauchen ist.
Hierzu benötige ich aber eine Information wie lange mein Zylinder beim verfahren benötigt hat, oder zumindestens wieviel Restzeit von der von mir vorgegebenen Zylinderlaufzeit den noch übrig ist?
Ohne diese Info stehe ich immer in Gefahr das ich die Überwachungszeiten zu kurz oder viel zu lang vorgegeben habe. Das führt in einem Fall dazu das ich nach kurzen Anlagenlaufzeit schon wieder zur Anlage muß weil ein Zylinder z.B 10% Langsammer geworden ist und meine Anlage immer häufiger stehen bleibt, oder das der Zylinder schon komplett gestorben ist als seine Überwachungszeit zugeschlagen hat.

Abropo arme Leute, was macht Ihr den?

 

[Zottel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die SPL-Anweisung ist meiner Meinung nach eine echte Verbesserung gegenüber STEP 5. Dort benutzten die meisten Programme, die ich gesehen habe, einzelne Merker, um die einzelnen Schritte zu kennzeichnen. Am Ende des Schritts wird einer gelöscht und ein anderer gesetzt. Da habe ich es mehr als einmal erlebt, dass bei einer unvorhergesehenen Unterbrechung oder Störung des Ablaufs dann zwei gleichzeitig oder gar keiner mehr gesetzt ist und eine Maschine sich deshalb gar nicht mehr in Gang setzen lässt oder nur nach Not-Aus oder Hauptschalter aus, so dass die SPS stromlos wird.
Ein Zähler für den Schritt zwingt zur Eindeutigkeit.

 

[sps-concept]

SPL

Hallo Zottel,

die Funktionalität der SPL-Anweisung gabs schon in der S5. Und wenn man bei einer herkömmlichen Schrittkette auf einmal mehrere Merker gesetzt hat ist sie ganz einfach unsauber programmiert. Tja und was machste bei Simultanverzweigungen? Da gehts mit dem Schrittzähler nich ohne weiteres. Und @Ulrich: Hilfe is zwar schön und gut, aber Bewertungen dass jemand irgendwas nich kapiert hat find ich arogant. Von der Sorte gibts schon genug

Mfg
André Räppel

 

[Ulrich Klakow]

Nicht kapiert

@sps-concept Das dass arogant klinkt kann ich nachvollziehen,
wenn ich damit jemanden verletze tut mir das leid.

Allerdings ist das was ich geschrieben habe nicht abwertend gemeint.
Es gibt sehr sehr viele Sachen die ich selber nicht kapiere, das ist doch nicht meisten nicht schlim.
Schlimm wird es nur, wenn ich die Sachen kapieren müßte, weil z.B. die Firma sie benötigt und ich will mir nicht die Mühe machen sie zu verstehen.
Wenn ich zu dumm bin etwas zu verstehen (selbst bei guter Erklärung)
dann habe ich allerdings ein echtes Problem (ist mir im Studium mit
dem Faltungsintegral so gegangen).

Ein SPL Anweisung gibt es bei der S5 100% nicht, es gibt nur eine Bearbeiteanweisung die Eingeschrängt zu ähnlichem fähig ist.

 

[sps-concept]

Zuviel Werbung?
-> Hier kostenlos registrieren

Alles klar Ulrich. Ausserdem programmiert jeder nach seinem Wissen und Können. Entscheidend ist das Ergebnis. Und ein wichtiger Aspekt für die Instandhalter ist Übersichtlichkeit!! Und noch ein Wort zu Schrittketten.... In manchen Firmen sind Schrittketten unerwünscht. Beispielsweise ist in den Rohbauanlagen von VW sowas nicht zu finden. Schrittketten wären da auch fehl am Platz da es viele parallele Abläufe gibt die sich dann irgendwann mal treffen. Wenn sowas mit einer Schrittkette programmiert wird und die Abläufe nacheinander kommen kostets Taktzeit. Entscheidend ist also immer der Anwendungsfall.

MfG
André Räppel

 

[Ulrich Klakow]

keine Schrittketten, Zustandmachinen

Hey,

ich Programmiere ja auch keine Schrittketten sondern Zustandsmachinen.
Der unterschied ist der, das bei einer Schrittkette immer von einem Schritt in der nächsten gegangen wird. Bei Zustandmachinen kann aus jedem Zustand abhängig von einer Bedingung oder mehreren Bedingungen zu jedem BELIEBIGEN Zustand gewechselt werden. Es wird auch immer nur der Zustand bearbeitet in dem sich der Anlagenteil gerade befindet. Beim übergang zu einem anderen Zustand wird der Initalisiert und kann dann wenn erforderlich sofort bearbeitet werden.
Wenn verschiedene Anlagenteile zusammenarbeiten sollen, können diese
durch eine Baumartige Struktur von abhängien Zustandmachinen sehr gut
zusammenarbeiten. Wenn du das einmal wirklich kapiert hast, wirst du es fast immer als Lösung einsetzen. Weiterhin kann man dann schon vor der Programmierung ein übersichtliches Konzept erstellen das einen bei der Erstellung schon auf ungeklärte Anlagenzustandübergänge aufmerksam macht.

 

[Zottel]

Ein ganz einfaches Beispiel aus einer Steuerung einer Verpackungsmachine:
Wenn gewisse Vorbedingungen erfüllt sind, wird eine Ware hineingefördert und die Auslaufklappe gechlossen. Diese beiden Vorgänge können parallel erfolgen und verschieden lange dauern. Wenn beide beendet sind, erfolgt das Einschrumpfen der Ware in PE-Folie.

Zustand 44: Vorbedingungen erfüllt.
Mögliche Folgezustände:
Zustand 45: Auslaufklappe zu, Ware noch nicht drin
Zustand 46: Auslaufklappe noch offen, Ware drin
Gemeinsamer Folgezustand:
Zustand 47: Auslaufklappe zu, Ware drin
Es gibt immer genau eine Übergangsbedingung.
44->Endschalter Klappe->45
44->Endschalter Warenposition->46
45->Endschalter Warenposition->47
46->Endschalter Klappe->47
Das kann man dann schön als Ablaufdiagramm darstellen und sieht sofort wo's hängt.
Man sähe z.B. auch, dass bei schweren Waren (langsamer gefördert) die Kette über 44,45,47 und bei leichten über 44,46,47 läuft.

 

[casius]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Ulrich,
also vom Prinzip her habe ich die Sache genauso gelöst. Ein paar Dinge mache ich anders, ich bin der Meinung, dass ich so flexibler bin. Ich lasse nun mal gerne große Lücken zwischen den einzelnen Schritten. (Aus gutem Grund, manchmal glaube ich, dass die Maschinenbauer nur deshalb den Ablauf komplett geändert haben wollen um mich zu ärgern.) Ich lasse immer zehn Schritte Platz, als Reserve. Damit scheidet der SPL Befehl leider aus, sonst würden zuwenig Schritte übrig bleiben, aber mein Sprungverteiler funktioniert eigentlich genau so, ist halt nur etwas mehr Tipperei. Das ganze sieht in etwa so aus:


//Sprungverteiler
L StepNR
L 10
==I
SPB S10

TAK
L20
==I
SPB S20

SPA Ende

//Step10
S10: Ll0
T StepNR

SET
=AUTO_HEBEN

U S_HEBEN
UN PAUSE
S PAUSE
SPB S20

SPA Ende

//Step20
S20: L20
T StepNR

CLR
=AUTO_HEBEN

UN S_HEBEN
UN PAUSE
S PAUSE
SPB S10
SPA Ende

Weiter Unten erfolgt dann dien Zuweisung. Das sieht etwa so aus:

U(
U AUTO_HEBEN
U AUTOMATIK_AN
O
U HAND_HEBEN
U HAND_AN
)
U STEUERUN_AN
=VENTIL_HEBEN


Mit Sicherheit etwas mehr Tipperei als bei dir, dafür aber sehr schön übersichtlich und etwas flexibler.


Das Thema schein ja wirklich sehr beliebt zu sein, dabei wollte ich eigentlich nur wissen ob jemand, genauso wie ich die „Suchen und Ersetzen“ Funktion in der Deklaration vermisst.

 

[Ulrich Klakow]

Bruchrechnung

Moin Casius,

der Sprungverteiler ist doch nur der Verteiler!
Die eigendlichen Zustände kommen jeder in ein eigenes Netzwerk.
Das hat den Vorteil das ich jeden Zustand sauber im Netzwerkkopf
dokumentieren kann und im Onlinestatus im Sprungverteiler sofort sehe
welcher Zustand gerade bearbeitet wird.
Die SPL Anweisung hat noch eine andere schöne Eigenschaft.
Hat die Zustandsvariable mal eine nicht vorhandene Nummer, kann ich im Defaultteil schön darauf reagieren.
Meist mache ich es auch so, dass meine normalen Anlagenzustände
erst ab Nummer_1 beginnen, dass hat den Vorteil, das ich bei der
Zustandvisuallisierung (z.B. WinCC) für die Zustandnummer_0
eine rot unterlegten Zustandstext ausgebe der mir sofort zeigt das
meine schöne Zustandsmachine offensichtlich noch nie durchlaufen wurde.
Die SPL Anweisung ist auch meist erheblich schneller als deine Methode.
Nach eine paar Tips:
Schreibt man vor der SPL Anweisung ein

    SET

dann kann man folgendes machen:

S10: L    10
T  StepNR
S  Auto_Heben

man sparrt einen haufen SET/CLR befehle ein und
das Programm wird kürzer. Du braucht das VKE übriges auch nicht zu setzen, weil es beim Zustandsvergleich und anschliessendem SPB
sowieso immer gesetzt wird.
Wenn du deine Methode weiterverwenden willst, gibt es noch einen Trick
wie du Anweisungen einsparen kannst:

L StepNR
L 10
==I
SPBN nS10  // nicht Zustand 10

//____________Bearbeitung S10_______________
   ...

   ...
//____________Ende_S10_____________________
+  10   // Accu1 ist jetzt 20, Zustandsnummer bleibt in Accu2
==I
SPBN nS20

usw.

Ein neuladen der Zustandsnummer wird nicht mehr nötig.