# Strukturiertes Programmieren durch Programmbausteine



## Beck (25 Mai 2014)

Hallo Profis,

macht es Sinn, seinen SPS-Code nach  Anwendungsfällen zu sortieren, sofern unterschiedliche Anwendungsfälle  auf dieselben Outputs zugreifen?
Beispiel:
Es gibt es eine manuelle Steuerung, bei der Output A durch Taster A und Output B durch Taster B gesteuert wird.
Daneben gibt es aber noch eine Notfallsteuerung, die Output A und Output B setzen soll, wenn ein Notfall eintritt.
Darüber hinaus gibt es noch einen zeitgesteuerten Automatismus, der Output A steuert.

Am liebsten würde ich drei Programmblöcke bilden "Handsteuerung", "Notfall" und "Automation", die alle drei vom Hauptprogramm aufgerufen werden.
Da ich in einem Zyklus Output A und Output B jeweils eindeutig setzen sollte (also nicht zweimal: erst aus, dann sofort wieder ein), darf es nur ein FUP-Netzwerk geben, dass in Output A endet. Oder?

Damit ist eine Strukturierung nach Anwendungsfällen eigentlich nicht möglich. Es bleibt nur, nach Outputs zu sortieren und ggf. ähnliche Outputs in einem Programmbaustein zusammenzufassen.

Oder wird es in der Praxis so gehandhabt, dass man zwar nach Anwendungsfällen gruppiert, in jedem Programmbaustein aber nur eine Hilfsvariable setzt oder löscht und dann im Hauptprogramm die Prioritäten der einzelnen Anwendungsfälle zu einer Antwort "mischt"? Also, z.B. Output A von "Automation" kann durch Output A von "Handsteuerung" überschrieben werden, welcher wiederum durch Output A von "Notfall" überschrieben werden kann.
Oder wird das dann auch nur unnötig komplex?


Wie jeder an dieser Stelle schnell erkennen kann, habe ich keinerlei Praxiserfahrung, bin aber begierig darauf, von Profis zu lernen.

Vielen Dank,

Beck


----------



## Ralle (25 Mai 2014)

Ich bevorzuge eher die letztere Möglichkeit.

hier mal in AWL

U Auto
U Mx.1
O
U Hand
U Mx.2
= Ay.1


----------



## Lipperlandstern (25 Mai 2014)

Wenn das eine Abstimmung ist : letzte Möglichkeit


Ich habe grade eine Anlage von S5 auf S7 umgerüstet. Im alten Programm wurden getrennte Bausteine für Hand- und Automatikbetrieb programmiert und je nach Betriebsart aufgerufen. Kann man so machen aber wenn man z.B. den A0.0 in der Querverweisliste 2x zugewiesen wird ist es schon etwas verwirrend


----------



## SoftMachine (25 Mai 2014)

.
Ausgänge sollten tunlichst nur an einer Stelle
gesetzt/rückgesetzt werden, damit die QVL
übersichtlich bleibt.

Ich gehe mal von STEP 7 aus, dort könntest
du es so machen, indem du einen Zweig für
HAND, einen für AUTO und den dritten für den
NOTFALL veroderst.

Die Rücksetzbedingungen baust du ähnlich auf,
für den OUTPUT_B erzeugst du ein weiteres
Netzwerk.


Output_A mit Selbsthaltung




Outpot_A mit RS-Glied


----------



## Norton (25 Mai 2014)

Ich tendiere auch zu der 2.ten Varainate

aber in der Praxis findest Du alle nur denkbaren Möglichkeiten.
angefangen
 von "alles im OB1"
 über Versuche "wir programmieren Objektorientiert in S7" 
oder ich programmiere so das keiner durchblickt
bis hin zu "Top so hätte ich es auch gemacht".

für mich ist ein Programm "Strukturiert" wenn ein anderer ohne grosse Erklärungen sich darin zurechtfindet

Beste Grüsse aus 
OWL
 Norton


----------



## vierlagig (26 Mai 2014)

SoftMachine schrieb:


> .
> Ausgänge sollten tunlichst nur an einer Stelle
> gesetzt/rückgesetzt werden



Ausgänge sollten tunlichst an *keiner *Stelle gesetzt werden


----------



## Beck (26 Mai 2014)

Hallo SoftMachine,

ich nutze zwar CodeSys und ziehe FUP einem KOP vor. Aber ich habe verstanden, was Du meinst.
Letztlich waren "Hand", "Auto" und "Notfall" ja auch nur Beispiele.
In  der Gebäudeautomation könnten es noch mehr werden. So fallen mir  folgende Anwendungsbereiche als zu bündelnde Logiken allein mit Fokus  auf die Lichtsteuerung ein: "Taster/Lichtszenen", "Visu", "Notfall",  "Urlaub/Anwesenheitssimulation", "Alarmanlage".
Im Lichtszenenmodul  taucht Lampe 1 ggf. in vier verschiedenen Szenen auf. Sofern das Gebäude  im "Urlaubsmodus" ist, wird diese Lampe per Zufallsprinzip abends ein-  und ausgeschaltet. Im Alarmfall soll sie blinken. Im Notfall  dauerleuchten. Und per Visu und Taster soll all das überschrieben werden  können.
Wenn ich alle vier Lichtszenen, die zeitliche Steuerung und  das Blinken mit in den gleichen Block code, ist es definitiv nicht mehr  leicht lesbar.

Wahrscheinlich ist Folgendes sinnvoll:
1. einen FB Lichtszenen zu haben, der eine Variable xLampe1_szenen setzt oder löscht
2. einen FB Urlaub zu haben, der eine Variable xLampe1_urlaub setzt oder löscht
3. einen FB Alarm zu haben, der eine Variable xLampe1_alarm bei Bedarf blinken lässt
....etc...
Im  Hauptprogramm werden die einzelnen xLampe1_* dann - so wie von Dir  dargestellt - miteinander verknüpft. Dort muss man dann die Prioritäten  festlegen, welches Szenario Vorrang hat. Das ist dann also eine  UND/ODER-Verknüpfung, die ggf. noch Flankenübergänge der einzelnen  xLampe1_* mitberücksichtigt.

Die Hilfsvariablen blähen das Ganze  natürlich sehr auf. Letztlich hat mal aber keine andere Wahl, wenn man  den Gesamtzusammenhang lesbar halten will.

Ich bin jetzt hier von  der Verwendung von FBs und nicht Funktionen ausgegangen. Funktionen  wären vielleicht noch schicker, da man sich globale Hilfsvariablen  spart. Aber wenn ein FB "Lichtszenen" Lampe 1, 2, 3 und 4 steuert, ich  im Hauptprogramm aber Lampe 1, 2, 3 und 4 völlig getrennt beschreiben  möchte, muss ich das doch so tun, oder? 

Stimmen mir die Profis zu? Oder würdet Ihr das anders realisieren? 


Beck


----------



## SoftMachine (26 Mai 2014)

.


Beck schrieb:


