# würdet ist das auch so machen? ist das so üblich



## Grimsey (4 April 2019)

Hallo zusammen,

ich habe in einem Programm von einem unserer Lieferanten folgende Passage gefunden:

```
"gb".cmd_ack                :=
    "gb".FU_FaAntr.ctrl.b.rst   :=        
    "gb".FU_LW.ctrl.b.rst       :=  
    "gb".FU_QS_Mat.ctrl.b.rst   :=  
    "gb".FU_LS.ctrl.b.rst       :=  
    "gb".FU_RSW_1.ctrl.b.rst    := 
    "gb".FU_RSW_2.ctrl.b.rst    := 
    "gb".FU_RSW_3.ctrl.b.rst    := 
            #HtP_cmd_ack_TP.Q
        OR  #Quitt_TP.Q
        OR  #rst_Not_Aus_TP.Q
        OR  #Ini_I_on_RT.Q
        OR  #RM_HS_RT.Q;
```

Um ehrlich zu sein musste ich mir das gerade in einem Testprojekt mal nachbauen um zu prüfen was genau da passiert.
Soweit habe ich das verstanden aber ich finde es recht unübersichtlich.

Ich hätte mir eher ein Signal aus der ODER-Verknüpfung gebaut und dieses dann den einzelnen Signalen zugewiesen.
Fände ich deutlich besser lesbar.

Da mir diese Schreibweise ehrlich gesagt neu war, wollte ich mal fragen ob das eine verbreitet Schreibweise ist und Ihr das eventuell auch so macht.
Reines Interesse.


----------



## Larry Laffer (4 April 2019)

Nein ... das würde ich auch so nicht machen und ... das habe ich auch noch nicht gesehen ... 8)
Ich würde hier auch die Verknüpfung in einer Variablen bilden und diese dann den anderen Variablen, die den gleichen Inhalt haben sollen, zuweisen.

Wenn man das weiterspinnt dann lassen sich wahrscheinlich noch ganz andere Konstrukte erschaffen, durch die man dann wirklich nicht mehr auf Anhieb durchblickt - also währet den Anfängen ...

Gruß
Larry


----------



## PN/DP (4 April 2019)

"A := B := C := ausdruck;" würde ich allerhöchstens in einem Anlaufbaustein zur Initialisierung von gleichen Anfangswerten machen oder tolerieren.

Das werden vermutlich nicht die einzigen Wertzuweisungen an A, B und C sein, und dieser Programmierstil führt oft zu höchst schwer verfolgbaren mehrfachen bedingten Zuweisungen an die selbe Variable verstreut in mehreren Programmbausteinen (und zu sogenannten Angst-Reset-Orgien an vielen Stellen), anstatt übersichtlich in nur einem Netzwerk oder einer Bildschirmseite die Wertzuweisung(en) komplett abzuhandeln.

Bei mehreren Kunden (auch bei uns) sind solche verstreuten mehrfachen Zuweisungen für Zuliefer-Programme nicht erlaubt.

Harald


----------



## flyingsee (4 April 2019)

Haben die Variablen denn in einem Zyklus überhaupt den gleichen Wert? Oder brauch der da 8 Zyklen?

Ich wusste nichtmal das man es in SCL so schreiben kann.


----------



## Grimsey (4 April 2019)

PN/DP schrieb:


> "A := B := C := ausdruck;" würde ich allerhöchstens in einem Anlaufbaustein zur Initialisierung von gleichen Anfangswerten machen oder tolerieren.
> 
> Das werden vermutlich nicht die einzigen Wertzuweisungen an A, B und C sein, und dieser Programmierstil führt oft zu höchst schwer verfolgbaren mehrfachen bedingten Zuweisungen an die selbe Variable verstreut in mehreren Programmbausteinen (und zu sogenannten Angst-Reset-Orgien an vielen Stellen), anstatt übersichtlich in nur einem Netzwerk oder einer Bildschirmseite die Wertzuweisung(en) komplett abzuhandeln.
> 
> ...



