# wie gehe ich da ran?



## xinix (16 März 2011)

Moin moin,

fange ja gerade erst mit ST an und benötige mal ne einschätzung zu folgenden Szenario:

Ich frage einen Zustand ( START oder BETRIEB ) zweier Tanks, je nach den Füllständen meiner Teichanlage ab. Sind beide Tanks leer, dann soll sie START Sequenz eingeleitet werden. 

Da sich der Zustand zu Sequenz währen dieser ändert, würde ich nach meiner Logik ein eine Variable setzen, und erst am ende der Sequenz wieder zurücksetzten. Wäre das eine Lösung oder gibt es was besseres?

Nach der Abfrage und wahl der Sequenz, muss ich ja entweder an eine bestimmte Stelle im Programm springen, oder ein anderes Programm aufrufen. Was macht mehr sinn, und wie geht das? Gibt es sowas wie goto? oder wie eine Sprung in FUP?

Wäre um ein Beispiel sehr dankbar!

Gruß


----------



## gloeru (16 März 2011)

Für Sequenzen setzt ich oft die Case-Struktur ein:
http://infosys.beckhoff.com/content/1031/tcplccontrol/html/tcplcctrl_statement_case.htm?id=12175

Da kannst du Schritte machen, und selber "Weiterschaltbedingungen" definieren. Sprünge habe ich noch nie in ST gebraucht!

Leider habe ich gerade kein passenden Beispiel parat, aber unten mal ein kleiner Auswahlbaustein in einer Case, es geht um eine Lüftungsklappe...


```
CASE iNr OF
    
        0: (* NOP *)
        ;

        10: (* Klappe öffnen *)
            bAusgang_Motor := TRUE;
            IF (bSensorIsOpen) THEN
            bAusgang_Motor := FALSE;
            bDoKlappe_Auf := FALSE;
            iNr := 0;
            END_IF

        20:    (* Klappe Schliessen *)
            bAusgang_Motor := TRUE;
            IF (bSensorIsClose) THEN
            bAusgang_Motor := FALSE;
            bDoKlappe_Zu := FALSE;
            iNr := 0;
            END_IF
    END_CASE
```


----------



## dante (16 März 2011)

Naja ohne Hardware kann man dir schlecht helfen. Wenn du 2 Fühler hast machste ne 2-punkt Regelung. Hast du Analoge Werte machst du halt ne If schleife mit real werten oder was auch immer. Aber so in die Glaskugel geschaut kann man dir nicht "richtig" helfen.


----------



## xinix (16 März 2011)

Hallo Dante, mir geht es eigenlich erst einmal um das grundsätzliche, nicht auf eine bestimmte Hardware bezogen, da ich es erst einmal verstehen möchte.

Also ich frage zunächst den Zustand ab, ob beide tanks leer sind. Wenn beide Tanks leer sind soll eine Starsequenz eingeleitet werden. Sind beide Tanks jeweils mit mehr als 25% gefüllt wird die Betriebssequenz eingeleitet.

Diese Start- und Betriebssequenz birgt aber auch wider eine Rehe von Messungen und Abfragen und Regelungen. Die Startsequenz ist auf die Betriebszeit von einer Strunde festgelegt. Nach dieser Stunde soll dann die Betriebssequenz eingeleitet werden die ähnlich der Startsequenz arbeite aber ein par kleine änderungen mit sich bringt.

Das auswerten der Fühler und das Steuern der Pumpen ist soweit kein problem.


----------



## cas (18 März 2011)

Hallo,

eigentlich hast du mit deiner Beschreibung bereits das Programm schon fast geschrieben.

Im Prinzip brauchst du nur noch Zeile für Zeile in Codeys übersetzen.

Beispiel:

Tank1_viertelvoll:=(Messwert1>33);
Tank2_viertelvoll:=(Messwert2>38); (*Falls der Tank andere Maße hat*)

If Tank1_Leer=True and Tank2_leer=true then Sequenz_Start:=true;end_if

If Tank1_viertelvoll=True and Tank2_viertelvoll then
Sequenz_Start:=False;
Sequenz_Regeln:=True;
end_if



Ist jetzt nur mal ein einfaches Beispiel.

MfG CAS


----------



## dante (18 März 2011)

Habs ihm schon komplett geschrieben 

Hier die exportierte Version: (mit seinen Angaben gemacht ohne Sicherheit das die Pumpen trocken laufen oder so)



```
(* @NESTEDCOMMENTS := 'Yes' *)
(* @PATH := '' *)
(* @SYMFILEFLAGS := '2048' *)
FUNCTION_BLOCK FB_Pumpensteuerung
VAR_INPUT
    nTank_1: INT;
    nTank_2: INT;
END_VAR
VAR_OUTPUT
    nPumpeTank_1: BOOL;
    nPumpeFilterung: BOOL;
    bPumpeTeichzulauf: BOOL;
    bUmspuelung: BOOL;
    bTeichfuellung: BOOL;
END_VAR
VAR
    bInit: BOOL;        (*Startvorgang*)
    TOF_Filterung: TOF;
    F_TRIG_Filterung: F_TRIG;
    bBetrieb: BOOL;
    R_TRIG_Betrieb: R_TRIG;
    TOF_betrieb: TOF;
    F_TRIG_Betrieb: F_TRIG;
END_VAR
(* @END_DECLARATION := '0' *)
(*
#############################
#                            #
#    Pumpensteuerung            #
#    Teichanlage V1.0            #
#                            #
#############################
*)

(*
###########################    Startvorgang
*)

IF nTank_1<100 AND nTank_2<100 AND F_TRIG_Filterung.Q=FALSE AND bBetrieb=FALSE THEN
    bInit=TRUE;
ELSIF F_TRIG_Filterung.Q=TRUE THEN
    binit=FALSE;
END_IF;

(*
###########################    Wasser umwaelzen | reinigen
*)

IF bInit=TRUE THEN            (*Startvorgang*)

    IF nTank_1<800 THEN
        nPumpeTank_1:=TRUE;
    ELSE
        nPumpeTank_1:=FALSE;
    END_IF;


    TOF_Filterung(IN:=nPumpeTank_1 , PT:=T#60m , Q=> , ET=> );    (*1 Stunde zur Filterung*)
    F_TRIG_Filterung(CLK:=TOF_Filterung.Q , Q=> );                (*Fallende Flanke vom Timer setzt initialschritt zurueck*)

    IF nTank_1>500 AND TOF_Filterung.Q THEN
        nPumpeFilterung:=TRUE;
    ELSE
        nPumpeFilterung:=FALSE;
    END_IF;

(*
###########################    Wasser umspuelen
*)

    IF nTank_2>nTank_1 AND TOF_Filterung.Q THEN
        bPumpeTeichzulauf:=TRUE;
        bUmspuelung:=TRUE;
    ELSE
        bPumpeTeichzulauf:=FALSE;
        bUmspuelung:=FALSE;
    END_IF;

END_IF;

(*
###########################    Betrieb
*)

IF binit=FALSE AND nTank_1<100 AND nTank_2<100 THEN
    bBetrieb:=TRUE;
ELSIF F_TRIG_Betrieb=TRUE THEN
    bBetrieb:=FALSE;
END_IF;

IF bBetrieb=TRUE THEN

    R_TRIG_Betrieb(CLK:=bBetrieb , Q=> );
    TOF_Betrieb(IN:=R_TRIG_Betrieb.Q OR F_TRIG_Betrieb.Q, PT:=t#180m , Q=> , ET=> );    (*3 Stunden Intervall*)
    F_TRIG_Betrieb(CLK:=TOF_Betrieb.Q , Q=> );

    IF F_TRIG_Betrieb.Q=TRUE THEN
        IF nTank_2>200 THEN
            bPumpeTeichzulauf:=TRUE;
            bTeichfuellung:=TRUE;
        ELSE
            bPumpeTeichzulauf:=FALSE;
            bTeichfuellung:=FALSE;
        END_IF;

        IF nTank_2>800 THEN
            nPumpeFilterung:=TRUE;
            nPumpeTank_1:=TRUE;
        ELSE
            nPumpeFilterung:=FALSE;
            nPumpeTank_1:=FALSE;
        END_IF;
    END_IF;

END_IF;
END_FUNCTION_BLOCK
```


----------



## Blockmove (19 März 2011)

also wenn man das so liest, könnte man glatt glauben, dass Codesys keinen KOP oder FUP kann 

Gruß
Dieter


----------



## bike (19 März 2011)

Blockmove schrieb:


> Laso wenn man das so liest, könnte man glatt glauben, dass Codesys keinen KOP oder FUP kann
> 
> Gruß
> Dieter



Kennen vielleicht schon, doch man kann auch versuchen jedes Werkzeug für jede Aufgabe zu nutzen. 
Es soll auch schon ein Hammer in der Uhrmacherwerkstatt gesichtet worden sein 


bike


----------



## Blockmove (19 März 2011)

bike schrieb:


> Es soll auch schon ein Hammer in der Uhrmacherwerkstatt gesichtet worden sein



Um bei deinem Vergleich zu bleiben:
Hier wurde der Schmiedehammer rausgeholt 