> ...
> Stimmen mir die Profis zu? Oder würdet Ihr das anders realisieren?
> 
> Beck






vierlagig schrieb:


> Ausgänge sollten tunlichst an *keiner *Stelle gesetzt werden



@Beck
Ich würde jetzt erstmal klären, was der nach längerer
Abstinenz seit kurzem ins Forum zurückgekehrte 
User <vierlagig> dir mit seinem obigen Beitrag für eine 
Hilfestellung geben will.
Ich kann mir vorstellen, da kommen sicher fundierte
Hinweise heraus.


----------



## vierlagig (26 Mai 2014)

SoftMachine schrieb:


> Ich würde jetzt erstmal klären, was der nach längerer
> Abstinenz seit kurzem ins Forum zurückgekehrte
> User <vierlagig> dir mit seinem obigen Beitrag für eine
> Hilfestellung geben will.
> ...



Nette Ironie, danke! 

Ich bleib dabei, ein Ausgang soll nur einmal beschrieben werden und S/R sind nun mal zwei Schreibvorgänge.

hier noch ein Lesetipp: http://www.sps-forum.de/programmierstrategien/21714-schrittkettenprogrammierung-und-ausgaenge-sicher-schalten.html


----------



## bike (26 Mai 2014)

vierlagig schrieb:


> Nette Ironie, danke!
> 
> Ich bleib dabei, ein Ausgang soll nur einmal beschrieben werden und S/R sind nun mal zwei Schreibvorgänge.
> 
> hier noch ein Lesetipp: http://www.sps-forum.de/programmierstrategien/21714-schrittkettenprogrammierung-und-ausgaenge-sicher-schalten.html



Ausgänge sollen, wie beschrieben, nur einmal zugewiesen werden.
Dann kann man an einer Stelle prüfen, warum ein Ausgang 1 ist oder nicht.
Für die einzelnen Funktionen Hand Automatik Urlaub Tage / Nacht sollten Merker verwendet werden.
Es ist einfacher direkt einen Ausgang an verschieden Stellen zu zuweisen, doch es ist weder schön noch sinnvoll, noch fair für die Nachfolger, die mit dem Programm leben müssen.

Da hat der user <vierlagig> absolut recht.


bike


----------



## PN/DP (26 Mai 2014)

Meine Erfahrung: Schon die Ausdrucksweise "einen Ausgang setzen" zeugt davon, daß die Funktionslogik falsch gedacht wird.

NICHT:
Wenn Taster_A gedrückt wird, dann Lampe_1 setzen und Lampe_2 setzen. Achja, und ganz dahinten auch noch Lampe_27 einschalten und das Rollo_12 schließen. Und vorsichtshalber Lampe_3 ausschalten, aber nur wenn sie an ist... *grauenhaft*
Bei allen nicht genannten Situationen bleiben die Ausgänge unschlüssig in dem Zustand wie sie gerade sind.

SONDERN:
Lampe_1 ist Ein wenn Taster_A gedrückt ist oder Notsituation oder Nachtschaltung aktiv ist oder ...
Bei allen nicht genannten Situationen ist die Lampe automatisch Aus.


Eine Elektroschaltung und ebenso eine Software"schaltung" in einer SPS verarbeitet normalerweise nicht Ereignisse sondern Zustände. Von daher kommt auch die zyklische Abarbeitung eines SPS-Programms.

Bei Programmen welche in der ereignisorientierten Denkweise programmiert sind, muß man bei jeder Programmänderung davon ausgehen, daß neue Fehler drin sind und das Programm müsste KOMPLETT neu getestet werden (was aber objektiv gar nicht möglich ist!). Weil dieses Kreuz-und-quer-setzen auch Programmteile außer Kraft setzen kann, welche man gar nicht angefasst hat. Das letzte Schreiben im Zyklus gewinnt, egal wie sinnvoll die vorherigen Zuweisungen programmiert waren. Bei solchen Programmen ist gegenüber Zustandsverknüpfungen auch die Wahrscheinlichkeit höher, daß noch unentdeckte Fehler im Programm enthalten sind.

Harald


----------



## vierlagig (26 Mai 2014)

Lieber Harald,

handelt es sich nicht um eine Mischung aus Zuständen und Ereignissen? 

Anlage nimmt durch Ereignis *a* den Zustand *A* an, durch Ereignis *b* den Zustand *B*. 

Die Ereignisse a,b,[...] sind die eingelesenen Zustände, Kombinationen daraus und entstehen aus Vergleichen zu bekannten Werten.
Am Ende geht es darum, die Zustandsbeschreibung auf die Aktoren zu schreiben - also die Wichtung entsprechend Deiner Ausführungen zu setzen.


----------



## PN/DP (26 Mai 2014)

Ereignisse können in einer vom Programmierer unerwarteten Reihenfolge auftreten (und dadurch wirkungslos bleiben), die dadurch erreichten (Teil-)Zustände bleiben aber meistens bestehen. Wenn der Programmierer die Zustände verknüpft, dann ist es egal in welcher Reihenfolge die sich eingestellt haben.

Natürlich kann man auch Ereignisse verknüpfen (z.B. Flanken), ich wollte aber betonen, daß das in einer einzigen = Zuweisung gemacht werden soll, aber nicht in zig S/R quer übers Programm verstreut.

Harald


----------



## vierlagig (26 Mai 2014)

PN/DP schrieb:


> Ereignisse können in einer vom Programmierer unerwarteten Reihenfolge auftreten (und dadurch wirkungslos bleiben), die dadurch erreichten (Teil-)Zustände bleiben aber meistens bestehen. Wenn der Programmierer die Zustände verknüpft, dann ist es egal in welcher Reihenfolge die sich eingestellt haben.



Ziel sollte es sein, Ereignisse so auszuwerten, dass sie sicher einem Zustand zugeordnet werden können. Und ja, eine erwartete Reihenfolge hat man idR nur in Schrittketten. Nichts desto trotz möchte ich beachtet wissen, dass ereignissgetriggerte Zustandswechsel mindestens auch erkannt werden sollten um den genauen Anlagenzustand verfügbar zu haben.

Aber das hängt alles zu sehr von der Zustand- und Ereignissbegriffdefinition ab, die wir ja nicht geklärt haben. 



PN/DP schrieb:


> Natürlich kann man auch Ereignisse verknüpfen (z.B. Flanken), ich wollte aber betonen, daß das in einer einzigen = Zuweisung gemacht werden soll, aber nicht in zig S/R quer übers Programm verstreut.
> 
> Harald



mein Reden, eine Zuweisung und nicht zwei (S/R) oder mehr.


----------



## leo (26 Mai 2014)

Für mich liest sich das so als ob PN und VL die gleiche Ansicht haben und trotzdem über (welche?) Differenzen diskutieren.


----------



## SoftMachine (26 Mai 2014)

.
Das Thema ist wohl etwas seitwärts gelaufen.
Ich habe da mal den Beitrag #4 auf die Schnelle
ergänzt, um dem TE ein anderes Beispiel zu liefern.