Da gebe ich Dir und Euch vollkommen recht!
Dieser "Stil" zieht sich durch das gesamte Programm. Es ist es schwer nachzuvollziehen. Die Maschine an sich ist nichts sooo kompliziertes.
Mich stört schon diese Abkürzungsorgie...ich habe von dem Programmierer ein 4-seitiges Dokument mit der Auflistung der Abkürzungen bekommen(!!).
Leider war ich zur Auftragsvergabe und Ausschreibung noch nicht im Unternehmen, sonst hätte ich dem ein Riegel vorgeschoben.

Es ist auch ganz so wie Harald sagt: die Variablen werden quasi über das gesamte Programm verstreut zugewiesen und man sucht schon eine Weile. Das betrifft auch Ansteuersignale für FUs und Motoren...das hätte ich so nie gemacht. Einen Baustein für den Antrieb, der wird an einer Stelle aufgerufen und die notwendigen Signale werden an einer Stelle im Programm zugewiesen bzw. logisch verschaltet.

Aber gut zu wissen, dass ich nicht der Einzige bin der sich mit diesem "Stil" schwer tut.


----------



## PN/DP (4 April 2019)

flyingsee schrieb:


> Haben die Variablen denn in einem Zyklus überhaupt den gleichen Wert? Oder brauch der da 8 Zyklen?


Das sind einfach 8 Zuweisungen des selben Wertes nacheinander in der tippfaulen Variante. 
Normalerweise sollte der Compiler selber erkennen, daß er "A := 1; B := 1; C := 1;" oder "A := 1; B := A; C := A;" zu "A := B := C := 1;" umformen kann.

Harald


----------



## flyingsee (4 April 2019)

Ja bei anderen Hochsprachen ist mir das klar aber ob das bei SCL auch so ist weiss ich nicht.


----------



## Howard (4 April 2019)

Moin,
ich hoffe ihr macht dann aber konsequenterweise auch in FUP das:


und nicht das:




Ich sehe bei der Mehrfachzuweisung keine Probleme. Nur das ODER hätte ich zunächst auf eine temp geführt und dann zur Mehrfachzuweisung verwendet, um nochmal eine abweichende Meinung beizutragen.


----------



## Grimsey (4 April 2019)

Ich mag FUP ja nicht so sehr und schreibe neben SCL auch viel in KOP, aber ja ich würde es genauso machen.

Ist halt eine Frage der Lesbarkeit und weniger der Funktionalität, dass ist mir klar.
Gut lesbarer Code ist halt auch besser zu warten aber davon brauch ich hier ja nicht anfangen. Das wir alle alle ganz gut.


----------



## Howard (4 April 2019)

Ich wollte auch nur dem unbekannten Kollegen der das bei dir abliefert hat zur Seite springen. In meinen beiden FUP-Lösungen würde wohl keiner auf die Idee kommen eine der beiden Varianten als komisch oder unüblich zu empfinden. In SCL ist diese Funktion halt erst nachträglich mit V14 (glaub ich) hinzugekommen und schon irritiert einen das, obwohl es absolut das Selbe ist


----------



## PN/DP (4 April 2019)

Howard schrieb:


> Ich sehe bei der Mehrfachzuweisung keine Probleme.


Ich würde solche Zuweisungsketten nicht verwenden, weil man da nicht sicher sein kann, daß der schlecht dokumentierte SCL-Compiler das korrekt übersetzt. Es ist ja nicht das erste Mal daß die Siemens TIA-Compiler Entwickler etwas undurchdacht Optimierungen einbauen, die zu falschem Verhalten führen können.

Die SCL-Formulierung:

```
#a := #b := #c := #x OR #y OR #z;
```
entspricht in KOP programmiert folgendem:

```
#x         #c
--| |--+--+--( )
       |  |
  #y   |  |  #b
--| |--+  +--( )
       |  |
  #z   |  |  #a
--| |--+  +--( )
```
Falsch wäre, wenn es so übersetzt wird (oder wenn man selber so programmiert, weil es bequemer zusammengeklickt ist):

```
#x      #c     #b     #a
--| |--+--( )----( )----( )
       |
  #y   |
--| |--+
       |
  #z   |
--| |--+
```

Harald


----------



## Larry Laffer (4 April 2019)

Mal unabhängig davon kommt dann vielleicht irgendwann auch noch so etwas :
	
	



```
a := b := C := x1 and x2 := (Z>= 0) ;
```
Und was der Dinge mehr sind.
Sicher kann man das alles irgendwie so machen (egal ob KOP, FUP oder AWL) - das hat für mich aber nichts mehr mit "schreibfaul" zu tun . Irgendwann bleibt da dann auch mal die Lesbarkeit auf der Strecke. Da kommt dann am Ende dabei heraus, dass man sich das Programm erstmal Online ansehen muss damit man beurteilen kann ob eine Verknüfung und/oder Zuweisung überhaupt wie erwartet funktioniert ...

@Grimsey:
Da die Lieferanten mittlerweile sehr erfinderisch sind empfehle ich dir dringend ein Pflichtenheft zu erstellen, dass hier(für dich) sinnvolle Vorgaben macht.

Gruß
Larry


----------



## Howard (4 April 2019)

PN/DP schrieb:


> Ich würde solche Zuweisungsketten nicht verwenden, weil man da nicht sicher sein kann, daß der schlecht dokumentierte SCL-Compiler das korrekt übersetzt. Es ist ja nicht das erste Mal daß die Siemens TIA-Compiler Entwickler etwas undurchdacht Optimierungen einbauen, die zu falschem Verhalten führen können.


Ach Harald und Larry,
ihr habt ja schon recht, aber ich kann doch nicht auf alle neuen Funktionen vom TIA verzichten, nur weil ich nicht weiß wie gut oder schlecht Siemens das umgesetzt hat. Ich für meinen Teil probiere solche Dinge aus (in der Sim und auf der richtigen CPU), evaluiere sie für mich und verwende sie dann ggf. auch. Ich kann ja auch nicht auf jeden Siemens-Baustein verzichten, nur weil ich dort nicht selber reinschauen kann.
Natürlich sollte der TE ein ordentliches Pflichtenheft erstellen um ein Programm nach seinen Vorgaben und (Zuweisungs-)Vorstellungen zu erhalten. Mir wäre halt wichtiger ein gut dokumentiertes und vernünftig strukturiertes Programm zu bekommen und tausend andere Dinge, die wichtiger sind als die Art der Zuweisung, weil das am Tagesende einfach nur Geschmackssache ist.


----------



## Heinileini (4 April 2019)

Grimsey schrieb:


> Da mir diese Schreibweise ehrlich gesagt neu war, wollte ich mal fragen ob das eine verbreitet Schreibweise ist und Ihr das eventuell auch so macht.


Diese Schreibweise ist eigentlich uralt, ausser anscheinend in SCL.
Compiler, die nicht mit dem Problem zu kämpfen haben, dass dieselbe Schreibweise für WertZuweisungen und für Vergleiche auf gleich bei der jeweiligen Sprache verwendet werden, können i.A. solche Zuweisungen richtig verarbeiten.
A := B := C = D; ist eindeutig: wenn C gleich D ist, wird den Variablen A und B derselbe Wert True zugeordnet, sonst wird den Variablen A und B der Wert False zugeordnet - und zwar passiert das alles selbstverständlich im selben Zyklus.
Hier muss man allerdings aufpassen, weil sich die Anweisung über mehrere Zeilen erstrecken kann und erst durch das ";" beendet wird.
A = B = C = D (z.B. in VB) ist auch eindeutig, weil hier immer nur das erste "=" von links in einer Zeile die Zuweisung ist und alle folgenden "=" deshalb nur der VergleichsOperator sein können.
Hier muss man aufpassen, weil die Anweisung mit dem ZeilenEnde beendet ist und weitere Zeilen nicht mehr dazu gehören, es sei denn, . . . (StichWort "_") . . . aber das ist schon zu sehr off Topic.