Fehlt nur noch die Modellierung auf Basis von Zustandsautomaten.

Gruß
Dieter


----------



## dante (19 März 2011)

du kannst die Aufgabe ja sehr gerne mal in FUB oder KOP machen und wir schauen was übersichtlichert wird .


----------



## StructuredTrash (19 März 2011)

```
IF Bedingung
THEN
   Ergebnis:=True;
ELSE
   Ergebnis:=False;
END_IF;

Ergebnis:=Bedingung;
```

Natürlich lassen sich solche Steuerungsfunktionen in kombinatorischer Logik einfacher darstellen, dazu braucht man noch nicht mal FUP oder KOP. Aber muss man das? Das Programm von Dante zeigt sehr gut, wie sich die Denkweise beim Programmieren mit ST langsam aber sicher zum "Wenn-Dann" entwickelt. Und sobald auch nur ein wenig speichernde Logik hinzukommt, ist das in meinen Augen auch besser verständlich. Wenn jemand seinen gesamten Programmierstil in diese Richtung entwickelt, sehe ich das deshalb nicht negativ.


----------



## xinix (20 März 2011)

Blockmove schrieb:


> Um bei deinem Vergleich zu bleiben:
> Hier wurde der Schmiedehammer rausgeholt
> 
> Fehlt nur noch die Modellierung auf Basis von Zustandsautomaten.
> ...



Also erst einmal vielen Dank für die unterstützenden Threads! Scheinbar wurde übersehen, dass ich am Anfang ausdrücklich nach der Hilfe in ST und nicht nach FUP oder KOP fragte. Dante hat sich überdurchschnittlich ins Zeug gelegt mir durch Sein Beispiel mal einen Einblick zu geben, wie soetwas aussehen kann. Dafür bin ich Ihn sehr dankbar. 

Sicherlicht ist es ähnlich dem Arztbesuch. Jeder Arzt stellt eine andere Diagnose. Mir hat's auf jeden fall Geholfen Dr. Dante!

Gruß


----------



## Blockmove (20 März 2011)

StructuredTrash schrieb:


> Natürlich lassen sich solche Steuerungsfunktionen in kombinatorischer Logik einfacher darstellen, dazu braucht man noch nicht mal FUP oder KOP. Aber muss man das?



Gegen

```
Ergebnis:=Bedingung;
```
habe ich gar nicht einzuwenden. Ist nichts anderes als KOP oder FUP.

Bei

```
IF Bedingung
THEN
   Ergebnis:=True;
ELSE
   Ergebnis:=False;
END_IF;
```
geht bei vielen in der Praxis oft der Überblick verloren und es entsteht schnell Spaghetti-Code. Ganz beliebt sind hier Betriebsartenwechsel, Manuelle Eingriffe, Not-Halt und ähnliches.
Viele Programmierer (besonders solche aus der PC-Ecke) vergessen hier, dass Anlagen und Benutzer manchmal ein "Eigenleben" haben.

Gruß
Dieter


----------



## PN/DP (20 März 2011)

StructuredTrash schrieb:


> Das Programm von Dante zeigt sehr gut, wie sich die Denkweise beim Programmieren mit ST langsam aber sicher zum "Wenn-Dann" entwickelt. Und sobald auch nur ein wenig speichernde Logik hinzukommt, ist das in meinen Augen auch besser verständlich. Wenn jemand seinen gesamten Programmierstil in diese Richtung entwickelt, sehe ich das deshalb nicht negativ.


Was ich besonders an dieser Wenn-Dann-Denke und Wenn-Dann-Programmierung (inklusive übermäßigem Gebrauch von Flanken) *hasse*, ist, daß dadurch fast zwangsläufig bedingte Ausgangszuweisungen an -zig Stellen im Programm gemacht werden. Wenn dann wie bei dante noch nicht einmal für ALLE möglichen Anlagenzustände eine Reaktion ausprogrammiert ist, dann gibt es Anlagenzustände ohne aktive Ausgangszuweisung. Die Ausgänge bleiben so, wie sie durch irgendeine Vorgeschichte "zufällig" stehen.

Wenn in solchen Programmen dann auch noch "ein wenig speichernde Logik" hinzukommt, dann wird das Verhälten des Programms in der Regel nicht verständlicher, sondern zeitweise unvorhersagbar.

Die typische Reaktion der Wenn-Dann-Programmierer bei zutagetreten der "unmöglichen" Anlagenzustände ist, noch eine spezielle Wenn-Dann-Reaktion hinterher-zu-programmieren und später noch eine und noch eine ... das Programm besteht dann irgendwann aus 80% Ausnahmereaktionen und nur noch 20% "gewollter Code". Ich sage in solchen Fällen immer: Es gibt 1000 Krankheiten, aber nur eine Gesundheit.

@dante
Kannst Du auf Anhieb genau sagen, was die Pumpen in Deinem Programm machen, wenn z.B. binit=FALSE und bBetrieb=FALSE oder im anderen Fall binit=TRUE und bBetrieb=TRUE sind? (Sag jetzt nicht, daß beide Fälle in Deinem Programm niemals vorkommen können).

Harald


----------



## bike (20 März 2011)

PN/DP schrieb:


> Was ich besonders an dieser Wenn-Dann-Denke und Wenn-Dann-Programmierung (inklusive übermäßigem Gebrauch von Flanken) *hasse*, ist, daß dadurch fast zwangsläufig bedingte Ausgangszuweisungen an -zig Stellen im Programm gemacht werden. Wenn dann wie bei dante noch nicht einmal für ALLE möglichen Anlagenzustände eine Reaktion ausprogrammiert ist, dann gibt es Anlagenzustände ohne aktive Ausgangszuweisung. Die Ausgänge bleiben so, wie sie durch irgendeine Vorgeschichte "zufällig" stehen.
> 
> Wenn in solchen Programmen dann auch noch "ein wenig speichernde Logik" hinzukommt, dann wird das Verhälten des Programms in der Regel nicht verständlicher, sondern zeitweise unvorhersagbar.
> 
> Die typische Reaktion der Wenn-Dann-Programmierer bei zutagetreten der "unmöglichen" Anlagenzustände ist, noch eine spezielle Wenn-Dann-Reaktion hinterher-zu-programmieren und später noch eine und noch eine ... das Programm besteht dann irgendwann aus 80% Ausnahmereaktionen und nur noch 20% "gewollter Code". Ich sage in solchen Fällen immer: Es gibt 1000 Krankheiten, aber nur eine Gesundheit.



Dazu kann nur eins kommen : *ACK*



PN/DP schrieb:


> @dante
> Kannst Du auf Anhieb genau sagen, was die Pumpen in Deinem Programm machen, wenn z.B. binit=FALSE und bBetrieb=FALSE oder im anderen Fall binit=TRUE und bBetrieb=TRUE sind? (Sag jetzt nicht, daß beide Fälle in Deinem Programm niemals vorkommen können).
> 
> Harald



Frag doch bitte nicht nach was  nicht ausprogrammiert ist. 

Der Schmiedehammer, wie jemand schon geschrieben hat, ist eben doch nicht immer das richtige Werkzeug.

Warum alles mit Gewalt in ein Korsett pressen?


bike


----------



## gloeru (20 März 2011)

Um mich auch noch in diese Diskussion mit ein zu bringen:

Ich verwende oft CASE für solche Sachen, dann ist das ganze Wenn-Dann etc. nur in der Auswahl der Einsprungstelle, die Anweisungen sind in der Struktur gut aufgehoben. Zudem kann ohne grosser Aufwand die Verriegelun realisiert werden.


----------



## bike (20 März 2011)

gloeru schrieb:


> Um mich auch noch in diese Diskussion mit ein zu bringen:
> 
> Ich verwende oft CASE für solche Sachen, dann ist das ganze Wenn-Dann etc. nur in der Auswahl der Einsprungstelle, die Anweisungen sind in der Struktur gut aufgehoben. Zudem kann ohne grosser Aufwand die Verriegelun realisiert werden.



Wenn du dann unkontrolliert aus der Schleife fällst, hast du ggF auch Ausgänge oder andere Variablen so, wie du diese nicht willst.

Egal wie. bei all den bedingten Abarbeitungen ist viel Aufwand zu tun, um nicht irgend etwas seltsames auf den Weg zu bringen.


bike


----------



## PN/DP (20 März 2011)

gloeru schrieb:


> Ich verwende oft CASE für solche Sachen


Wehe Du machst in den CASE-Zweigen Ausgangszuweisungen, dann ist es im Grunde der gleiche Mist wie diese Wenn-Dann- oder Setzen/Rücksetzen-Dinger.

Harald


----------



## StructuredTrash (20 März 2011)

PN/DP schrieb:
			
		

> Was ich besonders an dieser Wenn-Dann-Denke und Wenn-Dann-Programmierung (inklusive übermäßigem Gebrauch von Flanken) *hasse*, ist, daß dadurch fast zwangsläufig bedingte Ausgangszuweisungen an -zig Stellen im Programm gemacht werden.





			
				PN/DP schrieb:
			
		