----------



## leo (26 Mai 2014)

Früher habe ich Ausgänge direkt in der Schrittkette Ge/Rückgesetzt, spart ja so schön Tipparbeit. Nach einigen unschönen Scenen auf IBN hab ich mir dann auch angewöhnt, Ausgänge nur mit "=" anzusprechen.

wobei R/S Glieder meiner Meinung nach auch noch akzeptabel sind.


----------



## vierlagig (26 Mai 2014)

SoftMachine schrieb:


> .
> Das Thema ist wohl etwas seitwärts gelaufen.
> Ich habe da mal den Beitrag #4 auf die Schnelle
> ergänzt, um dem TE ein anderes Beispiel zu liefern.



das nächste Beispiel mit Konfliktpotential.

wie dem auch sei, was war die eigentliche Frage?



Beck schrieb:


> Ich bin jetzt hier von  der Verwendung von FBs und nicht Funktionen ausgegangen. Funktionen  wären vielleicht noch schicker, da man sich globale Hilfsvariablen  spart. Aber wenn ein FB "Lichtszenen" Lampe 1, 2, 3 und 4 steuert, ich  im Hauptprogramm aber Lampe 1, 2, 3 und 4 völlig getrennt beschreiben  möchte, muss ich das doch so tun, oder?
> 
> Stimmen mir die Profis zu? Oder würdet Ihr das anders realisieren?



es gibt der Realisierungsmöglichkeiten viele, wie man auch an der Diskussion merkt.
Je nach Umfang des Aktors kann ein FB alle Betriebsarten abarbeiten. Man übergibt die aktuelle Betriebsart und die den Zustand des Aktors beschreibenden Signale und bekommt den Zustandsorientierten Wert entsprechend der vorhergehenden Ereignisse geliefert. Das muss nicht nur das Bit Ein/Aus sein, kann auch noch zusätzlich Langsam Ein oder Schnellgang Ein oder der anzufahrende Positionswert, die Abzufahrende Kurve etc. sein.


----------



## SoftMachine (26 Mai 2014)

.


vierlagig schrieb:


> das nächste Beispiel mit Konfliktpotential.
> 
> wie dem auch sei, was war die eigentliche Frage?




Lieber Steffen,

die "eigentliche Frage" des Themas steht in Beitrag #1, 
mit Beitrag #4 habe ich darauf geantwortet.

Du gehst auf den Beitrag #7 vom TE ein, produzierst
hier Beiträge und betitelst dann in deinem Beitrag #18 
meinen Beitrag #4 nachträglich als "Konfliktpotential" ?

Sicher wirst du nochmal lesen und auch darlegen können,
wie du mich mit deiner ausschweifenden Diskussion und 
dem Beitrag #7 in Verbindung bringst ? 

Gruss


----------



## vierlagig (27 Mai 2014)

SoftMachine schrieb:


> .
> Lieber Steffen,
> 
> die "eigentliche Frage" des Themas steht in Beitrag #1,
> ...



Die Konfliktpotentialfeststellung bezieht sich tatsächlich auf Deinen Beitrag 4. Dann folgt eine sprachliche Trennung und ich gehe auf Beitrag siebn ein ohne auch nur einen Gedanken an Dich zu verschwenden.

Nicht böse sein, dass ich Dich in meiner Antwort auf 7 nicht bedacht habe!


----------



## Ralle (27 Mai 2014)

@4L+SoftMaschine

Darf ich euch bitten, das mal per PN zu klären und hier nicht weiter Beiträge mit recht wenig direktem Sachbezug zu produzieren!
Das nützt dem TE nun wirklich herzlich wenig.


----------



## Bapho (27 Mai 2014)

Wenn ich das in SCL mache, habe ich ja keine Wahl als  A1.0:=true bzw. A1.0:=false zu machen. 
Wichtig ist einzig das nur an einer Stelle zu machen, da alle Bedingungen mit IF /Elsif verknüpfen und am Ende mit einer Else den Ausgang auf false bringen wenn keine Bedinung zutrifft. 
So wie ich das lese meine wir ja alle dasselbe, nur drückt es jeder bissle anders aus


----------



## zotos (27 Mai 2014)

bapho schrieb:


> wenn ich das in scl mache, habe ich ja keine wahl als a1.0:=true bzw. A1.0:=false zu machen.
> ...




```
a1.0 := e1.0 and e1.1;
```


----------



## Bapho (27 Mai 2014)

klar geht das auch, aber wie liest sich das dann wenn es komplexer wird


```
a1.0:=((e1.0 and e1.1) or e7.0) and (e2.0 and (not e2.1 or 3.1)) and ((e3.0 and not e3.3) or A2.0));
```

dann schaut da der arme Instanthalter rein und kratzt sich nachdenklich am Hinterkopf 

edit: Strichpunkt vergessen


----------



## vierlagig (27 Mai 2014)

Bapho schrieb:


> klar geht das auch, aber wie liest sich das dann wenn es komplexer wird
> 
> 
> ```
> ...



wie sähe das denn Deiner Meinung nach "richtig" aus?


----------



## vierlagig (27 Mai 2014)

IMHO richtig: Die Verwendung einer geeigneten Darstellungsform.


----------



## MasterOhh (27 Mai 2014)

Ahhh, ich liebe solche Verknüpfungsorgien. Am liebsten noch in einem FUP Netzwerk das man dann auf A0 ausdrucken muss nur um mal einen Überblick zu bekommen.
Wenn ihr z.B. ein Ventil habt, das in 5 verschiedenen Betriebsmodi der Anlage angesteuert wird. In jedem Modus gibt es 10- 15 Bedingungen die ein Öffnen oder Schließen des Ventils bewirken. Prügelt ihr das wirklich alles in eine einzige Verknüpfung damit ihr den Ausgang für das Ventil nur ein einziges mal im Programm steuert?


----------



## vierlagig (27 Mai 2014)

MasterOhh schrieb:


> Ahhh, ich liebe solche Verknüpfungsorgien. Am liebsten noch in einem FUP Netzwerk das man dann auf A0 ausdrucken muss nur um mal einen Überblick zu bekommen.
> Wenn ihr z.B. ein Ventil habt, das in 5 verschiedenen Betriebsmodi der Anlage angesteuert wird. In jedem Modus gibt es 10- 15 Bedingungen die ein Öffnen oder Schließen des Ventils bewirken. Prügelt ihr das wirklich alles in eine einzige Verknüpfung damit ihr den Ausgang für das Ventil nur ein einziges mal im Programm steuert?



ich prügel das in 5 Verknüpfungen, die Oder-Verknüpft dann = Ventil ansteuern - ist das falsch?


----------



## Ralle (27 Mai 2014)

MasterOhh schrieb:


> Ahhh, ich liebe solche Verknüpfungsorgien. Am liebsten noch in einem FUP Netzwerk das man dann auf A0 ausdrucken muss nur um mal einen Überblick zu bekommen.
> Wenn ihr z.B. ein Ventil habt, das in 5 verschiedenen Betriebsmodi der Anlage angesteuert wird. In jedem Modus gibt es 10- 15 Bedingungen die ein Öffnen oder Schließen des Ventils bewirken. Prügelt ihr das wirklich alles in eine einzige Verknüpfung damit ihr den Ausgang für das Ventil nur ein einziges mal im Programm steuert?



Natürlich nicht, für so etwas kann man ja Zwischenvariablen nutzen.


----------



## StructuredTrash (27 Mai 2014)

Ich bin nicht grundsätzlich gegen mehrfache Ausgangszuweisungen. Wichtig ist für mich nicht, nur eine Zuweisung zu programmieren, sondern nur eine pro Programmzyklus auszuführen. Das setzt natürlich bedingte FB- oder Aktionsaufrufe voraus, einen Gewinn an Übersichtlichkeit wird man nur bei der Programmierung in ST erzielen. Bei Verwendung anderer Sprachen halte ich auch die Verwendung von Hilfsvariablen für die bessere Variante.


----------



## volker (27 Mai 2014)

selbstverständlich in fup 
und wie wärs denn wenn du die 5 modi auf temp-vars oder merker oder sonstiges legts und anschliessend veroderst?


----------



## volker (27 Mai 2014)

StructuredTrash schrieb:


> Wichtig ist für mich nicht, nur eine Zuweisung zu programmieren, sondern nur eine pro Programmzyklus auszuführen.


OHHH ha. Das wird ja immer besser.
Und irgendwann wird der Ausgang erst nach einer Sekunde geschaltet weil zu viele Zyklen dazwischenliegen.


----------



## MasterOhh (27 Mai 2014)

Damit, dass man eine Ausgangsvariable nur einmal im Zyklus ansteuern sollte, gehe ich 100% mit. Das diese Ansteuerung aber nur ein einziges mal im Programmcode enthalten sein soll halte ich für übertrieben.
Ich programmiere nur in ST und definiere für die verschiedenen Anlagenteile Zustände. In jedem Zustand kann ich dann Ausgänge beschreiben. Das immer nur ein Zustand je Anlagenteil aktiv ist, dafür sorgt eine CASE -Verzweigung. 
Das es in AWL, FUP oder KOP besser ist die Ausgänge wirklich nur an einer Stelle zu steuern leuchtet mir ein. Schrittketten sehen da ja auch anders aus und eine Zustandsorientierte Programmierung lässt sich da vieleicht nich so einfach realisieren.
In AS oder Graph werden Ausgänge idR ja auch direkt im Schritt gesetzt und das kann, je nach Umfang, mehrfach in einer Kette passieren.....



volker schrieb:


> OHHH ha. Das wird ja immer besser.
> Und irgendwann wird der Ausgang erst nach einer Sekunde geschaltet weil zu viele Zyklen dazwischenliegen.



Ich habe keinen blassen Schimmer was du meinst?


----------



## StructuredTrash (27 Mai 2014)

MasterOhh schrieb:


> Damit, dass man eine Ausgangsvariable nur einmal im Zyklus ansteuern sollte, gehe ich 100% mit. Das diese Ansteuerung aber nur ein einziges mal im Programmcode enthalten sein soll halte ich für übertrieben.
> Ich programmiere nur in ST und definiere für die verschiedenen Anlagenteile Zustände. In jedem Zustand kann ich dann Ausgänge beschreiben. Das immer nur ein Zustand je Anlagenteil aktiv ist, dafür sorgt eine CASE -Verzweigung.



So hatte ich es gemeint. Vielleicht sollte ich weniger schreibfaul sein, um Missverständnissen vorzubeugen.


----------



## PN/DP (27 Mai 2014)

StructuredTrash schrieb:


> Ich bin nicht grundsätzlich gegen mehrfache Ausgangszuweisungen. Wichtig ist für mich nicht, nur eine Zuweisung zu programmieren, sondern nur eine pro Programmzyklus auszuführen. Das setzt natürlich bedingte FB- oder Aktionsaufrufe voraus, einen Gewinn an Übersichtlichkeit wird man nur bei der Programmierung in ST erzielen.


Da will ich widersprechen - für mich ist ST das "Übel" schlechthin, weil es dem 10-Minuten-Programmierer erlaubt, völlig planlos die unübersichtlichsten Programme überhaupt zu produzieren.

Was für umständliche, unübersichtliche und unvollständige IF..THEN..ELSIF..-Konstrukte in der Praxis tatsächlich verwendet werden sieht man ja immer wieder im IEC61131-Forumsbereich.

Wenn zu den mehrfachen Ausgangszuweisungen auch noch bedingte Programmausführung dazukommt ... na, viel Spaß bei der Programmanalyse!

Wenn die Ausgangszuweisung an nur einer Stelle zusammengfaßt ist, dann kann ich diese Stelle online beobachten. Ist sie auf mehrere Zuweisungen an mehreren Orten verteilt, dann habe ich kaum eine Chance, denn Grund für unerwartete Zustandsänderungen zu finden, zumal diese S/R-Bedingungen meistens auch noch nur 1 Zyklus lang erfüllt sind.

Harald


----------



## KingHelmer (27 Mai 2014)

> Da will ich widersprechen - für mich ist ST das "Übel" schlechthin, weil  es dem 10-Minuten-Programmierer erlaubt, völlig planlos die  unübersichtlichsten Programme überhaupt zu produzieren.



Hallo Harald,

da wiederspreche ich hingegen auch wieder.
Wenn ich so machen AWL oder FUP/KOP verseuchten Programmbaustein ansehe, dann kommt mir auch manches Mal der Brechreiz.

Im allgemeinen finde ich ST wunderbar dazu geeignet Programme 1A zu strukturieren. Natürlich gibt es immer schwarze Schafe aber wie heißt es denn so schön:

"Eine Programmiersprache kann nichts für die unübersichtliche Gestaltung durch den Programmierer,
eine Verbalsprache kann schließlich auch nichts für ihre Schimpfworte" - Kinghelmer, 2014



Grüße, 
Flo


----------



## Bapho (27 Mai 2014)

vierlagig schrieb:


> wie sähe das denn Deiner Meinung nach "richtig" aus?



Was heißt richtig, viele Wege führen nach Rom. 
Da es hier aber um strukturiertes Programmieren geht, ging es mir eher um die Übersicht und Lesbarkeit des Codes.  Die Religionsfrage nach der besten Programmiersprache bzw. dem besten Motoröl spielt doch da keine Rolle. Ich kann in jeder Sprache Spaghetti mit Kauderwelsch erzeugen, was dann auch funktioniert, nur sieht dann keiner mehr durch.

Mir gefällt halt eine klar strukturierte und kommentierte IF/ElSIF/ELSE Sache besser als das alles in zig Klammern hintereinander zu schreiben. Klar muß ich dabei aufpassen, aber lieber paar Zeilen mehr wenn es der Verständlichkeit dient.

Ist meine persönliche Meinung und jeder soll das doch machen wie er will.


----------



## StructuredTrash (27 Mai 2014)

PN/DP schrieb:


> Da will ich widersprechen - für mich ist ST das "Übel" schlechthin, weil es dem 10-Minuten-Programmierer erlaubt, völlig planlos die unübersichtlichsten Programme überhaupt zu produzieren.


Planlose Programmierung ist wohl keine Frage der Programmiersprache und wird von ST auch nicht in besonderer Weise unterstützt. Das einzige, was man ST in dieser Richtung vorwerfen kann, ist, dass die Sprache dem Standard-IT-Programmierer suggeriert, er könne mit den ihm bekannten Vorgehensweisen auch mal eben eine SPS programmieren. Das ist dann aber ein Problem des Programmierers und nicht der Sprache.



PN/DP schrieb:


> Was für umständliche, unübersichtliche und unvollständige IF..THEN..ELSIF..-Konstrukte in der Praxis tatsächlich verwendet werden sieht man ja immer wieder im IEC61131-Forumsbereich


Leider gibt es dort genug Beispiele, die Deine Meinung stützen. Aber wie schon gesagt, sind dafür die Programmierer verantwortlich.



PN/DP schrieb:


> Wenn zu den mehrfachen Ausgangszuweisungen auch noch bedingte Programmausführung dazukommt ... na, viel Spaß bei der Programmanalyse!


Den habe ich. Standardbeispiel für so eine Programmierung ist ja die hier schon genannte Fallunterscheidung zwischen mehreren Betriebsarten. Wenn ich bei der Fehlersuche weiss, in welcher Betriebsart die Maschine sich befindet (und davon gehe ich mal aus), dann interessiert mich doch auch nur der Teil des Programms, der in ebendieser Betriebsart die Steuerung übernimmt.


----------



## vierlagig (27 Mai 2014)

ich hatte vor einigen Jahren in diesem Forum festgestellt, dass jede Darstellungsform, sei es KOP, AWL, ST/SCL, ihre Daseinsberechtigung hat - außer FUP 

hier noch ein schöner Lesetipp: http://www.sps-forum.de/simatic/16873-awl-kop-anzeigen-lassen.html

gab schon so manche, schöne Grundsatzdiskussion zu diesen Themen ... gute, alte Zeit.


----------



## vierlagig (27 Mai 2014)

Bapho schrieb:


> Was heißt richtig, viele Wege führen nach Rom.



Du hast ein konkretes Beispiel zur Verfügung gestellt. Die Frage ist, wie stellst Du das "in Deiner Welt" dar, wenn Dir die von Dir dargebrachte Darstellung nicht genehm ist?!


----------



## bike (27 Mai 2014)

Wenn ich so lese, dann stellt sich mir die Frage, warum gibt es flags?
Es ist doch Mist, wenn in verschiedenen Bausteinen ein Ausgang oder flag zugewiesen bzw gesetzt / rückgesetzt werden.
Wo soll ein Instandhalter anfangen Fehler zu suchen?

Und dabei ist es doch völlig egal, in welcher Programmiersprache das Programm erstellt wird.

Und es ist so, dass die Hochsprachenprogrammierer?, die sich als PLC Programmierer profilieren wollen, zuerst einmal die Technik verstehen sollen.

PLC ist eben eine andere Welt und das ist auch gut so.


bike

btw: Also ich kann auch Netzwerke in jeder Sprache schreiben und in in einer Länge, die in keinem Editor angeschaut werden können. Doch muss das sein?


----------



## Bapho (27 Mai 2014)

Als Beispiel das Thema Betriebzustände. Es gibt AUS/HAND/AUTO/EINRICHTEN. Der Ausgang ist eine Lampe und sie soll ausser bei AUS bei allen anderen Zuständen an sein. Da mach ich die Verknüpfungen in einem FC und setze mir dafür Bits in einem DB oder halt Merker. Wenn ich dann den Ausgang für die Lampe ansteuer sieht das so aus.

```
if DB1.DBX0.0       // Auto FC1 Zeile 20
   or DB1.DBX0.1  // Hand FC1 Zeile 40
   OR DB1.DBX0.2 // Einrichten FC1 Zeile 60
   then
   A1.0:=true; // Lampe EIN 
