Step 7 Erste Übung mit UDT-Array (Fehler beim CPU Start)

escride1 schrieb:
Weil es nicht jedem einfach so in den Sinn kommt das wenn er eine einfache Abfrage erstellt dann dies nochmal optimieren kann.
Wer weiß was in wessen alten Programmen so an sinnfreiem Code existent ist.
Zum Vergrößern anklicken....
Das ist dann aber auch nur, weil die Programmierer heutzutage sehr oft hochsprachenverseucht sind (, und nicht mehr die Grundlagen der EDV = einfache Logikschaltungen beherrschen).

Davon abgesehen, gebe ich dir recht, dass wohl jeder Programmierer über altes, selbstgeschriebenes manchmal den Kopf schüttelt.
 
Ich würde eher sagen das viele Programmierer heute Schule nach Plan des gelangweilten Lehrers bekommen und daher viele Punkte einfach rausfallen, hauptsache sie können erstmal programmieren und den Rest könn se später lernen.

Und hier:
Noebsi schrieb:
Auf meinem Weg mir selbstständig die S7 PLC Programmierung beizubringen
Zum Vergrößern anklicken....
Ich denke, das wenn man so versucht zu lernen, spezielle Tipps und Tricks einfach nicht vorhanden sind. Wie soll man denn darauf kommen es in einer Zeile zu schreiben wenn es einem nie gesagt wird oder es nicht da steht? Selbst Siemens-eigene Bausteine sind teilweise mit IF-THEN-Orgien gefüllt.

Ich sehe aktuell beim Programmierkurs meiner Tochter in der Berufsschule solche Problematiken ebenso. Es werden alle Langbegriffe in HTML, CSS und Co beigebracht, aber in CSS ne ordentliche Struktur aufbauen ist Fehlanzeige. Lieber 10 mal das gleiche definieren.
 
PN/DP schrieb:
Wieso?? Die Zuweisungen werden bei jedem Programmdurchlauf bei jedem möglichen Verknüpfungsergebnis ausgeführt - auch bei FALSE. In der normalen "richtigen" Programmversion von Peter Wahlen als auch in der IF-Schwuchtelei.
Zum Vergrößern anklicken....
Hast Recht. Gedankenfehler. Das ist ja nur in den IF-Anweisungen so, aber durch die ELSE-Abzweigung wird es ja initialisiert.
 
Peter Wahlen schrieb:
Hallo Noebsi,

wenn ich so etwas sehe, frage ich mich: Warum?
Code: 
//Schrankensteuerung Einfahrt
    IF IS1_E AND R_E <> TRUE AND TASTER THEN          // bezieht sich das <> nur auf R_E oder auf (IS1_E und R_E), was ist gemeint/gewollt?
        SCHRANKE_E := TRUE;
    ELSE
        SCHRANKE_E := FALSE;
    END_IF;

    //Schrankensteuerung Ausfahrt
    IF IS1_A AND DB2.TICKET[N].Bezahlt = TRUE THEN
        SCHRANKE_A := TRUE;
    ELSE
        SCHRANKE_A := FALSE;
    END_IF;

warum nicht so:
Code: 
//Schrankensteuerung Einfahrt
    SCHRANKE_E := IS1_E AND NOT(R_E) AND TASTER;    // Je nach dem, was gewollt ist, nur diese
    SCHRANKE_E := NOT(IS1_E AND R_E) AND TASTER;    // oder diese Zeile verwenden!

//Schrankensteuerung Ausfahrt
    SCHRANKE_A := IS1_A AND DB2.TICKET[N].Bezahlt;
Zum Vergrößern anklicken....
Hallo!
Naja, da ich gerade erst mit dem SPS Programmieren und Programmieren generell anfange, war die Schreibweise für mich verständlicher.
Einen anderen Grund gibt's dafür nicht.

Danke jedoch trotzdem für die Info, sieht viel besser aus.

Bg
 
Peter Wahlen schrieb:
Hallo Noebsi,