Komischerweise habe ich noch nie gehört, dass sich jemand in AWL über
U Bit1
= Bit2
= Bit3
= Bit4
oder
L 0
T Wort1
T Wort2
T Wort3
den Kopf zerbrochen hätte, was davon in welchem Zyklus ausgeführt wird, wenn überhaupt.
Was daran so verwirrend und unverständlich sein soll, kann ich nicht nachempfinden.
Noch kompakter und klarer und übersichtlicher kann man doch kaum den Sachverhalt darstellen und ich wüsste auch nicht, dass Querverweise dadurch unter den Teppich gekehrt würden.

Für mein Verständnis hat dies auch nichts mit MehrfachZuweisung zu tun.
Für mich ist MehrfachZuweisung, wenn derselben Variablen an verschiedenen Stellen im Programm Werte zugewiesen werden und nicht, wenn mehreren Variablen an "zufällig" derselben Stelle im Programm "zufällig" derselbe Wert zugewiesen wird.

Gruss, Heinileini


----------



## Grimsey (4 April 2019)

Larry Laffer schrieb:


> @Grimsey:
> Da die Lieferanten mittlerweile sehr erfinderisch sind empfehle ich dir dringend ein Pflichtenheft zu erstellen, dass hier(für dich) sinnvolle Vorgaben macht.



Das war eine meiner ersten Amtshandlungen.

@Heinileini
in AWL würde ich es auch so machen, wie Du es gezeigt hast.
In dem gezeigten Code geht es auch nicht um Mehrfachzuweisung, denn das ist es defacto ja auch nicht (mal abgesehen davon das es diese trotzdem in dem Programm massenweise gibt...).
Ich hab diese Art halt zum 1.Mal gesehen und finde sie einfach nicht gut lesbar. 

Wie das hier aber schon erwähnt wurde, ist es natürlich auch eine Geschmackssache.
Und mein Geschmack ist es nicht


----------



## Larry Laffer (4 April 2019)

@Howard:
Ich bin auch ziemlich offen für alles mögliche - beim Thema Code-Lesbarkeit bin ich aber seeeeeehr konservativ. Ich denke auch mal, dass man nicht jeden Code-Gag schreiben muss, nur weil er machbar ist ...

@Heinileini:
Für mich ist diese Schreibweise für Code-Erstellung nicht uralt. Welche (noch aktuellen) Programmiersprachen verwenden so etwas denn alle so ...?

Gruß
Larry


----------



## Larry Laffer (4 April 2019)

Grimsey schrieb:


> Das war eine meiner ersten Amtshandlungen.


          :s12:                    .


----------



## Heinileini (4 April 2019)

Larry Laffer schrieb:


> Welche (noch aktuellen) Programmiersprachen verwenden so etwas denn alle so ...?


Kann ich aus dem Ärmel leider gar nicht sagen. Wahrscheinlich liegt das daran, dass die Schreibweise tatsächlich so uralt ist, dass sie in "noch aktuellen" ProgrammierSprachen gar nicht mehr so aktuell ist und ich in Sprachen wie FORTRAN IV & V, ALGOL 60 & 68, COBOL seit > (alias .GT.) 35 Jahren nicht mehr programmiert habe. PASCAL-Routinen habe ich mal in C umgeschrieben - ist aber auch schon wieder ewig her. Diverse BASIC-Dialekte und Assembler-Sprachen kommen wohl nicht in Frage, hp25, hp19/29, hp67/97 und hp41 auch nicht (vergleichbar mit AWL). Bei CL800 weiss ich's nicht mehr. 
Sorry, ich krieg's einfach nicht auf die Reihe und muss Dir die Antwort schuldig bleiben. Könnte natürlich anfangen, danach zu guugeln - aber wozu? Wir kennen die Schreibweise, können sie lesen und werden nicht gezwungen sie auch zu schreiben. :grin:

Gruss, Heinileini


----------



## PN/DP (5 April 2019)

Larry Laffer schrieb:


> Welche (noch aktuellen) Programmiersprachen verwenden so etwas denn alle so ...?


Ich kenne solche Zuweisungsketten von C/C++, die gibt es vermutlich auch bei allen C-Nachfolgern wie Java, C#, ...
(anscheinend bei C schaut sich TIA-SCL auch andere 50 Jahre alte Ideen für Neuerungen ab, wie z.B. die kombinierten Zuweisungen +=, -=, ...)

In C/C++ hat eine Zuweisung einen Wert/Rückgabewert (den Wert des Zugewiesenen) und kann deshalb auch als Ausdruck verwendet werden, und damit auch rechts von einer Zuweisung verwendet werden, oder als Teil eines Ausdrucks (!).

Harald


----------



## de vliegende hollander (5 April 2019)

Grimsey schrieb:


> Hallo zusammen,
> 
> ich habe in einem Programm von einem unserer Lieferanten folgende Passage gefunden:
> 
> ...



Ja, Ich nach das genau so. Aber nur im TIA
Seit TIA V14 ist dies möglich.

Ich spar mir ein weitere variable auf diese Weise.

Bram


----------



## rostiger Nagel (5 April 2019)

Ich finde die Art des Konstruktes irgendwie unübersichtlich, wenn man es schon benutzen
möchte, hätte man ja die Verknüpfung trennen können. Als Beispiel:

```
tmpBool :=  #HtP_cmd_ack_TP.Q
        OR  #Quitt_TP.Q
        OR  #rst_Not_Aus_TP.Q
        OR  #Ini_I_on_RT.Q
        OR  #RM_HS_RT.Q;




    "gb".cmd_ack                :=
    "gb".FU_FaAntr.ctrl.b.rst   :=        
    "gb".FU_LW.ctrl.b.rst       :=  
    "gb".FU_QS_Mat.ctrl.b.rst   :=  
    "gb".FU_LS.ctrl.b.rst       :=  
    "gb".FU_RSW_1.ctrl.b.rst    := 
    "gb".FU_RSW_2.ctrl.b.rst    := 
    "gb".FU_RSW_3.ctrl.b.rst    :=  tmpBool;        

[HR][/HR]
meine bevorzugte Variante hätte so ausgesehen:

    "gb".cmd_ack                :=  tmpBool; 
    "gb".FU_FaAntr.ctrl.b.rst   :=  tmpBool;         
    "gb".FU_LW.ctrl.b.rst       :=  tmpBool;   
    "gb".FU_QS_Mat.ctrl.b.rst   :=  tmpBool;   
    "gb".FU_LS.ctrl.b.rst       :=  tmpBool;  
    "gb".FU_RSW_1.ctrl.b.rst    :=  tmpBool; 
    "gb".FU_RSW_2.ctrl.b.rst    :=  tmpBool; 
    "gb".FU_RSW_3.ctrl.b.rst    :=  tmpBool;
```


----------



## Ralle (5 April 2019)

Was daran ist schwer zu lesen, außer, dass man es irgendwann zum ersten Mal sieht?
Ich hab das auch in einigen Programmen gesehen, spart zumindest eine weitere Temp-Var und wenn es nicht inflationär in jedem 2.NW steht, finde ich es nicht schlimm.
Über Mehrfachzuweisungen müssen wir ohnehin nicht reden, die sind nicht schön, in SCL aber inzwischen auch wesentlich mehr verbreitet, als in KOP/FUP. Das liegt sicher im System, ist bei SCL kaum wirlich zu vermeiden.