else 
   A1.0:=false; // Lampe AUS
end_if;
```

Die andere Schreibweise ist ja dasselbe, nur verkürzt. Nur wenn hier einer reinschaut ist es auf Anhieb klar was fehlt bzw. wo was herkommt um weiter zu suchen. Ausserdem kann man besser kommentieren.

Nochmal, es geht mir nicht um irgendwelche Grundsatzdiskussionen, aber ich hab mir früher als Instandhalter oft sowas gewünscht um gerade im Stress früh 3.00 Uhr auf die Schnelle nachschauen zu können. Gerade weil sich das SCL in Step7 beim Beobachten mitunter so zickig hat.


----------



## norustnotrust (27 Mai 2014)

Um mich auch mal hier in der Grundsatzdiskussion einzubringen:
Ich finde dass obiges OR in FUP oder KOP viel übersichtlicher und besser gelöst ist (imho ist es sogar in AWL klarer). Nicht umsonst hat sich für binäre Logiken FUP und KOP durchgesetzt. Bei komplexeren Dingen sieht es natürlich wieder anders aus.


----------



## StructuredTrash (27 Mai 2014)

bike schrieb:


> Wenn ich so lese, dann stellt sich mir die Frage, warum gibt es flags?
> Es ist doch Mist, wenn in verschiedenen Bausteinen ein Ausgang oder flag zugewiesen bzw gesetzt / rückgesetzt werden.
> Wo soll ein Instandhalter anfangen Fehler zu suchen?


Klar, meistens beginnt die Fehlersuche beim Ausgang. Wenn der nur an einer Stelle des Programms zugewiesen wird, hat man natürlich einen eindeutigen Einsprungspunkt für die Suche. Aber wie geht es dann weiter? Im Hauptprogramm wird ja etwas stehen wie

```
HWAusgang:=(Hand AND HandAusgang) OR (Auto AND AutoAusgang);
```
Angenommen, Auto=1, AutoAusgang=0. Dann muss ich ja doch in dem Programmteil oder FB weitersuchen, in dem AutoAusgang programmiert ist.

Wenn ich die Ausgangszuweisungen in den FB's für die einzelnen Betriebsarten habe, fange ich mit der Suche auf der anderen Seite an. Erstmal schauen, welche Betriebsart aktiv ist, und dann in den entsprechenden FB springen. Dort habe ich dann alles, was ich brauche, vor mir, inklusive der Ausgangszuweisung. 
Ich erhebe für so eine Struktur keineswegs allein selig machenden Anspruch, aber für die Art der Maschinen, die wir bauen, hat sie sich als recht praktikabel erwiesen.


----------



## vierlagig (27 Mai 2014)

@Bapho:
es geht konkret um dieses besipiel!



Bapho schrieb:


> klar geht das auch, aber wie liest sich das dann wenn es komplexer wird
> 
> 
> ```
> ...