wenn ich so etwas sehe, frage ich mich: Warum?
Code: 
//Schrankensteuerung Einfahrt
    IF IS1_E AND R_E <> TRUE AND TASTER THEN          // bezieht sich das <> nur auf R_E oder auf (IS1_E und R_E), was ist gemeint/gewollt?
        SCHRANKE_E := TRUE;
    ELSE
        SCHRANKE_E := FALSE;
    END_IF;

    //Schrankensteuerung Ausfahrt
    IF IS1_A AND DB2.TICKET[N].Bezahlt = TRUE THEN
        SCHRANKE_A := TRUE;
    ELSE
        SCHRANKE_A := FALSE;
    END_IF;

warum nicht so:
Code: 
//Schrankensteuerung Einfahrt
    SCHRANKE_E := IS1_E AND NOT(R_E) AND TASTER;    // Je nach dem, was gewollt ist, nur diese
    SCHRANKE_E := NOT(IS1_E AND R_E) AND TASTER;    // oder diese Zeile verwenden!

//Schrankensteuerung Ausfahrt
    SCHRANKE_A := IS1_A AND DB2.TICKET[N].Bezahlt;
Zum Vergrößern anklicken....
Hallo nochmal!

Hätte mir das ganze jetzt genauer angeschaut und eine Frage zu der Schreibweise.