> Die typische Reaktion der Wenn-Dann-Programmierer bei zutagetreten der  "unmöglichen" Anlagenzustände ist, noch eine spezielle  Wenn-Dann-Reaktion hinterher-zu-programmieren und später noch eine und  noch eine



Wenn schon die erste Version eines Programms so geschrieben ist oder später noch jede Menge Verriegelungen nachgetragen werden müssen, hat man ganz klar seine Hausaufgaben nicht gemacht. Das hat für mich aber nichts mit der grundsätzlichen Denk- und Vorgehensweise beim Programmieren zu tun.


----------



## bike (20 März 2011)

StructuredTrash schrieb:


> Wenn schon die erste Version eines Programms so geschrieben ist oder später noch jede Menge Verriegelungen nachgetragen werden müssen, hat man ganz klar seine Hausaufgaben nicht gemacht. Das hat für mich aber nichts mit der grundsätzlichen Denk- und Vorgehensweise beim Programmieren zu tun.



Wenn ich dich richtig verstanden habe, weißt du zu Beginn schon alle Eventualitäten, die sich bei der Programmierung und Inbetriebnahme ergeben?

Respekt!


bike


----------



## StructuredTrash (20 März 2011)

bike schrieb:
			
		

> Wenn ich dich richtig verstanden habe, weißt du zu Beginn schon alle  Eventualitäten, die sich bei der Programmierung und Inbetriebnahme  ergeben?



Nein, da hast Du mich falsch verstanden. Ich meine, dass es kein guter Stil ist, Zuweisungen auf den selben Ausgang wild auf das gesamte Programm zu verteilen, so wie es auch PN/DP wohl schon öfter hat sehen müssen. Und alle Eventualitäten sehe ich auch nicht voraus, auch wenn sich die Anzahl der "don't cares", die tatsächlich keine sind, im Lauf der Jahre schon verringert.

Was ich ursprünglich zum Ausdruck bringen wollte, ist, dass die "Wenn-dann"-Struktur die Stärke von ST ist und man die auch nutzen sollte. Dass man dabei zu Anfang oft genug das "Sonst" ausser Acht lässt, weiss ich aus eigener Erfahrung nur zu gut. Wenn man lernfähig ist, sollte dieser Drob aber nach der ersten so programmierten Katastrophe gelutscht sein.

Bei einer simplen Aufgabe wie in meinem ursprünglichen Beispiel bevorzuge ich auch die direkte Zuweisung. Dies kann sich aber schon bei einer geringfügigen Änderung der Aufgabe umkehren. Dazu noch ein Beispiel:

```
IF Rueckwaerts
THEN
   Ausgabe:= -Sollwert;
ELSE
   Ausgabe:= Sollwert;
END_IF;

Ausgabe:=(1-(BOOL_TO_SINT(Rueckwaerts)*2)*Sollwert;
```

Ich gebe zu, dem Charme des Einzeilers schon mal erlegen zu sein. Aber jedes Mal, wenn sich ein Kollege erst mal am Kopf kratzt, bekomme ich ein schlechtes Gewissen.


----------



## PN/DP (21 März 2011)

Ich will hier nochmal drauf zurückkommen:


StructuredTrash schrieb:


> Das Programm von Dante zeigt sehr gut, wie sich die Denkweise beim Programmieren mit ST langsam aber sicher zum "Wenn-Dann" entwickelt. Und sobald auch nur ein wenig speichernde Logik hinzukommt, ist das in meinen Augen auch besser verständlich.


Sicher *kann* man mit IF...THEN...ELSE auch gute Programme schreiben, die wie mit FUP/KOP funktionieren. Mir gefällt diese Entwicklung zum Wenn-Dann aber nicht, gerade wegen der einfachen und verständlichen Formulierbarkeit (das begreift fast jeder Depp). Auch dafür ist das Programm von Dante ein gutes Beispiel: schnell was hingetippt, was auf den ersten Blick das tut, was es soll - doch wehe das Programm wird aus der Testumgebung in das reale Umfeld entlassen, mit Bedingungen, die der Programmierer nicht vorhergesehen hat.


dante schrieb:


> Habs ihm schon komplett geschrieben
> 
> Hier die exportierte Version: (mit seinen Angaben gemacht ohne Sicherheit das die Pumpen trocken laufen oder so)


Typisch sind "schon", "komplett" und dann doch noch Einschränkungen für die reale Verwendbarkeit.

Das zeigt doch, das die Aufgabe nicht mehr zuerst durchdacht wird (*), sondern sofort losprogrammiert wird und dann mal sehen, was es tut. Die paar Macken, die beim ersten Test auffallen, sind doch schnell mit weiteren Wenn-Dann umschifft!

Das dumme an dieser Wenn-Dann-Denke ist: sie *verführt* unheimlich dazu, Ereignis-orientiert ("vom Eingang zu den Ausgängen") zu programmieren und möglichst alle Reaktionen inklusive aller zu schaltender Ausgänge sofort in den Dann-Zweig zu legen. Das Bilden von Zwischenmerkern und anschließendes Verknüpfen zu einer Ausgangszuweisung ist vielen Programmierern scheinbar unbekannt oder sie meinen, diesen "überflüssigen" zusätzlichen Aufwand könne man sich sparen.

Vielleicht habe ich vorhin StructuredTrash falsch verstanden, vieleicht meinte er mit "speichernde Logik" solche Zwischenmerker?

(*) Apropos vorher durchdenken: da hat Question_mark letztens was schön formuliert.

Harald


----------



## Blockmove (21 März 2011)

PN/DP schrieb:


> Das dumme an dieser Wenn-Dann-Denke ist: sie *verführt* unheimlich dazu, Ereignis-orientiert ("vom Eingang zu den Ausgängen") zu programmieren


 
Ich glaube, dass das die Wurzel allen Übels ist.
Ereignis-Steuerung im Vergleich zu Verknüpfungssteuerung.
Was bei Windows-Programmierung gut ist, muss noch lange nicht für Automatisierung taugen. 

Gruß
Dieter


----------



## bike (21 März 2011)

Blockmove schrieb:


> Ich glaube, dass das die Wurzel allen Übels ist.
> Ereignis-Steuerung im Vergleich zu Verknüpfungssteuerung.
> Was bei Windows-Programmierung gut ist, muss noch lange nicht für Automatisierung taugen.
> 
> ...



Wobei ich bis heute noch? nicht überzeugt bin, ob das bei Windows der richtige erfolgreiche Weg ist. 
Doch die Hochsprachen erlauben eben dies und was funktioniert wird irgendwie genutzt.


bike


----------



## StructuredTrash (21 März 2011)

PN/DP schrieb:
			
		

> Mir gefällt diese Entwicklung zum Wenn-Dann aber nicht, gerade wegen der  einfachen und verständlichen Formulierbarkeit (das begreift fast jeder  Depp).


Ich finde auch als Nicht-Depp Gefallen an gut Verständlichem.



			
				PN/DP schrieb:
			
		

> Vielleicht habe ich vorhin StructuredTrash falsch verstanden, vieleicht meinte er mit "speichernde Logik" solche Zwischenmerker?


Nein, ich meine damit das, was man allgemein darunter versteht. Logik, bei der nicht jedem Eingangszustand ein eindeutiger Ausgangszustand zugeordnet ist.




			
				Blockmove schrieb:
			
		

> Ich glaube, dass das die Wurzel allen Übels ist.
> Ereignis-Steuerung im Vergleich zu Verknüpfungssteuerung.


Für die Wurzel allen Übels halte ich eher dies:


			
				PN/DP schrieb:
			
		

> Das zeigt doch, das die Aufgabe nicht mehr zuerst durchdacht wird (*),  sondern sofort losprogrammiert wird und dann mal sehen, was es tut.


Davor bietet aber auch eine Verknüpfungssteuerung keinen wirksamen Schutz. Zugegeben, es ist dabei schwieriger, bestimmte Zustände bei der Programmierung unberücksichtigt zu lassen. Dafür besteht die Gefahr, dass Monster-Netzwerke entstehen, bei denen man die Funktion im normalen Betrieb vor lauter Verriegelungen kaum noch erkennt. Die Verwendung von Zwischenmerkern, wie sie PN/DP nennt, scheint da tatsächlich weitgehend unbekannt zu sein.
Es gibt eben bei jeder Programmierweise gute und böse Programmierer.


----------



## dante (21 März 2011)

Ich konnte ja nur das Programmieren was ich an I/O hatte und mir an Funktion gegeben wurde. Ich denke für seinen Code dort war Wenn / Dann total okay! 

In vielen Beckhoff Bausteinen wird mit Case der Programmcode realisiert. Auch hier werden alle möglichen Variablen gesetzt / rückgesetzt.

Bei der Wenn / Dann programmierung muss man halt sehen das ALLE Zustandsfälle ausgenutzt werden. Ich sehe selbst nicht das große Problem, da er mal locker noch seine Trockenlaufschalter oder Hysteresen einbauen kann. Zu kompliziert würde ich es auch net angehen und ich habe Kommentare geschrieben das auch ein Neuling sich zurechtfindet.

@*PN/DP*