----------



## bike (27 Mai 2014)

Es gibt meist mehr als einen Weg zum Ziel.
Es ist doch aber meist aufwendiger, wenn man in den verschieden Funktionen schauen muss, in welcher der Ausgang aktiviert wird.
Ich finde es persönlich leichter, wenn im Querverweis immer nur eine Position angezeigt wird, an der die Zuweisung erfolgt.
Wenn komplette Funktionen portabel programmiert werden, dann kann man ohne viel zu tun diese verschiedene Projekte einfügen.

Jeder nach seiner Art, denn die einzig glücklich machende Lösung gibt es wohl nicht.


bike


----------



## Bapho (27 Mai 2014)

vierlagig schrieb:


> @Bapho:
> es geht konkret um dieses besipiel!



So wie ich es oben geschrieben habe, die 3 Zustände in 3 separaten if Zweigen erzeugen und ein Bit setzen, dann nur die Bits und für den Ausgang verknüpfen.
Oder reitest du so drauf rum weil ich ganz hinten eine Klammer zuviel hab?


----------



## vierlagig (27 Mai 2014)

Bapho schrieb:


> So wie ich es oben geschrieben habe, die 3 Zustände in 3 separaten if Zweigen erzeugen und ein Bit setzen, dann nur die Bits und für den Ausgang verknüpfen.
> Oder reitest du so drauf rum weil ich ganz hinten eine Klammer zuviel hab?



ich reite nicht darauf rum, schon gar nicht wegen einer Klammer.

Du hast dies als Beispiel für Unübersichtlichkeit ins Feld geführt und musst Dich nun leider an der Übersichtlichkeit messen lassen.
Obiger Extrakt mit den Datenbausteinzugriffen spiegelt nicht das Eingangs erwähnte Beispiel wider.

Wie dem auch sei - ST/SCL ist nach wie vor nach meinem Dafürhalten nicht für ausschweifendere Bitoperationen geeignet, wohl aber für das Arbeiten mit Zustandsentsprechungen im INT-Format so dass man auf so komfortable Befehle wie CASE zurückgreifen kann.


----------



## PN/DP (27 Mai 2014)

Bapho schrieb:


> So wie ich es oben geschrieben habe, die 3 Zustände in 3 separaten if Zweigen erzeugen und ein Bit setzen, dann nur die Bits und für den Ausgang verknüpfen.
> Oder reitest du so drauf rum weil ich ganz hinten eine Klammer zuviel hab?


Ist das so schwer, das einfach mal mit Deinem IF..THEN-Konstrukt zu formulieren? Oder würdest Du dann feststellen, daß es keineswegs übersichtlicher aussieht? (und viel mehr Platz auf dem Bildschirm oder Ausdruck benötigt?)

Nochmal zu den Instandhaltern - es geht nicht darum, ob die womöglich zu dumm für AWL oder SCL oder mehrfach-Zuweisungen sind, sondern die haben einfach keine Zeit zu verschwenden wenn die Anlage steht. Da ist keine Zeit erst 7 falsche Programmstellen zu beobachten... oder die ganze Bildschirmseite Text zu lesen statt das fehlende Bit in KOP direkt auf den ersten Blick zu sehen. Oder noch zusätzlich eine Variablentabelle öffnen zu müssen, um zu sehen, ob die im beobachteten Programmteil eindeutig zu sehende Zuweisung auch tatsächlich am Ende des Zyklus am Ausgang ankommt.

Harald


----------



## KingHelmer (27 Mai 2014)

> Wie dem auch sei - ST/SCL ist nach wie vor nach meinem Dafürhalten nicht  für ausschweifendere Bitoperationen geeignet, wohl aber für das  Arbeiten mit Zustandsentsprechungen im INT-Format so dass man auf so  komfortable Befehle wie CASE zurückgreifen kann.



Ich stimme bedingt zu.
Bei Operationen, welche in einem Baustein hunderte Bitzuweisungen auf Eingänge von Datenbausteinen haben, würde FUP zwar besser aussehen, aber die Arbeit bei einer Änderung vervielfachen. Bei sehr kleinen Bit-Logiken hat ST auch wieder den Vorteil der (finde ich) Übersichtlichkeit.

Bei mittleren, sich nie ändernden Situationen mag vieleicht eine visuelle Sprache richtig gewählt sein.

Habe ich große Mengen an Variablennamen zu ändern (als Beispiel), dann kann ich dies ganz locker in word oder einem .txt bearbeiten und einfach in das ST Programm einfügen.
Mit FUP oder anderen "visuellen" Sprachen geht das leider nicht.

Ich handhabe es so, dass ich alles, was den Anwender angeht (vieleicht die ersten beiden Bausteinebenen) mit FUP zuweise. Alles andere ist ausschließlich ST und kann schön von Projekt zu projekt einfach kopiert werden anstatt umständlich exportiert/importiert oder als .lib angelegt.

Piece and Out für heute!
Grüße und schönen Feierabend für alle die, wie ich, gleich nach Hause gehen!
Flo


----------



## vierlagig (27 Mai 2014)

KingHelmer schrieb:


> Habe ich große Mengen an Variablennamen zu ändern (als Beispiel), dann kann ich dies ganz locker in word oder einem .txt bearbeiten und einfach in das ST Programm einfügen.
> Mit FUP oder anderen "visuellen" Sprachen geht das leider nicht.



geht das nicht? die Darstellung in eine Textsprache umstellen oder besser noch in der "visuellen" Sprache [sic!] die Funktion Suchen/Ersetzen verwenden?
um an die Welt anzuknüpfen in der ich die meiste Zeit unterwegs bin: Bei Step7 kann ich Operanden- oder Symbolvorrang für das gesamte Programm wählen und mit der Funktion "Umverdrahten" oder mit der Änderung des Symbols programmweite Änderungen durchführen - klingt komisch...


----------



## bike (27 Mai 2014)

KingHelmer schrieb:


> Habe ich große Mengen an Variablennamen zu ändern (als Beispiel), dann kann ich dies ganz locker in word oder einem .txt bearbeiten und einfach in das ST Programm einfügen.
> Mit FUP oder anderen "visuellen" Sprachen geht das leider nicht.
> 
> Ich handhabe es so, dass ich alles, was den Anwender angeht (vieleicht die ersten beiden Bausteinebenen) mit FUP zuweise. Alles andere ist ausschließlich ST und kann schön von Projekt zu projekt einfach kopiert werden anstatt umständlich exportiert/importiert oder als .lib angelegt.



Also dafür gibt es doch Quellen in Step 7 z.B. und das funktioniert perfekt.
Ich schreibe viel in irgendeinem Editor und kompiliere es.