Wenn ich hier statt der IF-ELSE Verzweigung diese einfachen Deklarationen mache, werden dann die Zustände von (z.B. SCHRANKE_E überschrieben?

Bsp. Anstelle von:
Code: 
IF IS1_E AND R_E <> TRUE AND TASTER THEN //Wenn Einfahren will    
        SCHRANKE_E := TRUE;
        sPassed_In := TRUE;      
ELSIF IS1_E AND IS2_E AND sPassed_In THEN //Wenn noch unter Schranken steht
        SCHRANKE_E := TRUE;

Mit deiner Schreibweise (Bitte korrigiere mich, falls das falsch ist):

Code: 
SCHRANKE_E := IS1_E AND R_E <> TRUE AND TASTER;
SCHRANKE_E := IS1_E AND IS2_E AND sPassed_In;

Würde hier nicht die zweite Anweisung die erste überschreiben, falls die erste TRUE ist, aber die danach FALSE?
Tue mir bei sowas noch mit dem Verständnis etwas schwer.

Lg
 
Vorsicht!

Eine IF Then Else Abfrage kannst du durch eine Zuweisung ersetzen, weil eine IF Then Else Abfrage im Prinzip das selbe macht.

Jetzt hast du jedoch If Then ElseIf Abfrage, das ist etwas anderes!

Versuche am besten in Logischen Gatten (wie bei FUP) zu denken. Dann sind logische Verknüpfungen leichter zu verstehen.

Welche Zustände willst du hier eigentlich abfragen? Stichwort Operatorenrangfolge
Code: 
SCHRANKE_E := IS1_E AND R_E <> TRUE AND TASTER;          bedeutet ==> IS1_E AND NOT R_E AND TASTER

// (IS1_E=TRUE) UND (R_E=FALSE) UND (TASTER=TRUE)        besser so ==> IS1_E AND NOT R_E AND TASTER
// oder
// (IS1_E=FALSE) UND (R_E=FALSE) UND (TASTER=TRUE)       besser so ==> NOT IS1_E AND NOT R_E AND TASTER
//                                                       oder so   ==> NOT(IS1_E OR R_E) AND TASTER
 
Peter Wahlen schrieb:
Vorsicht!

Eine IF Then Else Abfrage kannst du durch eine Zuweisung ersetzen, weil eine IF Then Else Abfrage im Prinzip das selbe macht.

Jetzt hast du jedoch If Then ElseIf Abfrage, das ist etwas anderes!

Versuche am besten in Logischen Gatten (wie bei FUP) zu denken. Dann sind logische Verknüpfungen leichter zu verstehen.

Welche Zustände willst du hier eigentlich abfragen? Stichwort Operatorenrangfolge
Code: 
SCHRANKE_E := IS1_E AND R_E <> TRUE AND TASTER;          bedeutet ==> IS1_E AND NOT R_E AND TASTER

// (IS1_E=TRUE) UND (R_E=FALSE) UND (TASTER=TRUE)        besser so ==> IS1_E AND NOT R_E AND TASTER
// oder
// (IS1_E=FALSE) UND (R_E=FALSE) UND (TASTER=TRUE)       besser so ==> NOT IS1_E AND NOT R_E AND TASTER
//                                                       oder so   ==> NOT(IS1_E OR R_E) AND TASTER
Zum Vergrößern anklicken....
Gut, eine IF-ELSE Verzweigung mit den Zuweisungen zu ersetzen kann ich mir wie gesagt einfach vorstellen.
Aber die Diskussion die ihr alle davor hattet war ja explizit auf dieses Beispiel bezogen, bei welchem ich ein ELSIF verwende.
--> Die Kombi von "deiner" Schreibweise und ELSIF verwirrt mich eben hierbei.

Und der Zustand den ich abfragen möchte ist genau der, der hier abgefragt wird (also der erste).

Quasi: Induktionsspule1 UND NICHT Ampel_Rot_Eingang UND TasterEinfahrt
Da sollte das ja mit meiner Schreibweise korrekt abgefragt werden, soweit ich das verstanden habe. (zumindest funktioniert es so beim Simulieren)
 
Zuletzt bearbeitet:
Hallo Noebsi,

dann werden deine Signale so abgefragt, wie du möchtest. Ich wusste nicht, ob du die Operatorenrangfolge beachtest hast.

Ich habe dazu leider auf die Schnelle nur bei den 1200/1500 gefunden:

SIOS

support.industry.siemens.com support.industry.siemens.com
dort der Abschnitt: 17.1.6 Operatoren und Operatorenrangfolge

Ich hatte auch nur einen Hinweis zu der Vereinfachung von IF Then Else zu einer Verknüpfung aufgezeigt. Falls das zu einer Verwirrung geführt hat, bitte ich um Entschuldigung.
 
Peter Wahlen schrieb:
Hallo Noebsi,

dann werden deine Signale so abgefragt, wie du möchtest. Ich wusste nicht, ob du die Operatorenrangfolge beachtest hast.

Ich habe dazu leider auf die Schnelle nur bei den 1200/1500 gefunden:

SIOS

support.industry.siemens.com support.industry.siemens.com
dort der Abschnitt: 17.1.6 Operatoren und Operatorenrangfolge

Ich hatte auch nur einen Hinweis zu der Vereinfachung von IF Then Else zu einer Verknüpfung aufgezeigt. Falls das zu einer Verwirrung geführt hat, bitte ich um Entschuldigung.
Zum Vergrößern anklicken....
Achso, okay dann war das ein Missverständnis, macht nichts.
Ich habe mit der verkürzten Schreibweise ja trotzdem was dazu gelernt.(y)

Ich dachte nur, dass sich diese auch bei ELSIF anwenden lässt, da der Abschnitt den du ausgeschnitten hast ja in meinem Programm ein ELSIF beinhaltet.
Mir ist leider nicht aufgefallen, dass du das bei deinem ursprünglichen Post verändert gepostet hast, tut mir leid.

Bg
 
Noebsi schrieb:
Code: 
SCHRANKE_E := IS1_E AND R_E <> TRUE AND TASTER;
SCHRANKE_E := IS1_E AND IS2_E AND sPassed_In;

Würde hier nicht die zweite Anweisung die erste überschreiben, falls die erste TRUE ist, aber die danach FALSE?
Zum Vergrößern anklicken....
Die zweite Anweisung überschreibt immer die Zuweisung der ersten Anweisung, egal welche Ergebnisse die beiden Anweisungen haben. Die erste Anweisung ist daher völlig überflüssig.
Peter Wahlen hatte zwei alternative Programmzeilen geschrieben, weil er nicht sicher war, ob deine Formulierung der Bedingungs-Logik korrekt ist, und hatte zwei alternative Möglichkeiten der Formulierung gezeigt und dazugeschrieben "// Je nach dem, was gewollt ist, nur diese // oder diese Zeile verwenden!" (ggf. scrolle den Code-Block nach rechts)
Peter Wahlen schrieb:
Code: 
//Schrankensteuerung Einfahrt
    SCHRANKE_E := IS1_E AND NOT(R_E) AND TASTER;    // Je nach dem, was gewollt ist, nur diese
    SCHRANKE_E := NOT(IS1_E AND R_E) AND TASTER;    // oder diese Zeile verwenden!
Zum Vergrößern anklicken....

"IF-Schwurbelei" ist, wenn bei einer IF-Anweisung der ELSE-Zweig genau das logische Gegenteil vom THEN-Zweig macht, z.B. TRUE oder FALSE an dieselbe Variable zuweisen. Die Schwurbelei ist perferkt ;), wenn da auch noch das Ergebnis der Bedingungs-Logik mit TRUE oder FALSE verglichen wird!
Code: 
IF Bedingung = TRUE THEN
  BoolVariable := TRUE;