Du kannst gerne die 2 seitige PDF bekommen und codest es besser, wenn du damit fertig bist kannst du auch gerne meinen Code kritisieren. Einfach mal den Ball flach halten und es besser machen. Es gibt gerade bei der Programmierung 1000 Wege zum Ziel.


----------



## bike (21 März 2011)

dante schrieb:


> Ich konnte ja nur das Programmieren was ich an I/O hatte und mir an Funktion gegeben wurde. Ich denke für seinen Code dort war Wenn / Dann total okay!



Vielleicht solltest du zuerst genauer nachdenken und nachfragen.
So ein Bruchstück schreibe ich dir wenn in meiner Kneipe auf das nexte Bier warte. 
Aber! ich stell so etwas nie ins Netz.




dante schrieb:


> @*PN/DP*
> 
> Du kannst gerne die 2 seitige PDF bekommen und codest es besser, wenn du damit fertig bist kannst du auch gerne meinen Code kritisieren. Einfach mal den Ball flach halten und es besser machen. Es gibt gerade bei der Programmierung 1000 Wege zum Ziel.



Wenn ich jetzt recht gelesen habe, bist du der Überzeugung, dass dein Code gut und richtig ist und alle möglichen Abbruch- und Ausnahmesituationen berücksichtigt werden?


bike


P.S: Ich hoffe du schreibst so nicht für uns.


----------



## IBFS (21 März 2011)

dante schrieb:


> Bei der Wenn / Dann programmierung muss man halt sehen das ALLE Zustandsfälle ausgenutzt werden. Ich sehe selbst nicht das große Problem, da er mal locker noch seine Trockenlaufschalter oder Hysteresen einbauen kann.



Vernünftige Programme entstehen nur, wenn man von der Automaten- bzw. Zustandstheorie ausgeht.

Dieses --- nah de müssen wir eben noch  ein UN( O.. O ) U (..) dazuhäcken und schon  passt das   -  ist Müll.

Wie schnell haut einem der Herr Karnough (kennste den ) die Füße weg.

Spätestens wenn man eine Teilfunktion stilllegen (auskommentieren) muß - mal eben kurz  - dann kracht es, weil man etwas nicht bedacht hat.

Nene, EINDEUTIGE Zustände definieren - auch für sowass "scheinbar" (nicht "anscheinend") simples wie eine Pumpensteuerung.

Wenn man klar Zustände hat, kann man diese Zustände auch klar benennen
und ggf. auch den passenden - dem Zustand entsprechenden - Text in das Faceplate einblenden.

Wenn man nicht in der Lage ist das Zustandsdiagramm zu zeichnen, dann sollte
man lieber erst garnicht programmieren.
Leider habe ich schon extremen Pfusch gesehen, daher bin ich in meinem
Auffassung ggf. etwas sehr prägnant.

Frank


----------



## xinix (21 März 2011)

bike schrieb:


> So ein Bruchstück schreibe ich dir wenn in meiner Kneipe auf das nexte Bier warte.
> Aber! ich stell so etwas nie ins Netz.
> 
> Wenn ich jetzt recht gelesen habe, bist du der Überzeugung, dass dein Code gut und richtig ist und alle möglichen Abbruch- und Ausnahmesituationen berücksichtigt werden?
> ...



Darf ich mal fragen warum Du so agressiv argumentierst?  Bis jetzt nörgelt Ihr alle nur rum und meint ihr könnt es besser, Dante ist aber der einzige der sich mal ne Stunde zeit genommen hat und mir als einziger zu meiner Frage und zu meien ersten Schritten in ST weitergeholfen hat. Auch wenn er mir damit vielleicht nicht den Diamanten präsentiert hat, ist voll ok. Den hätt ich wohl für den Anfang auch nicht verstanden.


----------



## Blockmove (22 März 2011)

xinix schrieb:


> Darf ich mal fragen warum Du so agressiv argumentierst?  Bis jetzt nörgelt Ihr alle nur rum und meint ihr könnt es besser, Dante ist aber der einzige der sich mal ne Stunde zeit genommen hat und mir als einziger zu meiner Frage und zu meien ersten Schritten in ST weitergeholfen hat.



Vielleicht mag es daran liegen, dass wir uns in der Praxis zu oft mit Programmen dieser Art "vergnügen" dürfen. 

Dieter


----------



## bike (22 März 2011)

xinix schrieb:


> Darf ich mal fragen warum Du so agressiv argumentierst?  Bis jetzt nörgelt Ihr alle nur rum und meint ihr könnt es besser, Dante ist aber der einzige der sich mal ne Stunde zeit genommen hat und mir als einziger zu meiner Frage und zu meien ersten Schritten in ST weitergeholfen hat. Auch wenn er mir damit vielleicht nicht den Diamanten präsentiert hat, ist voll ok. Den hätt ich wohl für den Anfang auch nicht verstanden.



Weil wir, wie Blockmove richtig schreibt, zu oft mit solchen Ergüssen beglückt werden.
Deine Anschauung in aller Ehre, doch besser nichts bekommen, als etwas falsches.
Wenn du dir etwas falsch angewöhnt hast und es mit Glück vielleicht sogar funktioniert, wirst du weiter in diese Richtung arbeiten und dann?


Daher bin ich der Meinung besser nichts als etwas falsches zu schreiben.


bike


----------



## dante (22 März 2011)

Ich finde es sehr bedauernd, dass hier immer mehr Personen im Forum unterwegs sind die mehr negative Kommentare geben als Hilfestellung. In diesem Fall hier hat er eine Aufgabenstellung zusammengestellt und diese wurde 1:1 lauffähig umgesetzt. Hier erlauben sich dann Personen ein Urteil die nicht mal die Aufgabe kennen. 
Ich bin der, der sich überhaupt mal Zeit nahm und falls ihr eine twincat Schulung besuchen durftet dort wird in St noch viel niedriger begonnen. Warum soll er für seine hobbyanlage Nukularrichtlinien befolgen? Urteil darf sich nur wer erlauben der sich auch die Aufgabe angeschaut hat. Hier geht der konsens des Forums leider zugrunde. Wiewar das mit dem wissen das geteilt wird? Ich sehe keine andere Lösung oder gar einen Ansatz hier. Ganz einfach ... Aufgabe angucken und damit was besseres machen.


----------



## bike (22 März 2011)

dante schrieb:


> Hier erlauben sich dann Personen ein Urteil die nicht mal die Aufgabe kennen.



Es geht nicht um die Aufgabe an sich, sondern darum zu vermeiden, dass etwas falsch gelernt / beigebracht wird.




dante schrieb:


> Wiewar das mit dem wissen das geteilt wird?



Wissen ja, aber bitte kein Halbwissen.



bike


----------



## Mobi (22 März 2011)

Ich gebe den anderen recht. Man sollte nicht los programmieren in der Hoffnung das man alle Fehlerzustände ausmerzt. Deshalb verdienen auch andere Firmen damit ihr Geld und das zurecht. Der Kunde sagt was er haben will und die Firma "konstruiert" das Programm. D.h. das sie sich auch vorher Gedanken machen, welche Fehler auftreten könnten und wie man das Programm am sinnvollsten schreibt. Da es sogar durch die Programmierung zu nicht vorhersehbaren Fehlern kommen kann. Vielleicht sagt dir ein KV-Diagramm was?


----------



## gloeru (22 März 2011)

*Grundsatzdebatte...*

Ich, als nicht-Voll-Profi verfolge die Diskussion hier mit etwas gemischten Gefühlen, und möchte ein paar Punkte in die Runde werfen:


Was ist wirklich richtig/falsch, was ist Ansichtssache, und wer entscheidet das? (auch Profs können sich mal irren)
Wie habt Ihr begonnen zu programmieren? - Viele jüngere Leute (inkl. ich) lernen mit der Try-and-Error Methode, d.h. ausprobieren, versuchen, auf die Fresse fliegen, nachfragen (z.B hier), besser machen, etwas gelernt haben!
Für eine kleine Gartenteich-Steuerung denke ich reicht dieses Vorgehen aus. Hätte er eine profesionelle Lösung gesucht, wäre er zu einem Ingenieur-Büro gegangen. Dies schliesst Sicherheitsbedenken und gut gemeinte Ratschläge natürlich nicht aus!
Wenn nur noch die Profis hier Wissen vermitteln möchten, müssten ja auch immer dieselben antworten.  - Ich denke, es gibt genug hochstehende Fragen, wo sich die Profis voll auslassen dürfen.
Was herrscht hier für eine Lernkultur: Darf man beim Lernen Fehler machen? - Darf man dumme Fragen stellen? - *Lernen durch lehren kann sehr interessant sein, auch wenn nicht 100% alles stimmt, ist dies oft eine Win-Win Situation!
*
Kleine Anekdote:


Als Ihr in der Schule zu dividieren begonnen habt, hat die Lehrerin sicherlich mit 12 Äpfel durch 6 Schüler, nicht gerade mit dem Satz von l'Hôpital begonnen... (Div/0)
Fazit:


Für einfache und Anfängerfragen reichen doch einfache Code-Beispiele aus. Wenn der Fragesteller interessiert ist, werden danach laufen Nachfolge-Fragen kommen. Besser er versteht was er macht, als er macht scheinbar alles richtig, versteht aber sein Code garnicht....
*P.S: Die ist als kleiner Denkanstoss gedacht, möchte mir nicht erlauben, hier jemand direkt zu kritisieren!*


----------



## bike (22 März 2011)

Da hast du absolut recht.
Wenn jemand ein Problem hat, es versucht zu lösen und dann sich Hilfe holt ist das absolut richtig.
Doch wenn jemand anderes ein Programm schreibt, hier publiziert und es dann nicht abkann, wenn Einwände, die auf Problem dieser Art zu programmieren hinweisen, kommen, dann ist dies ebenfalls  richtig und wichtig.
Es gibt keine allgemeingültige Art zu programmieren, jedoch sollten gewisse Regeln beachtet werden.


bike


----------



## ahds (22 März 2011)

gloeru schrieb:


> Ich, als nicht-Voll-Profi verfolge die Diskussion hier mit etwas gemischten Gefühlen, und möchte ein paar Punkte in die Runde werfen:



Um auch mal so ein hübsches Bild zu nutzen: *ACK*

Ich finde Elfenbeinturm-Denken gefährlicher als ein kleines, dreckiges Programm das ein Problem löst.

Aber was mich am meisten interessiert: wo ist der wirkliche Kritikpunkt? 
Die Sprache ST generell? 
Das vllt nicht ganz "nach Geschmack" aufgezogene Zustands-Handling? (Ich hätte es ja auch anders gemacht... Aber das ist doch egal!)

Neugierig und viele Grüße,
ahds


----------



## IBFS (22 März 2011)

ahds schrieb:


> Ich finde Elfenbeinturm-Denken gefährlicher *als ein kleines, dreckiges Programm *das ein Problem löst.



Ich hoffe mal nicht das dein 5er BMW nicht auch "dreckig" programmiert ist.

Diese kleinen dreckigen Programme holen dich, oder deinen Nachfolger irgendwann ein.

Ich habe heute wieder mal so ein dreckiges Programm ändern müssen:

- Merker ohne Symbolik

- L   DB7.DBD38     obwohl im Ziel-DB  an dieser Stelle 2 Worte definiert waren (das es dadurch nicht symbolisch dargestellt war, muss ich hoffentlich nicht weiter erwähnen)

- Datenbausteine ohne Symbolik  (gut bei CFC ist das normal aber sonst nicht)

- ...

- keine Sicherungen hinterm Netzteil (ok. das ist Hardware)

usw.

Ich kann dieses Selbstgefällige - Quick und Dirty -Gerede einfach nicht mehr hören.

Was meinst du, wenn du ein Festpreisangebot machen muss und dann geht es los und du musst erst mal mühsam den Mist glattziehen - dann möchte ich dich sehen was du dann sagst.

Frank


----------



## bike (22 März 2011)

ahds schrieb:


> Ich finde Elfenbeinturm-Denken gefährlicher als ein kleines, dreckiges Programm das ein Problem löst.




Ich hoffe, dass du kein Programmierer bist.
Mal eben quick and dirty ein Programm basteln und dann verschwinden.
Der Lackierte ist der Kunde.
Ich mache lieber ein paar Änderungen, auch wenn diese nicht im Angebot sind.
Daher kann ich auch später meinen Kunden ins Gesicht sehen. 
Bisher hatte ich noch nie Probleme so wegen Anwalt oder so.

Es geht nicht um ST. Ich verwende SCL und ST auch, doch für jede Aufgabe das richtige Werkzeug, das ist meine Meinung.


bike


----------



## StructuredTrash (22 März 2011)

bike schrieb:
			
		

> Ich hoffe, dass du kein Programmierer bist.
> Mal eben quick and dirty ein Programm basteln und dann verschwinden.


Dem kann man nur zustimmen.



			
				bike schrieb:
			
		

> Es geht nicht um ST.


Ein wenig hatte ich bislang schon den Eindruck, dass es eher um Glaubensfragen ging, inkl. meiner eigenen Beiträge. Die einzige konkrete Kritik war doch diese hier:


			
				PN/DP schrieb:
			
		

> Kannst Du auf Anhieb genau sagen, was die Pumpen in Deinem Programm  machen, wenn z.B. binit=FALSE und bBetrieb=FALSE oder im anderen Fall  binit=TRUE und bBetrieb=TRUE sind? (Sag jetzt nicht, daß beide Fälle in  Deinem Programm niemals vorkommen können).


Den Zustand bInit=False und bBetrieb=False kann das Programm nicht verhindern, dazu ist es auf die ordnungsgemässe Funktion der Sensorik angewiesen. Sich darauf zu verlassen, ist schon gefährlich. Ausserdem wird man bei einer Umsetzung der Teichsteuerung diese auch mal ausschalten wollen. Es wäre daher mindestens guter Stil, wenn nicht mehr gewesen, diesen Fall zu berücksichtigen.
bInit=True und bBetrieb=True sind dagegen im Programm verriegelt. Auf eine Reaktion darauf kann man daher wohl verzichten. Schlecht ist aber, dass man sich überhaupt mit dieser Möglichkeit beschäftigen muss. Die eindeutige Speicherung der Betriebsart in einer einzelnen Variablen wäre da besser.


----------



## gloeru (22 März 2011)

xinix schrieb:


> Ich frage einen Zustand ( START oder BETRIEB ) zweier Tanks, je nach den Füllständen meiner Teichanlage ab.



Ich denke, es geht weder um Kunden, noch um Anwälte, sondern um einen Heimwerker, der niemandem etwas verkaufen will. (Hoffe ich zumindest sehr!!)



> Die eindeutige Speicherung der Betriebsart in einer einzelnen Variablen wäre da besser.


Nur zu meinem Verständnis, meinst du damit indirekt auch gerade die Verwendung einer CASE Struktur? 


```
CASE iBetriebsart OF
0: (* Init *)
10: (* aus *)
20: (* Normalbetrieb *)
30: (* Niveau absenken oder sonst was *)
END_CASE
```


----------



## StructuredTrash (22 März 2011)

CASE OF bietet sich für so etwas meistens an. Ich würde allerdings die Werte für die Betriebsarten als Konstanten oder als Enumeration deklarieren. Die Wahrscheinlichkeit, dass durch Flüchtigkeitsfehler undefinierte Werte zustandekommen, wird damit geringer.
Ausserdem sollte die CASE-Anweisung einen ELSE-Zweig enthalten, mit dem die Anlage in einen definierten Zustand gebracht bzw. dort gehalten wird. Im einfachsten Fall kann dort die selbe Aktion oder der selbe FB wie bei "Aus" aufgerufen werden. Ein, zumindest in der Entwicklumgsumgebung, sichtbarer Hinweis darauf, dass dieser Aufruf irregulär zustandegekommen ist, kann dabei aber nicht schaden.


----------



## ahds (22 März 2011)

bike schrieb:


> Ich hoffe, dass du kein Programmierer bist.
> Mal eben quick and dirty ein Programm basteln und dann verschwinden.
> Der Lackierte ist der Kunde.



Naja also wir kennen uns ja alle nicht - und ich sowieso niemanden, wo ich doch recht neu in diesem Forum bin. Auch musst Du was mich betrifft nichts hoffen oder Dich bangen. 

Grundsätzlich stimme ich Dir ja schon zu: ein kleiner Hack kann viel ausrichten und man sollte schon probieren, es "richtig"(tm) zu machen. Mein Elfenbeinturm bezog sich jedenfalls darauf, jedes noch so kleine Problemlösung auseinanderzupflücken - ohne den Kontext u.a. im Auge zu halten. Natürlich MUSS ein großes Projekt sauber geplant sein und die Architekturvorgaben müssen eingehalten werden. Auch andere Konventionen etc. spielen dann eine große Rolle.
Aber machen wir uns nix vor: Für ein kleines Ding, dass nebenher gelöst werden muss - damit es läuft und man keinen Doktortitel (ob mit oder ohne KGT sei mal dahingestellt) dafür braucht, da reicht auch der kleine Hack.
Und als Anstoss für jemanden, der sowieso neu in der Materie erst recht.

Jedenfalls ist das meine Meinung.

Und nach als Randbemerkung: ich habe interessante Einblicke in die Auto-Steuerungstechnik bzw. die Entwicklung derselben bei Audi erhalten. Und danach wunderte ich mich doch sehr, dass überhaupt ein Audi je am Ziel ankommt! Ich sag nur "Produkt reift beim Kunden." Und das gilt nicht nur für Audi! Die Elektronikprobleme des Alfas eines Bekannten sind in meinem Bekanntenkreis schon legendär!


Insofern: die Realität (=deadline) holt doch auch den ausgebufftesten Programmierer ein! Wissen wir doch alle. Also wieso soviel Wind wegen einem kleinen Hack, der doch nur als Startschuss dienen sollte? Und eben als einfache Lösung?

Liebe Grüße
ahds


----------



## StructuredTrash (22 März 2011)

ahds schrieb:
			
		