Und in ST bzw SCL Netzwerke mit umfangreichen Bitverknüpfungen zu debuggen, das ist es Erlebnis. Doch muss nicht wirklich sein.


bike


----------



## hucki (27 Mai 2014)

Bapho schrieb:


> ```
> if DB1.DBX0.0       // Auto FC1 Zeile 20
> or DB1.DBX0.1  // Hand FC1 Zeile 40
> OR DB1.DBX0.2 // Einrichten FC1 Zeile 60
> ...


Genau sowas ist für mich das Paradebeispiel für 'ne IF-THEN-Orgie unter SCL/ST (ungeachtet der Absolutadressierung) 

Ich würde da immer eine Zuweisung bevorzugen:

```
A1.0 := DB1.DBX0.0       // Auto FC1 Zeile 20
    OR DB1.DBX0.1  // Hand FC1 Zeile 40
    OR DB1.DBX0.2; // Einrichten FC1 Zeile 60
```


----------



## Bapho (27 Mai 2014)

Ich habe das Gefühl ich werde missverstanden.

Ich lass das ganze Code Zeugs mal weg und möchte nochmal meinen Standpunkt zum Thema verdeutlichen. "strukturiertes Programmieren"
Wie ich oben schon schrub geht es mir dabei ums Prinzip. 
Ich betreue komplexe Fertigungszellen, so etwa in der Größenordnung von 6 Maschinen mit je eigener SPS, Roboter, Messautomaten, Laser, vor- uind nachgelagerte Anlagen + übergeordnetes Leitsystem. Diese Kisten sind fast alle, ausser Leitsystem, mit DP/DP Kopplern mit der Zellensps verbunden. Warenträger läuft ein, ID wird beim Leitsystem aungefragt, Material ID + Rezepte + Kommisionierdaten werden zurückgeschickt und die Zelle reagiert entsprechend darauf.
Wenn das Material fertig bearbeitet ist, wird der Warenträger wieder abgemeldet und weitergeschickt, inkl. diverser Meldungen wie NIO, Zustand der Anlagen usw.
Das der ganze Spass recht anfällig ist, liegt in der Natur der Sache, hat das Leitsystem richtig geantwortet, ist überhaupt ein Telegramm raus, ist auf einem Band ein Ini kaputt, hat der Robi übergriffen, ist eine Maschine in Störung usw. usf.
Man kann sowas bis zu einem bestimmten Punkt im Programm abfangen bzw. konkrete Meldungen ausgeben, aber es wird immer zu unvorhergesehenen Zuständen kommen und dann muß der Instandhalter zügig den Fehler finden und dafür ist unbedingt eine klar strukturierte und verständliche Programmierung notwendig, gepflegte und kommentierte Varablentabellen und regelmäßige Unterweisungen.
Meine Erfahrungen haben folgendes gezeigt, meterlange UND Verknüpfungen in FUP sind für die meisten Leute unverständlich, SCL/ST wird meist in Servickursen sehr stiefmütterlich behandelt, super laufende Anlagen die komplett in AWL sind, inkl. massenweise indirekter Adressierung + Sprunglisten sind für Instandhalter fast nicht zur durchschauen.
Deswegen von mir das Beispiel mit der verschachtelten Zuweisung. Jemand der nicht jeden Tag damit zu tun hat, beißt sich dann an sowas die Zähne aus.
Auch wenn ihr mich dafür verteufelt, ich mache endlose if/then Orgien, ordentlich und sinnvoll in beschriftete FC/FB verpackt mit Kommentaren zu den Querverweisen. Das mag sich auf den ersten Blick schlecht lesen lassen, ok, aber bei der Fehlersuche kann man sich ratzbatz zum Problem durchhangeln, die Leute wollen das ja nicht alles von oben bis unten lesen, nur über die QVL hinspringen und sehen wo es klemmt.  

Außerdem hab ich euch alle lieb und jetzt sage ich gfanz laut JEHOVAAA!


----------



## vierlagig (27 Mai 2014)

Dass das mit FUP nicht geht war ja klar, gib den Leuten KOP! Da kann man mit dem Finger das Signal verfolgen ...


----------



## Bapho (27 Mai 2014)

vierlagig schrieb:


> Dass das mit FUP nicht geht war ja klar, gib den Leuten KOP! Da kann man mit dem Finger das Signal verfolgen ...



da ist der Meter dann horizontal statt vertikal


----------



## vierlagig (27 Mai 2014)

Bapho schrieb:


> da ist der Meter dann horizontal statt vertikal



Ja UND der überbezahlte Instandhalter wird es verstehen - versprochen!


----------



## bike (27 Mai 2014)

Bapho schrieb:


> Ich habe das Gefühl ich werde missverstanden.
> 
> Ich lass das ganze Code Zeugs mal weg und möchte nochmal meinen Standpunkt zum Thema verdeutlichen. "strukturiertes Programmieren"
> Wie ich oben schon schrub geht es mir dabei ums Prinzip.
> ...




Also langsam solltest du dir Gedanken mache, ob du vielleicht dein Problem völlig falsch beschrieben hast.

Es gibt in vielen Firmen den Ansatz zu standardisieren. 
Dass in in einem bestimmten Baustein diese, in einem anderen ein andere Funktion ausprogrammiert wird und so schnell bei Störungen zum Ziel gekommen wird. (HMI - lite / transline 2000)
Aber so wie du schreibst, kann dir vermutlich niemand folgen.

Und noch ein Hinweis:
Wenn die Instandhaltung ein PG brauchen, dann ist das ein Tiefschlag für die Programmierer (sagt ein anderer User hier, aber der hat absolut recht)


bike


----------



## vierlagig (27 Mai 2014)

bike schrieb:


> Und noch ein Hinweis:
> Wenn die Instandhaltung ein PG brauchen, dann ist das ein Tiefschlag für die Programmierer (sagt ein anderer User hier, aber der hat absolut recht)



Das ist doch Blödsinn!


----------



## zotos (27 Mai 2014)

[SV]
Hilfe! bike zitiert mich, gibt mir recht und ich ihm.
[/SV]


----------



## Bapho (27 Mai 2014)

mir nach, ich folge euch *hust*


----------



## vierlagig (27 Mai 2014)

vierlagig schrieb:


> Das ist doch Blödsinn!



Im Sinne des Zitaturhebers ist es kein Blödsinn - danke für die Erläuterungen!


----------



## spirit (30 Mai 2014)

vierlagig schrieb:


> Ausgänge sollten tunlichst an *keiner *Stelle gesetzt werden



... wobei es aber doch z.B. bei der Ansteuerung von Servo's gar nicht anders geht, oder?  

Lt. Beschreibung von Festo wird ein Servo-Antrieb wie folgt in Betrieb gesetzt:


```
U #MotorStart              // HMI-Button
S #StartTask               // Start Fahrauftrag Festo-Antrieb
 