----------



## Heinileini (5 April 2019)

PN/DP schrieb:


> In C/C++ hat eine Zuweisung einen Wert/Rückgabewert (den Wert des Zugewiesenen) und kann deshalb auch als Ausdruck verwendet werden, . . .


Was mir daran gefallen hat: dass man damit das Inkrementieren eines SchleifenZählers und die Abfrage des SchleifenZählers zu einer Anweisung zusammenfassen kann.
Ist natürlich auch Geschmackssache.


----------



## PN/DP (5 April 2019)

de vliegende hollander schrieb:


> Ich spar mir ein weitere variable auf diese Weise.


Variablen sind bei Siemens bekanntlich ja sooo teuer. 

Siemens-Beispielprogramme nach Programmierstyleguide zeigen wie es gemacht werden soll  und speichern nach fast jeder einzelnen Operation jedes noch so unwichtige Zwischenergebnis auf Variablen  z.B. der FB LGF_Integration:


TheLevel schrieb:


> ```
> // Calculate time difference between last and actual time
> #tempDeltaTimeT := #statSysTime - #statLastTime;
> 
> ...







Heinileini schrieb:


> Was mir daran gefallen hat: dass man damit das Inkrementieren eines SchleifenZählers und die Abfrage des SchleifenZählers zu einer Anweisung zusammenfassen kann.


Noch besser: einen Null-terminierten String kopieren:

```
while (*d++ = *s++);
```

Harald


----------



## rostiger Nagel (5 April 2019)

Ralle schrieb:


> Was daran ist schwer zu lesen, außer, dass man es irgendwann zum ersten Mal sieht?
> Ich hab das auch in einigen Programmen gesehen, spart zumindest eine weitere Temp-Var und wenn es nicht inflationär in jedem 2.NW steht, finde ich es nicht schlimm.
> Über Mehrfachzuweisungen müssen wir ohnehin nicht reden, die sind nicht schön, in SCL aber inzwischen auch wesentlich mehr verbreitet, als in KOP/FUP. Das liegt sicher im System, ist bei SCL kaum wirlich zu vermeiden.



Grunsätzlich ist es schwer zu lesen ob die Verknüpfung erfüllt ist und warum Sie erfüllt ist.
Schöner wird es wenn noch zu den "OR" ein paar "AND" kommen, damit kann man sogar sich
selber zur Verzweifelung bringen.


----------



## Howard (5 April 2019)

rostiger Nagel schrieb:


> Grunsätzlich ist es schwer zu lesen ob die Verknüpfung erfüllt ist und warum Sie erfüllt ist.
> Schöner wird es wenn noch zu den "OR" ein paar "AND" kommen, damit kann man sogar sich
> selber zur Verzweifelung bringen.


da hast du leider recht, aber das liegt ja eher an der misslungenen Online-Ansicht von SCL und betrifft jede größere Verknüpfung. Den Onlinewert direkt an der Variable zu sehen wäre da hilfreicher. In solchen fällen kann ich nur die viel zitierte "gelbe Pest" empfehlen:


so kann man sich langsam von Variable zu Variable durchhangeln


----------



## Heinileini (5 April 2019)

PN/DP schrieb:


> anscheinend bei C schaut sich TIA-SCL auch andere 50 Jahre alte Ideen für Neuerungen ab, wie z.B. die kombinierten Zuweisungen +=, -=, ...


Für Schreibweisen wie += u.s.w. gab es mal einen Grund: man konnte damit SpeicherZugriffe und somit Ausführungszeit sparen. Das war noch zu der Zeit, als der Programmierer dem Compiler auf die Sprünge helfen musste, statt sich von einem im Compiler untergebrachten "Besserwisser" Überraschungen durch Optimierungen unterjubeln zu lassen.

Übrigens, die Klammern bei BitVerknüpfungen in AWL ermöglichen auch "Tricks", die für meinen Geschmack alles andere als "gut lesbar" sind. Habe diese Möglichkeiten immer gemieden und dementsprechend leider auch keine Beispiele parat.


----------



## vollmi (8 April 2019)

Howard schrieb:


> Moin,
> ich hoffe ihr macht dann aber konsequenterweise auch in FUP das:
> Anhang anzeigen 45170
> 
> ...



In Fup würde ich vermutlich eine Variable verwenden und diese mit einm zusätzlichen Pfad pro = anschliessen. Also die = untereinander aber mit einer Linie an nur eine Eingangsvariable angebunden.

Ich denke ausserdem, dass man nicht die FUP/KOP Programmierstile direkt nach SCL portieren sollte.
In Kop sehen Bitverknüpfung in einer Linie Horizontal ja noch gut und übersichtlich aus. Das ist aber in SCL IMHO nicht der fall, da schreibe ich lieber untereinander.

```
"TCHO.UVR.201.35_I8.0" :=
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.NG.Alarm" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_NG1.Alarm" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SPV.Stoe" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.QSK.1070.2070" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.QSK.1072.2072" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.QSK.710" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V_FS1070_2070" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1072_2072" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1076_2076" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1078_2078" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1080_2080" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.WS2552" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.WS2553" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1082_2082" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1084_2084" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1086_2086" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1088_2088" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.VA1560_2560" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1090_2090" OR
 "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.VA1562_25