> Für ein kleines Ding, dass nebenher gelöst werden muss - damit es läuft  und man keinen Doktortitel (ob mit oder ohne KGT sei mal dahingestellt)  dafür braucht, da reicht auch der kleine Hack.


Warum sollte man privat weniger hohe Ansprüche an sich selbst stellen als beruflich? Gerade da geht es doch an den eigenen Geldbeutel, wenn man etwas in Grund und Boden fährt.



			
				ahds schrieb:
			
		

> Und als Anstoss für jemanden, der sowieso neu in der Materie erst recht.


Der Anstoss gibt oft auch eine Richtung vor, und die sollte schon stimmen.


----------



## IBFS (22 März 2011)

ahds schrieb:


> ... wo ich doch recht neu in diesem Forum bin. ....ahds



immerhin schon seit 2009. ;-)

kommt dein NICK eigentlich daher?: http://de.wikipedia.org/wiki/Aufmerksamkeitsdefizit-/Hyperaktivitätsstörung 

[duck .. und .. wech]  

Frank


----------



## bike (23 März 2011)

ahds schrieb:


> Naja also wir kennen uns ja alle nicht - und ich sowieso niemanden, wo ich doch recht neu in diesem Forum bin. Auch musst Du was mich betrifft nichts hoffen oder Dich bangen.



Meine Bedenken hatten eigentlich nichts direkt mit dir zu tun.
Ich dachte eher an die betroffenen Kunden.




ahds schrieb:


> Aber machen wir uns nix vor: Für ein kleines Ding, dass nebenher gelöst werden muss - damit es läuft und man keinen Doktortitel (ob mit oder ohne KGT sei mal dahingestellt) dafür braucht, da reicht auch der kleine Hack.
> Und als Anstoss für jemanden, der sowieso neu in der Materie erst recht.
> 
> Jedenfalls ist das meine Meinung.



Wenn du gelesen hast, möchte hier nicht jemand einen "Hack" mal eben machen, sondern das Programmieren lernen. Und da ist genug Zeit um es gleich und richtig zu machen.




ahds schrieb:


> Und nach als Randbemerkung: ich habe interessante Einblicke in die Auto-Steuerungstechnik bzw. die Entwicklung derselben bei Audi erhalten.
> 
> Insofern: die Realität (=deadline) holt doch auch den ausgebufftesten Programmierer ein! Wissen wir doch alle. Also wieso soviel Wind wegen einem kleinen Hack, der doch nur als Startschuss dienen sollte? Und eben als einfache Lösung?



Wenn es andere falsch machen, muss ich es auch falsch machen?
Nur wenn die Messlatte hoch liegt und man die überqueren muss, kommt Qualität heraus.


bike


----------



## ahds (23 März 2011)

IBFS schrieb:


> kommt dein NICK eigentlich daher?: http://de.wikipedia.org/wiki/Aufmerksamkeitsdefizit-/Hyperaktivitätsstörung
> 
> [duck .. und .. wech]
> 
> Frank



Harhar, hat da auch schon jemand den Witz bemerkt!  

Ich hab damals halt mit ADS von Beckhoff "rumspielen" müssen und fand A"h"DS dann für meine Situation ganz passend. 

Grüße,
ahds


----------



## ahds (23 März 2011)

bike schrieb:


> Wenn es andere falsch machen, muss ich es auch falsch machen?



Im Grunde stimme ich Dir doch durchweg zu. 

Ich habe nur meine persönliche Situation gesehen und mich an meine eigenen Erfahrungen eben mit Elfenbeinturm-Anspruchsdenken in unserem Betrieb (von mir und anderen) nochmal vor Augen gehalten - und an die Konsequenzen gedacht. Und so kam mein Kommentar zustande. 

Insofern bitte nichts für ungut und
liebe Grüße,
ahds

PS: Ich finde aber Diskussionen über SPS-Programmieren bzw. über Programmorganisation usw. grundsätzlich schon sehr interessant - eben weil ich "neu" in dieser Domäne bin.


----------



## xinix (24 März 2011)

Also ich hatte die letzten tage keine Zeit in Forum zu gehen und habe eben noch mal aufholend nachgelesen....

Wenn ich das alles richtig verstanden haben, geht es zusammenfassend darum:

Das Programm sieht keine Aktionen auf nicht berücksichtigte und ungeklährte Zustände vor. Diese könne man zwar einbauen aber dafür wären die IF THEN ELSE dann zu unübersichtlich?

Scheinbar geht es auch primär um den Startschuss - oder?

Ist das so richtig?

Mal abgesehen davon, dass ich mir den eventuell in Frage kommenden (nicht berücksichtigten) Zuständen selbst bewusst werden muss, was wäre denn da eine gute alternaive von der Programmierung her?

Die beschriebene CASE ?

Darf ich mich in der CASE neben den festen Werter eigenlich auch  solches beziehen?

CASE iBetriebsart OF
T1<100 AND T2<100: (* Init *)
usw...

END_CASE
oder muss ich diese "Nenner vorher setzen und diese dann gezielt abfragen?

Dazu erst einmal Danke!

Zum Schuss noch mal eins... Dante hat mich bei der Übermittlund darauf hin gewiesen, das auf Grund fehlender Informationen Schutzmechanissmen nicht berücksichtigt wurde. z.B. Pumpentrockenlauf usw. Das ganze ging wie anfangs gesagt auch erst einmal nur um das Verständnis. Im gesamten hat mir der gesamte Beitrag dann schlussendlich viel gelehrt.

Gruß aus Hamburg...


----------



## StructuredTrash (24 März 2011)

xinix schrieb:


> Darf ich mich in der CASE neben den festen Werter eigenlich auch  solches beziehen?
> 
> CASE iBetriebsart OF
> T1<100 AND T2<100: (* Init *)
> ...



Nein, als CASE-Selektoren können nur konstante Werte dienen. Also z. B. so

```
CASE iBetriebsart OF
   0: (*Aus*)
   1: (*Init*)
   2: (*Betrieb*)
END_CASE;
```
oder besser so

```
VAR CONSTANT
BaAus:BYTE:=0;
BaInit:BYTE:=1;
BaBetrieb:BYTE:=2;
END_VAR

CASE iBetriebsart OF
   BAAus:
   BAInit:
   BABetrieb:
END_CASE;
```
Vor der CASE-Anweisung musst Du einen der Werte an iBetrieb zuweisen, und zwar so, dass iBetrieb auf jeden Fall =BAAus wird, wenn weder die Bedingung für BAInit noch die für BABetrieb gegeben ist.

Und noch etwas zum Startschuss. Ich gebe zu, dass ich das Programm zunächst nur kurz überflogen habe. Und als dann der Begriff "Schmiedehammer" eingeworfen wurde, habe ich gedacht, dass es vorrangig um den verschwenderischen Einsatz von IF THEN ELSE ginge.
Mittlerweile habe ich mir das Programm etwas genauer angeschaut und kann den teilweise scharfen Ton der Kritik schon verstehen.
Nimm z. B. dies hier


> IF nTank_1<100 AND nTank_2<100 AND F_TRIG_Filterung.Q=FALSE AND bBetrieb=FALSE THEN     bInit=TRUE;


Wozu dient das "AND F_TRIG_Filterung.Q=False"? Doch wohl dazu, einen zweiten Init-Anlauf zu verhindern. Aber wieso funktioniert das? F_TRIG_Filterung.Q ist doch der Ausgang eines Flankenerkennungs-FB's, der eigentlich nur für einen Zyklus True sein sollte. Weisst Du es? Und wenn ja, hältst Du es für eine saubere Lösung?


----------



## Blockmove (24 März 2011)

StructuredTrash schrieb:


> Und noch etwas zum Startschuss. Ich gebe zu, dass ich das Programm zunächst nur kurz überflogen habe. Und als dann der Begriff "Schmiedehammer" eingeworfen wurde, habe ich gedacht, dass es vorrangig um den verschwenderischen Einsatz von IF THEN ELSE ginge.
> Mittlerweile habe ich mir das Programm etwas genauer angeschaut und kann den teilweise scharfen Ton der Kritik schon verstehen.



Den Schmidehammer habe ich "eingeworfen"
Grund hierfür war:
ST / SCL halte generell nicht für Anfänger geeignet. Man sollte sich erstmal mit der Arbeitsweise einer SPS vertraut machen und nicht versuchen einfach PC-Programmierung auf die SPS zu übertragen. Sowas geht in der Regel schief. KOP und FUP sind hier - meines Erachtens - weniger kritisch, da hier Programme meist verknüfungsorientiert porgrammiert werden. Die meisten ST/SCL-Programme sine eher ereignisorientiert. Oder einfach gesagt: Bei KOP / FUP steht der Ausgang im Vordergrund, bei ST/SCL der Eingang.

Gruß
Dieter


----------



## StructuredTrash (24 März 2011)

Blockmove schrieb:


> ST / SCL halte generell nicht für Anfänger geeignet. Man sollte sich erstmal mit der Arbeitsweise einer SPS vertraut machen und nicht versuchen einfach PC-Programmierung auf die SPS zu übertragen. Sowas geht in der Regel schief. KOP und FUP sind hier - meines Erachtens - weniger kritisch, da hier Programme meist verknüfungsorientiert porgrammiert werden. Die meisten ST/SCL-Programme sine eher ereignisorientiert. Oder einfach gesagt: Bei KOP / FUP steht der Ausgang im Vordergrund, bei ST/SCL der Eingang.