U #AckStart                // Start ausgeführt
R #StartTask
```


----------



## rostiger Nagel (30 Mai 2014)

spirit schrieb:


> ... wobei es aber doch z.B. bei der Ansteuerung von Servo's gar nicht anders geht, oder?
> 
> Lt. Beschreibung von Festo wird ein Servo-Antrieb wie folgt in Betrieb gesetzt:
> 
> ...



würde schon gehen, an den beispiel kannst du sehen wer die Achsen laufen lässt
und die Achse würde im Notfall auch stillgesetzt, wenn auch der Start, warum 
auch immer, noch ansteht.


```
U #MotorStart              // HMI-Button
S #HM_Achse_Start

U #AckStart                // Start ausgeführt
R #HM_Achse_Start

O #HM_Achse_Start
O #HM_Achse_Tippen
U #Freigabe_Not_Halt
= #StartTask               // Start Fahrauftrag Festo-Antrieb
```


----------



## spirit (30 Mai 2014)

rostiger Nagel schrieb:


> würde schon gehen, an den beispiel kannst du sehen wer die Achsen laufen lässt
> und die Achse würde im Notfall auch stillgesetzt, wenn auch der Start, warum
> auch immer, noch ansteht.
> 
> ...



Danke rN,

also das eigentliche Starten des Motors würde ja nach wie vor über #StartTask erfolgen; richtig?

Aber ist dieses #HM_Achse_Start lediglich ein x-beliebiger Merker und wofür steht HM?


Lieben Dank!


----------



## vierlagig (30 Mai 2014)

spirit schrieb:


> das eigentliche Starten des Motors würde ja nach wie vor über #StartTask erfolgen; richtig?


ja



spirit schrieb:


> Aber ist dieses #HM_Achse_Start lediglich ein x-beliebiger Merker und wofür steht HM?



HilfsMerker


...und weil Festo es so in der Beschreibung hat wird Festo aus der Normteilliste gestrichen - Strafe muss sein


----------



## zotos (30 Mai 2014)

rostiger Nagel schrieb:


> würde schon gehen, an den beispiel kannst du sehen wer die Achsen laufen lässt
> und die Achse würde im Notfall auch stillgesetzt, wenn auch der Start, warum
> auch immer, noch ansteht.
> 
> ...


Das Beispiel passt bei Festo Achsen nicht!
Wenn man die Achse anhalten will sollte man den Eingang "Halt" auf False setzen, wenn man den Fahrauftrag abbrechen will den Eingang "Stop" auf False setzen. Der Start Task muss nur solange ansein bis er mit AckStart quittiert wurde.


----------



## spirit (30 Mai 2014)

vierlagig schrieb:


> ...und weil Festo es so in der Beschreibung hat wird Festo aus der Normteilliste gestrichen - Strafe muss sein



Danke vierlagig -

Ähm, ist diese Art der Ansteuerung eher ungewöhnlich?


----------



## spirit (30 Mai 2014)

zotos schrieb:


> Das Beispiel passt bei Festo Achsen nicht!
> Wenn man die Achse anhalten will sollte man den Eingang "Halt" auf False setzen, wenn man den Fahrauftrag abbrechen will den Eingang "Stop" auf False setzen. Der Start Task muss nur solange ansein bis er mit AckStart quittiert wurde.



... aber somit muss doch StartTask einmal gesetzt und dann wieder rückgesetzt werden?


----------



## vierlagig (30 Mai 2014)

zotos schrieb:


> Das Beispiel passt bei Festo Achsen nicht!
> Wenn man die Achse anhalten will sollte man den Eingang "Halt" auf False setzen, wenn man den Fahrauftrag abbrechen will den Eingang "Stop" auf False setzen. Der Start Task muss nur solange ansein bis er mit AckStart quittiert wurde.



Erinnert an das Datenhandling mit der alten Kuka-Schnittstelle.

also:


```
*

U    MotorStart     //mit allen Sicherheitszeuch bereits gebildet
UN   Start_ACK
=    Start_Task
```


----------



## bike (30 Mai 2014)

spirit schrieb:


> Ähm, ist diese Art der Ansteuerung eher ungewöhnlich?



Jein, ist es nicht wirklich. 

Du musst dich von der Vorstellung verabschieden, dass Hersteller bessere Programmierer haben.
Die müssen Beispiele liefern, sonst kauft niemand mehr ein Teil.
Auch diese Beispiele sind nicht perfekt und werden auch ohne Gewährleistung geliefert, da nicht alles ausgetestet wird / werden kann.
Es gibt keine allgemeingültigen Regeln und Vorschriften. 

Daher such dir einen Weg, der passt und den deine Kollegen und die Instandhalter verstehen und gut bezeichnen.


bike


----------



## zotos (30 Mai 2014)

Ja dem ist so und das ist auch nichts schlimmes. Dieser Absolutheitsanspruch das niemals nicht irgendwas gesetzt werden darf ist quatsch und artet in einen Glaubenskrieg aus.

Ich setze den StartTask bei den Festo Achsen auch ohne dabei ein schlechtes Gewissen zu haben.

```
U     #Achse.StartAchse
      FP    #Achse.FL_Start
      S     #Achse.StartTask


      U     #Achse.AckStart
      O     #Achse.Fault
      ON    #Achse.Halt          //low aktiv
      ON    #Achse.Stop          //low aktiv
      R     #Achse.StartTask
```


Ob ich nun den StartTask setze oder sowei rn einen Hilfsmerker ist egal und hat nichts damit zu tun ob man nun Ausgänge setzten will oder nicht.


----------



## spirit (30 Mai 2014)

vierlagig schrieb:


> also:
> 
> 
> ```
> ...



Also würde hier MotorStart z.B. schon die Freigabe (U #Freigabe_Not_Halt) enthalten...


----------



## spirit (30 Mai 2014)

zotos schrieb:


> Ich setze den StartTask bei den Festo Achsen auch ohne dabei ein schlechtes Gewissen zu haben.
> 
> Code:
> 
> ...



Wobei dieses Setzen und Rücksetzen von StartTask bei mehreren Antrieben dann ja auch *entsprechend oft* passieren müsste, richtig?

UND ist die Flanke als Sicherheit, falls #Achse.StartAchse permanent TRUE wäre?


----------



## zotos (30 Mai 2014)

Jeder Antrieb hat ja seine eigene Schnittstelle. Klar muss jeder Antrieb eigens behandelt werden.


----------



## spirit (30 Mai 2014)

Ok, lieben Dank zotos!

... aja, und die Flanke aus reinem Sicherheitsbewusstsein?


----------



## zotos (30 Mai 2014)

Nicht ganz. Die Variable StartAchse wird über die Schrittkette solange auf True gehalten bis die Achse ein "InPos" (Isposition im Positionsfenster und MC (Motion Complete)) meldet.

Mit anderen Worten ich habe um den Festo CMMP_AS_CTRL Baustein noch etwas drumherum Programmiert damit es besser in mein System passt.


----------



## spirit (31 Mai 2014)

Aja, ok - danke zotos!


----------