ELSE
  BoolVariable := FALSE;
END_IF;

//sowas schreibt man viel besser einfach so:
BoolVariable := Bedingung;

1. Man braucht nicht das Ergebnis von logischen (boolschen) Ausdrücken mit TRUE oder FALSE vergleichen, man kann das boolsche Ergebnis auch gleich direkt verwenden und z.B. einer boolschen Variable zuweisen. Der SCL-Compiler optimiert solche unnötigen Vergleiche automatisch weg.
2. IF..THEN..ELSE-Anweisungen werden vom SCL-Compiler in Programmverzweigungen mit Sprung-Anweisungen übersetzt, um die Anweisungen der jeweils nicht erfüllten Zweige zu überspringen. Zwei verschiedene Zuweisungen plus zwei Sprünge sind nicht so effizient wie einfach nur eine Zuweisung. Der SCL-Compiler optimiert solchen umständlichen IF..THEN..ELSE-Code nicht, sondern erzeugt uneffizienten Code genau so umständlich wie vom Programmierer hingeschieben.
3. Man muss bei einer Programmanalyse/-beobachtung nicht noch extra aufmerksam den ELSE-Zweig analysieren, ob da derselben Variable das logische Gegenteil vom THEN-Zweig zugewiesen wird. Man kann da auch keinen Tippfehler im Variablenname machen, wenn es den ELSE-Zweig nicht gibt.

SCL ist einfach nicht gut geeignet, um logische Verknüpfungen zu programmieren. Dafür nimmt man besser KOP oder FUP. Da braucht man auch keine nötigen oder unnötigen Operandenvorrang-Klammern, um die Logik übersichtlicher oder eindeutiger zu machen. Besonders für Quereinsteiger aus Hochsprachen verführt SCL leider zu oft schlecht überlegter und/oder unvollständiger Logik - wir nennen das "IF-Orgien", besonders wenn der Programmierer aufgrund seines unübersichtlichen/schlecht verständlichen Programms noch "vorsichtshalber" (oft zum größten Teil unnötige) Reset-Zuweisungen an alle möglichen Variablen macht und damit vorherige Formulierungen ggf. unerwartet wieder über den Haufen wirft. Solche mehrfachen Zuweisungen an verstreuten Stellen lassen sich äußerst schlecht beobachen, wenn man z.B. sehen will, warum ein Ventil unerwartet schließt.
 
Zuletzt bearbeitet:

Similar threads

M
TIA AGLink Zugriff auf Array of UDT oder Array of Struct
Antworten
2
Aufrufe
745
meikSPS
M
N
Step 7 Probleme mit Loop und globalen DBs
Antworten
6
Aufrufe
1K
Gleichstromer
Gleichstromer
P
TIA CPU Stopp mit Fehler Technologieobjekt aktiv
Antworten
6
Aufrufe
586
DeltaMikeAir
DeltaMikeAir
S
TIA 1500er CPU mit verschiedenen TIA Versionen Probleme CPU im Stop
Antworten
3
Aufrufe
720
spqr76
S
D
codesys 2.3 Update 2.3.9.47->2.3.9.72 - Übersetzung produziert Fehler in Verbindung mit Bibliotheken
2
Antworten
20
Aufrufe
3K
Babustino
B
Zurück
Oben