*ACK*

Vor meinen ersten Automations-Gehversuchen in Pascal habe ich jahrelang mit Schleicher-P02-Steuerungen gearbeitet. Die liessen sich nur in KOP programmieren und kannten noch nicht einmal R/S-Befehle. Ohne diesen Hintergrund würde ich meinem Nick wohl nicht nur bei Spass-Denkaufgaben nach dem Motto "Wer präsentiert die abgedrehteste Lösung" gerecht werden.


----------



## bike (24 März 2011)

StructuredTrash schrieb:


> Mittlerweile habe ich mir das Programm etwas genauer angeschaut und kann den teilweise scharfen Ton der Kritik schon verstehen.



Du siehst es so wie andere hier.
Besser nichts schreiben als falsch.

Und zu Kop mal der Hinweis, nicht nur du hast solche hochtechnischen PLC programmieren dürfen.  
Doch gibt es zwischen KOP und ST noch verschiedenes, das für ANfänger sinnvoll ist.


bike


----------



## StructuredTrash (24 März 2011)

bike schrieb:


> Und zu Kop mal der Hinweis, nicht nur du hast solche hochtechnischen PLC programmieren dürfen.



Wenn man heutige SPSen sieht, scheinen Lichtjahre dazwischen zu liegen. Aber schön war es auch. Da war man noch mit jedem Bit per Du, ein Gefühl, das heute mehr und mehr schwindet.


----------



## ahds (26 März 2011)

Blockmove schrieb:


> ST / SCL halte generell nicht für Anfänger geeignet. Man sollte sich erstmal mit der Arbeitsweise einer SPS vertraut machen und nicht versuchen einfach PC-Programmierung auf die SPS zu übertragen.



Gäbe es einen "100% No-Ack", den würd ich jetzt drücken. 