```

Am liebsten wäre mir, der Editor würde das automatisch auch so einrücken

```
"TCHO.UVR.201.35_I8.0" :=   "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.NG.Alarm" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_NG1.Alarm" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SPV.Stoe" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.QSK.1070.2070" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.QSK.1072.2072" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.QSK.710" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V_FS1070_2070" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1072_2072" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1076_2076" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1078_2078" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1080_2080" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.WS2552" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.WS2553" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1082_2082" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1084_2084" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1086_2086" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1088_2088" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.VA1560_2560" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.FS1090_2090" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.VA1562_2562" OR
                             "GDB_HW_Datenpunkte"."TCHO.UVR.201.35_SiAut.230V.MS704_706";
```


----------



## PN/DP (8 April 2019)

Und wie machst Du es, wenn Du das Ergebnis der langen Verknüpfung mehrmals verwenden willst, z.B. an 8 verschiedene Variablen zuweisen möchtest?

Harald


----------



## vollmi (8 April 2019)

PN/DP schrieb:


> Und wie machst Du es, wenn Du das Ergebnis der langen Verknüpfung mehrmals verwenden willst, z.B. an 8 verschiedene Variablen zuweisen möchtest?



Dann gehe ich über eine Temp. manchmal überlege ich mir sogar einen sinnvollen Namen für diese Temporäre variable.
Aber oft habe ich genau für sowas eine dummy Temp in der Schnittstelle. Man muss dann halt nur aufpassen das man sie wirklich vor der Abfrage auch mit dem Ergebnis beschreibt das für diese Abfrage zählt.


----------



## Grimsey (8 Juli 2019)

Hallo zusammen,

ich habe wieder was gefunden, was mich stutzig werden lässt:

```
IF "gb".FU_DF.sts.msg_n_0 THEN
          #w_F_DF := - LINT_TO_REAL(1500);
ELSE
          #w_F_DF := - UINT_TO_REAL("gb".DF.w.F_abzi);
 END_IF;
```

Gibts eine Erklärung warum man bei der 1. Zuweisung von "w_F_DF" der Wert nochmal gewandelt wird??
Man hätte doch auch "w_F_DF := 1500.0;" schreiben können.


----------



## Heinileini (8 Juli 2019)

Grimsey schrieb:


> Man hätte doch auch "w_F_DF := 1500.0;" schreiben können.


Sicher, aber mit dem Vorzeichen wäre es noch besser/einfacher/lesbarer: w_F_DF := -1500.0;

Gruss, Heinileini


----------