Mit derselben Einstellung hätte die PC-Programmierung nie die Assembler-Schmuddelecke verlassen und hoch-effiziente Compiler hätten nie das Licht der Welt entdeckt. Auch interpretierte Sprachen (Java, C#, Python, ...) die auf all diesen Technologien aufsetzen, wären heute nicht in der Werkzeugkiste.

Meine Meinung also: Es geht alles in allem doch nur um SPS-Programmierung. Zu fordern, dass man erstmal "Hardware-nah" sich die Finger wund tippen muss, um zwei alberne Eingänge miteinander zu vergleichen nur "um ein Gespür für eine SPS zu bekommen", der macht sich doch ein wenig lächerlich. Sorry, ist ja nicht persönlich gemeint.

ST und Konsorten sind ja doch wohl (auch) da, um all das zu vereinfachen und eben Programmierer aus anderen Domänen (wie mich) schneller und leichter in die SPS-Welt produktiv einzuführen.

Und das ist auch gut so. Oder? 

liebe Grüße,
ahds


----------



## Blockmove (26 März 2011)

ahds schrieb:


> Mit derselben Einstellung hätte die PC-Programmierung nie die Assembler-Schmuddelecke verlassen und hoch-effiziente Compiler hätten nie das Licht der Welt entdeckt. Auch interpretierte Sprachen (Java, C#, Python, ...) die auf all diesen Technologien aufsetzen, wären heute nicht in der Werkzeugkiste.
> 
> Meine Meinung also: Es geht alles in allem doch nur um SPS-Programmierung.



Deine Argumentation ist schlichtweg nur polemenisch und realitätsfremd.
Programmiersprachen sind Werkzeuge. Nicht mehr und nicht weniger.
Die Aufgabe bestimmt die Wahl des Werkzeuges. Du kannst deinen Garten mit einem Kaffeelöffel umgraben und deine Torte mit einem Spaten essen. Beides wird funktionieren und zum Ziel führen. Nur unter welchem Umständen?

Auch wenn es deiner Meinung nach "nur um SPS-Programmierung" geht, dann sollte man vielleicht nicht vergessen, dass so manches Menschenleben von der Sorgfalt des SPS-Programmierers abhängt (Stichwort: Sicherheits-SPS).

Dieter


----------



## rostiger Nagel (26 März 2011)

Blockmove schrieb:


> Deine Argumentation ist schlichtweg nur polemenisch und realitätsfremd.
> Programmiersprachen sind Werkzeuge. Nicht mehr und nicht weniger.
> Die Aufgabe bestimmt die Wahl des Werkzeuges. Du kannst deinen Garten mit einem Kaffeelöffel umgraben und deine Torte mit einem Spaten essen. Beides wird funktionieren und zum Ziel führen. Nur unter welchem Umständen?
> 
> ...



Ich gebe dir vollkomen recht, nicht umsonst werden Sicherheits SPS 'en wie
Siemens nur in FUP oder KOP programmiert. Für jede Art das richtige Werkzeug, 
für einfache Verknüpfungen sind die altbewährten Sprachen FUP, KOP und 
natürlich AWL das richtige Werkzeug, alles andere macht einfach keinen Sinn. 

Aber das mit den Spaten für den Kuchen werde ich morgen beim Sonntags-
Kaffee ersteinmal versuchen, ich glaube da werde ich um einiges effizienter


----------



## PN/DP (26 März 2011)

ahds schrieb:


> Blockmove schrieb:
> 
> 
> > ST / SCL halte generell nicht für Anfänger geeignet. Man sollte sich erstmal mit der Arbeitsweise einer SPS vertraut machen und nicht versuchen einfach PC-Programmierung auf die SPS zu übertragen.
> ...


Das zeigt mir, daß Du anscheinend auch zu der Sorte Programmierer gehörst, die (noch) nicht begriffen haben, daß SPS völlig anders als PC programmiert werden müssen.
Die Betonung in der Aussage von Blockmove liegt in "*sich erstmal in der Arbeitsweise einer SPS vertraut machen*" - siehe die danach folgenden Sätze, die Du nicht zitiert hast.
Für den kompletten Beitrag von Blockmove gibt es meine volle *ACK*.



ahds schrieb:


> Meine Meinung also: Es geht alles in allem doch nur um SPS-Programmierung. Zu fordern, dass man erstmal "Hardware-nah" sich die Finger wund tippen muss, um zwei alberne Eingänge miteinander zu vergleichen nur "um ein Gespür für eine SPS zu bekommen", der macht sich doch ein wenig lächerlich. Sorry, ist ja nicht persönlich gemeint.


Es geht nicht "nur" um SPS-Programmierung, sondern um die Programmierung von Maschinen und Anlagen, die bei solchen undurchdachten Programmen, wie sie mit ST und Konsorten leicht möglich sind, immerhin einigen materiellen Schaden und gesundheitliche Beinträchtigungen bis hin zum Tod von Menschen anrichten können. Deshalb sind SPS anders konstruiert und arbeiten anders als z.B. Windows-PC. Und deshalb kann man die überwiegend ereignisorientierte (und unzuverlässige!) Programmierweise aus der PC-Welt nicht in die SPS-Welt übertragen. Eine SPS ist eine Zustandsmaschine, die unter allen Umständen zu einem kontrollierten Schalt-Ergebnis kommen muß. Die speziellen SPS-Programmiersprachen FUP/KOP/AWL wurden nicht erfunden, damit man sich "die Finger wund" tippt (und Hardware-nah würde ich die auch nicht bezeichnen), sondern damit man einfach übersichtliche und zuverlässige logische Verknüfungen erstellen kann. Wie immer gilt: Für jede Aufgabe soll man das richtige Werkzeug benutzen. ST ist für mich NICHT das richtige Werkzeug um logische Verknüpfungen zu programmieren.



ahds schrieb:


> ST und Konsorten sind ja doch wohl (auch) da, um all das zu vereinfachen und eben Programmierer aus anderen Domänen (wie mich) schneller und leichter in die SPS-Welt produktiv einzuführen.


Klar ist ST auch dazu da, das Programmieren zu vereinfachen, ABER: nicht losprogrammieren ohne die Technik und die Prozesse zu verstehen!

Harald


----------



## rostiger Nagel (26 März 2011)

Ich kann auch nicht erkennen das Mann sich an AWL die finger wund
Programmieren soll.

```
U(
O #Start
O #Antrieb
)
U #Eingang_1
U #Eingang_2
U #Eingang_3
UN #Stop
= #Antrieb
```

so kleine Konstrukte lassen sich doch schnell runter tippen und später
wunderbar warten. 

Habe ich aber solche Lösungen wie hier heute von Thomas_V2.1 erstellt,
ziehe ich die eindeutig vor, obwohl ich es in AWL programmiert hätte, weil
leider in SCL nicht so fit bin. 


```
FUNCTION FC2000 : VOID

VAR_INPUT
    DATA: ARRAY[1..50] OF INT;
END_VAR

VAR_IN_OUT
    OUT1 : ARRAY[1..100] OF BOOL;
END_VAR

VAR_TEMP
    i : INT;
    x : INT;
END_VAR

BEGIN
    // Ausgangsarray initialisieren
    FOR i := 1 TO 100 DO
        OUT1[i] := false;
    FOR i := 1 TO 50 DO
        x := DATA[i];
        IF x >= 1 AND x <= 100 THEN
            OUT1[x] := true;
        END_IF;
    END_FOR;       
    
END_FUNCTION
```


----------



## zotos (26 März 2011)

Helmut_von_der_Reparatur schrieb:


> Ich kann auch nicht erkennen das Mann sich an AWL die finger wund
> Programmieren soll.
> 
> ```
> ...


oh... ist das hässlich. Aber wohl Geschmackssache.
AWL mit Selbsthaltung ist jetzt nicht mein Favorit.

Und zu dem Sicherheitsgelaber von einigen Kollegen hier kann ich echt nur noch den Kopfschütteln. Wenn ich mir die wilde AWL Pointerei, Zugriffe auf Lokaldaten und fehlende Typcast ansehe möchte ich mal darauf hinweisen warum man für ST Pascal als Vorlage gewählt hat:


> Heute findet Pascal im universitären Bereich (Entwicklung/Ausbildung)  und in *sicherheitskritischen Bereichen (z. B. Verkehrstechnik,  Energieversorgung, Medizintechnik, Raumfahrt, Militär, teilweise im  Banken- und Versicherungswesen)* Anwendung. Dies beruht hauptsächlich auf  der guten Prüfbarkeit und Wartbarkeit des Codes und der klaren  Zuordnung der Variablen. So ist die 2005 eingeführte Betriebsleittechnik IV der Transrapid-Versuchsanlage Emsland in Pascal programmiert.


Quelle: http://de.wikipedia.org/wiki/Pascal_(Programmiersprache)


----------



## rostiger Nagel (26 März 2011)

zotos schrieb:


> oh... ist das hässlich. Aber wohl Geschmackssache.
> AWL mit Selbsthaltung ist jetzt nicht mein Favorit.
> 
> Und zu dem Sicherheitsgelaber von einigen Kollegen hier kann ich echt nur noch den Kopfschütteln. Wenn ich mir die wilde AWL Pointerei, Zugriffe auf Lokaldaten und fehlende Typcast ansehe möchte ich mal darauf hinweisen warum man für ST Pascal als Vorlage gewählt hat:
> Quelle: http://de.wikipedia.org/wiki/Pascal_(Programmiersprache)



Natürlich ist das hässlich selbsthaltung mit einen "Oder" aber ich habe gerade 
In der Eile das 'S' und 'R' nicht gefunden. Was glaubst du wie das aussieht
wenn ich mit den Spaten den Kuchen esse, wichtig ist nur das ich das größte
Stück bekomme


----------



## Blockmove (26 März 2011)

Helmut_von_der_Reparatur schrieb:


> wichtig ist nur das ich das größte Stück bekomme



Genau Helmut *ACK*

SPS-Programmierer unserer Altersklasse wissen eben, was wichtig ist 

Gruß
Dieter


----------



## Thomas_v2.1 (26 März 2011)

zotos schrieb:


> oh... ist das hässlich. Aber wohl Geschmackssache.
> AWL mit Selbsthaltung ist jetzt nicht mein Favorit.
> 
> Und zu dem Sicherheitsgelaber von einigen Kollegen hier kann ich echt nur noch den Kopfschütteln. Wenn ich mir die wilde AWL Pointerei, Zugriffe auf Lokaldaten und fehlende Typcast ansehe möchte ich mal darauf hinweisen warum man für ST Pascal als Vorlage gewählt hat:
> Quelle: http://de.wikipedia.org/wiki/Pascal_(Programmiersprache)



Volle Zustimmung. Wobei in sicherheitsrelevanten Anlagen wohl öfter ADA zum Einsatz kommt.
Für AWL gibt es nichtmal eine formale Sprachbeschreibung. Das heißt ich kann alles Mögliche programmieren was ich will: keine Überprüfung auf syntaktische Korrektheit, keine Typüberprüfung, nada. Wie man auf die Idee kommen kann dass dieses ausgerechnet zur Programmierung von sicherheitsrelevanten Anlagen das Beste sein soll entzieht sich meiner Kenntnis. Außer es handelt sich dabei um absolut triviale Programme die in ihrer Gesamtheit auf eine Bildschirmseite passen.


----------



## bike (26 März 2011)

Thomas_v2.1 schrieb:


> Volle Zustimmung. Wobei in sicherheitsrelevanten Anlagen wohl öfter ADA zum Einsatz kommt.
> Für AWL gibt es nichtmal eine formale Sprachbeschreibung. Das heißt ich kann alles Mögliche programmieren was ich will: keine Überprüfung auf syntaktische Korrektheit, keine Typüberprüfung, nada. Wie man auf die Idee kommen kann dass dieses ausgerechnet zur Programmierung von sicherheitsrelevanten Anlagen das Beste sein soll entzieht sich meiner Kenntnis. Außer es handelt sich dabei um absolut triviale Programme die in ihrer Gesamtheit auf eine Bildschirmseite passen.



Daher gibt es bei BigS ja auch kein AWL bei Sicherheitssteuerungen.
Und FUP oder KOP haben eine Syntaxprüfung, wenn die nicht passt, geht es nicht.


bike


----------



## ahds (27 März 2011)

Naja, bevor man mir wieder Polemik, Unkenntnis o.ä. vorwirft, verabschiede ich mich mal besser. Es ist ja nur SPS-Programmierung, keine Rocket-Science, wie es so schön heißt.  

liebe Grüße,
ahds


----------



## Blockmove (27 März 2011)

ahds schrieb:


> Es ist ja nur SPS-Programmierung, keine Rocket-Science, wie es so schön heißt.



Meiner Meinung nach disqualizifizierst du dich einfach durch deine Aussagen.
Zeig mir heute einen Bereich wo SPS keine Rolle spielt. Egal ob Versorgung (Wasser, Strom), Produktion, Logistik.
Selbst dein Sarg oder deine Urne wird mal mit Hilfe von SPS-gesteuerten Anlagen hergestellt 

Gruß
Dieter


----------



## rostiger Nagel (27 März 2011)

Blockmove schrieb:


> Meiner Meinung nach disqualizifizierst du dich einfach durch deine Aussagen.
> Zeig mir heute einen Bereich wo SPS keine Rolle spielt. Egal ob Versorgung (Wasser, Strom), Produktion, Logistik.
> Selbst dein Sarg oder deine Urne wird mal mit Hilfe von SPS-gesteuerten Anlagen hergestellt
> 
> ...



Sarg kann ich mit Sicherheit bestätigen!
Einfache Kreissägen sehen mittlerweile so aus http://www.altendorf.de/de/produkte/f-45-elmo/f-45-elmo-iv.html


----------



## ahds (27 März 2011)

Blockmove schrieb:


> Meiner Meinung nach disqualizifizierst du dich einfach durch deine Aussagen.



Na soviel dazu. Schön pauschal und ad homimen - aber mir wird Polemik vorgeworfen.  Aber ok. Und es ist Sonntag. (Und mit dem Link meine ich Dich, mein lieber Dieter.)



> Zeig mir heute einen Bereich wo SPS keine Rolle spielt. Egal ob Versorgung (Wasser, Strom), Produktion, Logistik.



Habe ich etwas anderes behauptet? Oder behauptet, SPSe spielen keine Rolle? Meine Güte, ich sagte dass SPS-Programmierung keine Rocket-Science ist. Wo bitte liest Du da, es würde keine Rolle spielen?

Wenn ich mal recht kurz zusammenfassen darf:

Ich habe gesagt, dass ich a) z.B. ST für Einsteiger gut finde und ich stehe immer noch b) zu der Aussage, dass man nicht immer mit dem perfektesten Schnippsel Programm anfangen muss, zu lernen. c) sagte ich, dass ich ST bevorzuge, weil ich bei AWL das Gefühl bekomme, mir die Finger wund zu tippen. (Und zu schnell den Überblick verliere, zugegeben. )

Und zu a-c stehe ich uneingeschränkt - und ich sehe auch nicht, wo mich das "disqualifiziert". Und ich habe sogar schon erfolgreich Projekte durchgezogen, die fast zu 100% in *Vorsicht, ganz leise* "ST" geschrieben worden sind.


Also ehrlich, was hab ich denn hier angestellt?
...und eigentlich wollte ich mich doch verabschieden... 
liebe Grüße,
ahds


----------



## drfunfrock (27 März 2011)

Übrigens mir wäre St oder AWL oder Ladder scheiss egal. Wichtig ist allein, dass die Kritierien an Überprüfbarkeit des Programmes und der Wartbarkeit erfüllt werden. Dazu gehört aber ein bisschen mehr, als der Streit um die richtige Progammiersprache. 

Übrigens, ein richtiger Mann und ich meine einen richtigen Mann, der programmiert per Binärschalter jedes Bit einzeln. Nur das garantiert, dass die Maschine keinen Mist macht. Und eine SPS kann nur vernünftig programmiert werden, wenn man auch um den letzten Transistor weiss.


----------

