# WORD aus einzelnen Bits zusammensetzen



## moeins (20 November 2007)

Ich will mir einen FB bauen der als Eingang #Bit1...#Bit16 hat und möchte diese Bits zu einem #Ausgangswort zusammensetzen.  Die Position  der Bits in dem Wort soll variabel sein.
Irgendwie fehlt mir der Ansatz dazu, wie ich in dem #Ausgangswort die Bit gezielt platziere...?!?


----------



## Larry Laffer (20 November 2007)

...?
Was willst du genau machen ?
Eine Funktion, die als Ausgang (oder IN_OUT) ein WORD liefert, in dem du per Parameter ein Bit setzt, also in etwa so ?

```
FC xyz
  Bit_Nr :   [0 .. 15]
  Status :  [0 / 1]
  SetWORD :
```
schreib mal etwas mehr (genauer) dazu ...


----------



## moeins (20 November 2007)

Also dann will ich es nochmal kurz erklären. So in etwa :



> FC xyz
> Bit1: E0.1
> Bit2: M12.3
> Bit3: E6.2
> ...


Ich habe am FB/FC die Eingänge #Bit1, #Bit2, #Bit3, ...bis #Bit16.
An diese Eingänge werden Merker bzw. SPS-Eingänge angelegt. 
Diese 16 Bit sollen dann so zusammengesetzt werden das dadurch ein Wort entsteht, was ich dann in WinCC Flexible als Meldewort nutzen will.

Prinzipiell brauche ich nur Bit1-Bit16 so zusammensetzen das es mit Lowbyte und Highbyte passt und so in WinCC auch gleich mit Meldung 1 beginnt.

Ich möchte diese Funktion aber auch für andere Zwecke nutzen.

Mir fehlt jetzt nur der Ansatz das z.B. wenn #Bit1 =1 ist, diese in das #Ausgangswort an die entsprechende Stelle zu schreiben.
Wie kann ich auf die einzelnen Bits einer #symbolischen Variable zugreifen ?


----------



## vierlagig (20 November 2007)

in deinem FC hat das ausgangswort eine lokale adresse z.b. LW 6 ... bei diesem wort kannst du dann jedes bit einzeln anfassen z.b. L 6.2 oder L 7.5

....ich hör sie schon wieder aufschreien...


----------



## OHGN (20 November 2007)

vierlagig schrieb:


> ....ich hör sie schon wieder aufschreien...


Ich schrei nicht, ich mach das in kleinen in sich geschlossenen Funktionen auch so. 

```
U #Bit1
= L1.0
U #Bit2
= L1.1
....
....
U #Bit16
= L0.7
L LW0
T #Ausgangswort
```
Und jetzt können die ganzen Pointer-Vorschläge kommen.


----------



## Tetrade (20 November 2007)

Und hier dann ein Pointervorschlag  :

#######################################
FUNCTION "Bit->Word" : VOID
TITLE =Bit -> Word
VERSION : 0.1

VAR_INPUT
  BIT_01 : BOOL ; 
  BIT_02 : BOOL ; 
  BIT_03 : BOOL ; 
  BIT_04 : BOOL ; 
  BIT_05 : BOOL ; 
  BIT_06 : BOOL ; 
  BIT_07 : BOOL ; 
  BIT_08 : BOOL ; 
  BIT_09 : BOOL ; 
  BIT_10 : BOOL ; 
  BIT_11 : BOOL ; 
  BIT_12 : BOOL ; 
  BIT_13 : BOOL ; 
  BIT_14 : BOOL ; 
  BIT_15 : BOOL ; 
  BIT_16 : BOOL ; 
END_VAR
VAR_OUTPUT
  WORD_AUS : WORD ; 
END_VAR
VAR_TEMP
  temp_word : WORD ; 
END_VAR
BEGIN
NETWORK
TITLE =
      LAR1  P##temp_word; 
      U     #BIT_01; 
      =     L [AR1,P#1.0]; 
      U     #BIT_02; 
      =     L [AR1,P#1.1]; 
      U     #BIT_03; 
      =     L [AR1,P#1.2]; 
      U     #BIT_04; 
      =     L [AR1,P#1.3]; 
      U     #BIT_05; 
      =     L [AR1,P#1.4]; 
      U     #BIT_06; 
      =     L [AR1,P#1.5]; 
      U     #BIT_07; 
      =     L [AR1,P#1.6]; 
      U     #BIT_08; 
      =     L [AR1,P#1.7]; 
      U     #BIT_09; 
      =     L [AR1,P#0.0]; 
      U     #BIT_10; 
      =     L [AR1,P#0.1]; 
      U     #BIT_11; 
      =     L [AR1,P#0.2]; 
      U     #BIT_12; 
      =     L [AR1,P#0.3]; 
      U     #BIT_13; 
      =     L [AR1,P#0.4]; 
      U     #BIT_14; 
      =     L [AR1,P#0.5]; 
      U     #BIT_15; 
      =     L [AR1,P#0.6]; 
      U     #BIT_16; 
      =     L [AR1,P#0.7]; 
      L     #temp_word; 
      T     #WORD_AUS; 
END_FUNCTION
#######################################

Gruß André


----------



## kiestumpe (20 November 2007)

*Viele Wege führen nach Rom*

Und hier noch eine Variante in SCL, läßt sich übrigens leicht auf BYTEs oder DW's erweitern:

-------------------------------
FUNCTION FC326 : VOID


TITLE = 'BitsToWord'
//
// Funktion: 16 Bits werden einem Word zugeordnet.
//
VERSION : '1.0'

// Bausteinparameter
VAR_INPUT
  // Eingangsparameter
BIT_1    :    BOOL;
BIT_2    :    BOOL;
BIT_3    :    BOOL;
BIT_4    :    BOOL;
BIT_5    :    BOOL;
BIT_6    :    BOOL;
BIT_7    :    BOOL;
BIT_8    :    BOOL;
BIT_9    :    BOOL;
BIT_10    :    BOOL;
BIT_11    :    BOOL;
BIT_12    :    BOOL;
BIT_13    :    BOOL;
BIT_14    :    BOOL;
BIT_15    :    BOOL;
BIT_16    :    BOOL;


   END_VAR

VAR_IN_OUT
  // Durchgangsparameter
END_VAR

VAR_OUTPUT
    WORD_OUT : WORD;
END_VAR


VAR_TEMP
  // temporäre Variablen
    I : INT;
    WORD_TMP : WORD;
    BITS: ARRAY[1..16] OF BOOL;

END_VAR
BITS[1    ]:=    BIT_1    ;
BITS[2    ]:=    BIT_2    ;
BITS[3    ]:=    BIT_3    ;
BITS[4    ]:=    BIT_4    ;
BITS[5    ]:=    BIT_5    ;
BITS[6    ]:=    BIT_6    ;
BITS[7    ]:=    BIT_7    ;
BITS[8    ]:=    BIT_8    ;
BITS[9    ]:=    BIT_9    ;
BITS[10    ]:=    BIT_10    ;
BITS[11    ]:=    BIT_11    ;
BITS[12    ]:=    BIT_12    ;
BITS[13    ]:=    BIT_13    ;
BITS[14    ]:=    BIT_14    ;
BITS[15    ]:=    BIT_15    ;
BITS[16    ]:=    BIT_16    ;

  // Anweisungsteil
  WORD_TMP := B#16#0;
  FOR I := 0 TO 15  DO 
      WORD_TMP:=SHL(IN:=WORD_TMP,N:=1);    
      IF ((BITS[16-I]) = TRUE) THEN
        WORD_TMP := WORD_TMP OR B#16#01 ;

      ELSE
        WORD_TMP := WORD_TMP OR B#16#00 ;
      END_IF;
  END_FOR;
// *********************
//       Ausgabe  
// *********************
   WORD_OUT :=WORD_TMP;

END_FUNCTION


----------



## zotos (20 November 2007)

Mal auf die schnelle mit dem AT Operant in SCL:

```
FUNCTION FC25 : WORD

VAR_INPUT
  Bit_00  :BOOL;
  Bit_01  :BOOL;
  Bit_02  :BOOL;    
  Bit_03  :BOOL;
  Bit_04  :BOOL;
  Bit_05  :BOOL;
  Bit_06  :BOOL;    
  Bit_07  :BOOL;  
  Bit_08  :BOOL;
  Bit_09  :BOOL;
  Bit_10  :BOOL;    
  Bit_11  :BOOL;  
  Bit_12  :BOOL;
  Bit_13  :BOOL;
  Bit_14  :BOOL;    
  Bit_15  :BOOL;      
END_VAR

VAR_TEMP
  // temporäre Variablen
  myWord  :WORD;
  myArray AT myWord :ARRAY[0..15] OF BOOL; 
END_VAR

  // Anweisungsteil
  myArray[ 0] := Bit_00;
  myArray[ 1] := Bit_01;
  myArray[ 2] := Bit_02;
  myArray[ 3] := Bit_03;
  myArray[ 4] := Bit_04;
  myArray[ 5] := Bit_05;
  myArray[ 6] := Bit_06;
  myArray[ 7] := Bit_07;
  myArray[ 8] := Bit_08;
  myArray[ 9] := Bit_09;
  myArray[10] := Bit_10;
  myArray[11] := Bit_11;
  myArray[12] := Bit_12;
  myArray[13] := Bit_13;
  myArray[14] := Bit_14;
  myArray[15] := Bit_15;
  
  FC25 := ROL(IN:=myWord, N:=8); (* MSB und LSB Tauschen *)
END_FUNCTION
```


----------



## Larry Laffer (20 November 2007)

... und hier aus meinem Fundus zur Vervollständigung die SCL-Lösung für das, was ich oben weiter gefragt hatte ...
[gezielt ein Bit im WORD setzten / löschen]


```
FUNCTION FC424 : VOID              // UP Bit in WORD setzen
 
VAR_INPUT
   Bit_Nr : INT ;     // Bit-Nummer  [0..15] , -1 = alle
   Aktion : INT ;     // 0 = löschen , 1 = setzen
END_VAR
VAR_IN_OUT
   WORD_Var : WORD ;  // Variable, in der das Bit geändert werden soll   
END_VAR
VAR_OUTPUT
END_VAR
VAR_TEMP
   Shift_Var : WORD ;
   Shift_Anz : INT ;
   Maske_W   : WORD ; 
END_VAR
 
BEGIN
IF Bit_Nr >= 00 THEN
   Shift_Anz := 0 ;
      IF     Bit_Nr <= 07 THEN Shift_Anz := Bit_Nr + 8 ;
      ELSIF  Bit_Nr <= 15 THEN Shift_Anz := Bit_Nr - 8 ;
      END_IF ;
   Shift_Var := 1 ; 
   Maske_W := SHL (IN:=Shift_Var , N:=Shift_Anz) ;  // Maske bilden (1 Bit)
 
ELSIF Bit_Nr = -1 THEN 
   Maske_W := 16#FFFF ;                             // Maske bilden (alle Bits)
END_IF ; 
 
IF Aktion = 0 THEN  // Bit löschen
   Maske_W := Maske_W XOR 16#FFFF ;    // Maske invertieren
   WORD_Var := WORD_Var AND Maske_W ; 
ELSE                // Bit setzen
   WORD_Var := WORD_Var OR Maske_W ; 
END_IF ;
 
END_FUNCTION
```
 
Vielleicht hat ja auch jemand daran Spass ...


----------



## IBN-Service (20 November 2007)

vierlagig schrieb:


> in deinem FC hat das ausgangswort eine lokale adresse z.b. LW 6 ... bei diesem wort kannst du dann jedes bit einzeln anfassen z.b. L 6.2 oder L 7.5
> 
> ....ich hör sie schon wieder aufschreien...



Hallo vierlagig,

da möchte ich jetzt mal aufschreien...

Diese Lösung ist wirklich nicht empfehlenswert!  

Spätestens wenn du mal Lokalvariablen nachfügst, wird das im Chaos enden.

Viel besser ist es, du benutzt den *P## *- Befehl.

Damit kannst du symbolisch auf Bits im Wort zugreifen.

Ich glaub, Volker hat dazu einen Beitrag für die FAQ geschrieben,
alternantiv gibts auf meiner HP das Beispiel "Graycode", dass die Verwendung des P##
demonstriert.

Zu guter letzt kann man auch in der Not auf das gute alte Schmiermerkerwort zurück greifen...

CU

Jürgen


.


----------



## zotos (20 November 2007)

Ich wollte Dir ein Danke verpassen und 100% Ack. schreiben aber dann kam das Grauen:



IBN-Service schrieb:


> ...
> Zu guter letzt kann man auch in der Not auf das gute alte Schmiermerkerwort zurück greifen...
> ...



Bitte, bitte nicht! Schmiermerker gehören zu den schlimmsten Stolpersteine.


----------



## IBN-Service (20 November 2007)

zotos schrieb:


> Ich wollte Dir ein Danke verpassen und 100% Ack. schreiben aber dann kam das Grauen:
> 
> Bitte, bitte nicht! Schmiermerker gehören zu den schlimmsten Stolpersteine.



Hallo Zotos,

daran erkennt man, dass du noch Jung bist und kein S5 kennst!  
In der S5 - Welt sind Schmiermerker zwingend notwendig,
auch in den Siemens - Bausteinen werden diese verwendet.

Ich schrieb ja extra _*in der Not*_, und dann frisst ja der Teufel bekanntlich sogar Fliegen...

Wenn man ein Schmiermerkerwort einsetzt und in der Symbolliste ordentlich dokumentiert,
ist es m.E. nicht verboten. Aber auch nicht schön, ganz klar.


CU

Jürgen


.


----------



## vierlagig (20 November 2007)

es ging um *einen* baustein, der aus *16 bits* *ein word* baut, kann mir nicht vorstellen, wie bei einer solchen standardfunktion jemand noch andere lokale variablen hinzufügen möchte ... *pissigwird*


----------



## zotos (20 November 2007)

Schmiermerker haben bei Step7 ihre Existenzberechtigung verloren.
Wer diese ernsthaft einsetzt ist einfach geistig bei der S5 stehen geblieben und hat sich für den falschen Beruf entschieden.

@IBN-Service: Danke für die Verbesserung!


			
				IBN-Service schrieb:
			
		

> *Da ist aber einer aus dem Konzept geraten, was?*
> "Wer das ernst haft einsetzt ist einfach Geistig bei der S5 stehen geblieben und hat sich für den falschen Beruf entschieden."
> 
> ernsthaft ist EIN Wort,
> ...


----------



## IBN-Service (20 November 2007)

zotos schrieb:


> @IBN-Service: Danke für die Verbesserung!




Hallo Zotos,

gern geschehen.


----------



## vierlagig (20 November 2007)

IBN-Service schrieb:


> Hallo Hakle feucht



:s12: ... tausend mal gehört und schon lange nimma drüber nachgedacht...


----------



## Onkel Dagobert (20 November 2007)

vierlagig schrieb:


> in deinem FC hat das ausgangswort eine lokale adresse z.b. LW 6 ... bei diesem wort kannst du dann jedes bit einzeln anfassen z.b. L 6.2 oder L 7.5..


Was zu beweisen wäre  !


Gruß, Onkel


----------



## vierlagig (20 November 2007)

Onkel Dagobert schrieb:


> Was zu beweisen wäre  !



kann dir nich folgen...was ist daran nicht klar?


----------



## Onkel Dagobert (20 November 2007)

Das Ausgangswort liegt nicht in den Lokaldaten der FC. Auf die Ein- und Ausgänge eine Funktion kann man nicht mittels absoluter Adressierung zugreifen, behaupte ich jetzt mal.


Gruß, Onkel


----------



## vierlagig (20 November 2007)

Onkel Dagobert schrieb:


> Das Ausgangswort liegt nicht in den Lokaldaten der FC. Auf die Ein- und Ausgänge eine Funktion kann man nicht mittels absoluter Adressierung zugreifen, behaupte ich jetzt mal.



ich behaupte: man kann! ... rechtsklick auf entsprechende variable -> objekteigenschaften und lokale adresse ablesen -> fertig


----------



## Onkel Dagobert (20 November 2007)

Die Adressen der Ein- und Ausgänge von Funktionen liegen in den Lokaldaten des aufrufenden Bausteins (V-Bereich). Was du meinst, ist nichts anderes als ein unnützer Zähler aber keine wirkliche Adresse. Wenn du mal einen Pointer auf eine solche Variable setzt, zeigt er dir die Adresse. Sie ist bei jedem Aufruf einer Funktion eine andere, bzw. sie abhängig vom jeweiligen Aktualparameter. Man kann nur indirekt oder symbolisch darauf zugreifen.


```
L P##Bit_00
LAR1 // AR1 = z.Bsp. V 29.2
```
 

Gruß, Onkel


----------



## vierlagig (20 November 2007)

...aber es funktioniert...


----------



## Onkel Dagobert (20 November 2007)

...Dann zeig mal her! Sonst kann ich heute nicht schlafen....


----------



## vierlagig (20 November 2007)

wär ich doch nur noch im büro ... 

wenn ich aber eine funktion "bit_to_word" schreibe und diese like



> U #in_bit0
> = L2.0
> U #in_bit1
> = L2.1
> ...



ausführe, wobei ich 16 in-variablen (bool) von L0.0 bis L1.7 und eine out-variable (word) mit anfangsadresse L2.0 habe, funktioniert das!


----------



## Onkel Dagobert (20 November 2007)

Irrtum. Du schreibst auf jeden Fall in die temporären Lokaldaten. Erst wenn du anschliessend mit...


```
L     LW2
T    OutWord
```
...die Lokaldaten an den Ausgang übergibst, wird es funktionieren. Siehe auch Beitrag Nr.5 von OHGN.


Gruß, Onkel


----------



## vierlagig (20 November 2007)

i´ll try ... morgen ... hoffe du kannst trotzdem gut schlafen ...


----------



## Onkel Dagobert (20 November 2007)

Ja, danke! Gute Nacht!

Gruß, Onkel


----------



## Kai (21 November 2007)

Onkel Dagobert schrieb:


> Irrtum. Du schreibst auf jeden Fall in die temporären Lokaldaten. Erst wenn du anschliessend mit...
> 
> 
> ```
> ...


 
Onkel Dagobert hat Recht.

Gruß Kai


----------



## Kai (21 November 2007)

Hier noch mal ein Lösungsvorschlag mit Pointern:


```
FUNCTION "FC_BOOL_WORD_PT" : VOID
TITLE =BOOL => WORD
AUTHOR : KAI
FAMILY : SPSFORUM
NAME : LOKALDAT
VERSION : 1.0
 
VAR_INPUT
  IN_BIT_00 : BOOL ;    
  IN_BIT_01 : BOOL ;    
  IN_BIT_02 : BOOL ;    
  IN_BIT_03 : BOOL ;    
  IN_BIT_04 : BOOL ;    
  IN_BIT_05 : BOOL ;    
  IN_BIT_06 : BOOL ;    
  IN_BIT_07 : BOOL ;    
  IN_BIT_08 : BOOL ;    
  IN_BIT_09 : BOOL ;    
  IN_BIT_10 : BOOL ;    
  IN_BIT_11 : BOOL ;    
  IN_BIT_12 : BOOL ;    
  IN_BIT_13 : BOOL ;    
  IN_BIT_14 : BOOL ;    
  IN_BIT_15 : BOOL ;    
END_VAR
VAR_OUTPUT
  OUT_WORD : WORD ; 
END_VAR
BEGIN
NETWORK
TITLE =IN_BIT_00 - IN_BIT_15 (BOOL) => OUT_WORD (WORD)
 
      L     P##IN_BIT_00; 
      LAR1  ; 
 
      L     W [AR1,P#0.0]; 
      TAW   ; 
      T     #OUT_WORD; 
 
END_FUNCTION
```
 
Gruß Kai


----------



## vierlagig (21 November 2007)

ohkai kai und auch onkel ... man muss am ende einen transfer durchführen - ihr habt recht!  ...wieder was gelernt...


----------



## Onkel Dagobert (21 November 2007)

Hallo,

was stimmt denn an Kai's Lösung nicht?


Gruß, Onkel


----------



## Perfektionist (21 November 2007)

da gehts schon los ...:twisted:


----------



## vierlagig (21 November 2007)

Onkel Dagobert schrieb:


> was stimmt denn an Kai's Lösung nicht?



hab sie mir nicht angeguckt und deswegen auch nicht behauptet, sie würde nicht stimmen  ... meinst du das "ohkai"? ist eine phonetische abwandlung von ok


----------



## Larry Laffer (21 November 2007)

Perfektionist schrieb:


> da gehts schon los ...:twisted:


 
Sehe ich genau so ...
Das Thema ist doch hinreichend beantwortet und ob man es über Pointer oder Lokaldaten oder sonstwie machen möchte liegt doch an jedem selbst.
In diesem Fall ging es, glaube ich, um eine eigenständige Funktion, die sich nur selbst "verschmickeln" kann.


----------



## zotos (21 November 2007)

Larry Laffer schrieb:


> ...
> Das Thema ist doch hinreichend beantwortet und ob man es über Pointer oder Lokaldaten oder sonstwie machen möchte liegt doch an jedem selbst.
> ...



Also ich bin ja kein Freund vom direkten (->nicht symbolischen) Zugriff auf Lokale Daten. Aber bitte lass sich keiner dazu verleiten in einer geschlossenen Funktion einen globalen Merker als Schmiermerker zu missbrauchen. In AWL ist Kais Lösung sicher die eleganteste. @Kai: die PDFs waren IMHO allerdings mal wieder unnötig. Alles Wichtige steht doch schon zwischen den Code Tags.


----------



## Perfektionist (21 November 2007)

zotos schrieb:


> Also ich bin ja kein Freund vom direkten (->nicht symbolischen) Zugriff auf Lokale Daten. Aber bitte lass sich keiner dazu verleiten in einer geschlossenen Funktion einen globalen Merker als Schmiermerker zu missbrauchen.
> ...


100% ACK

Bei mir steht zu Beginn eines Bausteins drin, wie dirty der geschrieben ist. Dort schreibe ich dann Achtung ...
-Querzugriffe
-benutzt Globalvariablen
-greift absolut auf Lokal-/Instanzdaten zu.

Aber das entscheide ich dann in dem Moment, wo ich das mache, wie schmutzig es in dem Moment sein darf. Viel Achtung wird man mir dafür nicht entgegenbringen, dass ich weiß, das es nicht nur sauber, sondern auch rein geht:???: 

Aber bei Inbetriebnahme, wenn man dann eine Anlage nicht wegen einer Instanzänderung abstellen will, bleibt manchmal keine ander Wahl.


----------



## vierlagig (21 November 2007)

*erlaubt ist was gefällt!* und funktioniert!

...diese ganze lokaldaten-diskussion kommt alle wochen wieder und langsam wirds langweilig...


----------



## IBN-Service (21 November 2007)

zotos schrieb:


> AIn AWL ist Kais Lösung sicher die eleganteste. @Kai: die PDFs waren IMHO allerdings mal wieder unnötig. Alles Wichtige steht doch schon zwischen den Code Tags.



Hallo Zotos,

Recht hast du, Kais Lösung (mit dem von mir vorgeschlagenen P##)  ist die eleganteste Lösung.

Unrecht hast du mit den PDF.
Ich finds ungeheuer praktisch, weil ich da den Baustein schnell 
angenehm lesbar formatiert vor mir sehe.

@Kai: Weiter so.


----------



## IBN-Service (21 November 2007)

Perfektionist schrieb:


> Aber bei Inbetriebnahme, wenn man dann eine Anlage nicht wegen einer Instanzänderung abstellen will, bleibt manchmal keine ander Wahl.



Hallo Andreas,

da sieht man, dass du mit Maschinen nicht nur theoretisch umgehst,
sondern auch ein Mann der Praxis bist.

Das würde einigen "Aristokraten" hier auch mal guttun....  

_In den Not findet nun mal so manches statt, was sonst nicht stattgefunden hat.
(Wilhelm Busch)_



CU

Jürgen


.


----------



## Perfektionist (21 November 2007)

IBN-Service schrieb:


> ...da sieht man, dass du mit Maschinen nicht nur theoretisch umgehst,
> sondern auch ein Mann der Praxis bist.
> ...


 
Danke
*auf zehn Zeichen erweiter*


----------



## Larry Laffer (21 November 2007)

zotos schrieb:


> ... In AWL ist Kais Lösung sicher die eleganteste ...


Dazu 100% Ack ...

Leider habe ich ein paar Stunden "verschlafen" ...

@Zotos:
Ich gebe dir mit deiner Argumentation grundsätzlich recht - vor allem in dem Punkt mit dem Programmierstil. Trotz alle dem hat auch jeder der Anderen Recht. Das wollte ich mit meinem Beitrag ausdrücken.
- So nebenher ... dein Vorschlag war auch nicht schlecht ... (weihräucher ... lobhudel ... )


----------



## Perfektionist (21 November 2007)

Ich knobel grad dran, ob man nicht auch mit der Rotieroperation das Statusbit A1 Stück für Stück in den Akku reinschieben kann. Aber das scheitert wohl daran, dass es keinen vernünftigen Weg gibt, in das A1 ohne Umstände die binären Werten zu schreiben


----------



## Onkel Dagobert (21 November 2007)

Hallo vierlagig,



vierlagig schrieb:


> hab sie mir nicht angeguckt und deswegen auch nicht behauptet, sie würde nicht stimmen  ... meinst du das "ohkai"? ist eine phonetische abwandlung von ok


Nein, meine Frage war durchaus ernst gemeint.


Gruß, Onkel


----------



## vierlagig (21 November 2007)

Onkel Dagobert schrieb:


> Hallo vierlagig,
> Nein, meine Frage war durchaus ernst gemeint.



 ...was meinst du?


----------



## Onkel Dagobert (21 November 2007)

Ich möchte ganz einfach mal wissen, ob jemandem auffällt was an dem Vorschlag von Kai nicht stimmt. Ich kann in dieser Runde doch nicht der einzige sein, dem das sofort ins Auge sticht? Ich meine nicht solche "Kleinigkeiten" wie das Sichern und Wiederherstellen des AR1. Nichts gegen Kai, er kann das mit Sicherheit besser. Nur hat er hier wohl nicht genügend nachdgedacht, passiert mir auch oft. Es ist schon toll, was man alles für Fehler machen kann, um ein paar Bits in ein Wort zu schreiben.


Gruß, Onkel


----------



## IBN-Service (21 November 2007)

Onkel Dagobert schrieb:


> Ich möchte ganz einfach mal wissen, ob jemandem auffällt was an dem Vorschlag von Kai nicht stimmt. Ich kann in dieser Runde doch nicht der einzige sein, dem das sofort ins Auge sticht? Ich meine nicht solche "Kleinigkeiten" wie das Sichern und Wiederherstellen des AR1. Nichts gegen Kai, er kann das mit Sicherheit besser. Nur hat er hier wohl nicht genügend nachdgedacht, passiert mir auch oft. Es ist schon toll, was man alles für Fehler machen kann, um ein paar Bits in ein Wort zu schreiben.
> 
> 
> Gruß, Onkel



Hallo Onkel,

jetzt frag ich aber auch mal,
was meinst du?


Bitte lass uns nicht dumm sterben!

CU

Jürgen

.


----------



## Onkel Dagobert (21 November 2007)

Hallo Jürgen,



IBN-Service schrieb:


> ..Das AR1 wird nach FC - Return wieder mit dem Inhalt vor Aufruf geladen, dass macht das BS..


Also, mein BS macht das nicht, aber darum geht es mir ja auch garnicht.

Nur soviel, es handelt sich um eine Funktion (FC). Dass die Ein- und Ausgangsparameter nicht in den Lokaldaten liegen, habt ihr mir ja hoffentlich schon mal abgekauft. Weiterhin sollten die 16 Eingänge nicht im selben Operandenbereich, und schon garnicht in geordneter Reihenfolge vorliegen müssen, sonst wäre die Funktion überflüssig. Jetzt sollte es schon etwas klarer werden?

Wer die Möglichkeit hat, sollte sich mal den Code vornehmen und sich beim simulieren wundern  . Vielleicht auch vor und nach dem Bausteinaufruf den Inhalt des AR1 ansehen?


Gruß, Onkel


----------



## marlob (21 November 2007)

IBN-Service schrieb:


> Das AR1 wird nach FC - Return wieder mit dem Inhalt vor Aufruf geladen,
> dass macht das BS.
> Probleme gibts m.E. nur beim _AR2 bei Multiinstanzen_...
> .



Aus der Siemens FAQ (mehr Infos unter Beitrags-Id 14628680)


> Die Verwendung der folgenden höheren Sprachkonstrukte kann dazu führen, dass die Inhalte von *DB-Register* und Adressregister *AR1* verändert werden:
> vollqualifizierter DB-Zugriff (z.B. DB20.DBW10) als Aktualparameter für FC's
> FB- und Multiinstanz-CALL
> Strukturkomponente eines Formalparameters als Operand innerhalb eines FC's oder FB's
> Strukturkomponente eines Formalparameters als Aktualparameter für FC oder FB


----------



## no-strada-mus (21 November 2007)

aus dem Vorschlag von Kai:

L     P##in_bit_00; 
      Lar1  ;    ...Was steht jetzt im AR1 ???

      L     W [ar1,p#0.0];    ...und wo greift der dann hin ???


also ich denke, da es sich um eine FC handelt, ist #in_bit_00 direkt mit dem beim Aufruf zugewiesenen Aktualparameter verknüpft. 

Wenn #in_bit_00 z.B. mit E2.0 als Aktualparameter belegt wird, dann müsste mit  L     W [ar1,p#0.0] das EW2 geladen werden.
Wird #in_bit_00 z.B. mit E2.1 belegt, müsste es Probleme geben, da für den Ladebefehl die Bitadresse<>0 ist.

Würden Kais Befehle in einem FB ausgeführt, dann würde nach den Befehlen 
L     P##in_bit_00; 
      Lar1  ;
im Adressregister die Adresse von #in_bit_00 im Instanzdatenbereich stehen.

Soweit meine Theorie.

Hat es ausser Onkel noch jemand probiert ?


----------



## Kai (21 November 2007)

Ich bin gerade am Ausprobieren. So wie ich das im Augenblick sehe, müssen in der Funktion das DB-Register und das Adressregister AR1 am Anfang gesichert und am Ende wiederhergestellt werden.

Gruß Kai


----------



## zotos (21 November 2007)

Also bei mir geht die Lösung von Kai auch wenn ich die Eingänge durcheinander würfele. Also Bit_00 := E0.1 und Bit_01 := E0.0 geht bei mir.


----------



## Onkel Dagobert (21 November 2007)

Hallo moeins,



moeins schrieb:


> Ich will mir einen FB bauen..


Dich hätten wir ja fast vergessen. Du hast es sicherich schon so umgesetzt wie OHGN es im fünften Beitrag beschrieben hat! In solch kleinen, überschaubaren Funktionen hat die absolute Adressierung der Lokaldaten durchaus eine Berechtigung.

@Jürgen
Schlaf gut! Auch ich hatte bei Inbetriebnahmen noch nie lange Weile. 


Gruß, Onkel


----------



## Kai (21 November 2007)

Kai schrieb:


> Ich bin gerade am Ausprobieren. So wie ich das im Augenblick sehe, müssen in der Funktion das DB-Register und das Adressregister AR1 am Anfang gesichert und am Ende wiederhergestellt werden.


 
Meine Funktion FC100 arbeitet auch ohne Sicherung und Wiederherstellung des DB-Registers und des Adressregisters AR1 richtig:

http://www.sps-forum.de/showpost.php?p=107371&postcount=30

Gruß Kai


----------



## Kai (21 November 2007)

Der Vollständigkeit halber hier noch einmal die Funktion FC100 mit der Sicherung und Wiederherstellung des DB-Registers und des Adressregisters AR1:


```
FUNCTION "FC_BOOL_WORD_PT" : VOID
TITLE =BOOL => WORD
AUTHOR : KAI
FAMILY : SPSFORUM
NAME : LOKALDAT
VERSION : 1.0
 
VAR_INPUT
  IN_BIT_00 : BOOL ;    
  IN_BIT_01 : BOOL ;    
  IN_BIT_02 : BOOL ;    
  IN_BIT_03 : BOOL ;    
  IN_BIT_04 : BOOL ;    
  IN_BIT_05 : BOOL ;    
  IN_BIT_06 : BOOL ;    
  IN_BIT_07 : BOOL ;    
  IN_BIT_08 : BOOL ;    
  IN_BIT_09 : BOOL ;    
  IN_BIT_10 : BOOL ;    
  IN_BIT_11 : BOOL ;    
  IN_BIT_12 : BOOL ;    
  IN_BIT_13 : BOOL ;    
  IN_BIT_14 : BOOL ;    
  IN_BIT_15 : BOOL ;    
END_VAR
VAR_OUTPUT
  OUT_WORD : WORD ; 
END_VAR
VAR_TEMP
  TEMP_DB : WORD ;  
  TEMP_AR1 : DWORD ;    
END_VAR
BEGIN
NETWORK
TITLE =DB-Register und Adressregister AR1 sichern
 
      L     DBNO; 
      T     #TEMP_DB; 
 
      TAR1  #TEMP_AR1; 
 
NETWORK
TITLE =IN_BIT_00 - IN_BIT_15 (BOOL) => OUT_WORD (WORD)
 
      L     P##IN_BIT_00; 
      LAR1  ; 
 
      L     W [AR1,P#0.0]; 
      TAW   ; 
      T     #OUT_WORD; 
 
NETWORK
TITLE =DB-Register und Adressregister AR1 wiederherstellen
 
      AUF   DB [#TEMP_DB]; 
 
      LAR1  #TEMP_AR1; 
 
END_FUNCTION
```
 
Gruß Kai


----------



## IBN-Service (21 November 2007)

*Wer bezahlt mich eigendlich für die Nachhilfestunden hier ?*



Kai schrieb:


> Meine Funktion FC100 arbeitet auch ohne Sicherung und Wiederherstellung des DB-Registers und des Adressregisters AR1 richtig:
> 
> http://www.sps-forum.de/showpost.php?p=107371&postcount=30
> 
> Gruß Kai



@Kai:
Klar, dein FC funktioniert und du *musst *auch *nicht *zwingend AR1 / DBreg. retten.

Ein erfahrener Programmierer weis, dass er mit offenem AR-Registern über Bausteingrenzen hinweg eben vorsichtig
umgehen muss.

Das DB1 - Register wird eh beim nächsten vollquallifizierten Zugriff wieder beschrieben,
also drohen auch da keine Probleme.

Das einzigste Argument, dass für das Retten / Laden der Register spricht, ist ein unsynchroner Aufruf 
der FC, z.B. in einem Alarm - OB.

*IMHO hast du alles richtig gemacht.*




zotos schrieb:


> Also bei mir geht die Lösung von Kai auch wenn ich die Eingänge durcheinander würfele. Also Bit_00 := E0.1 und Bit_01 := E0.0 geht bei mir.



Zotos,
das ist ganz klar, da der P## nicht die Adresse des _Operanden _sondern die Anfangsadresse des _Parameters _lädt,
 das ist ja der Witz des P## - Befehls.
OK, das ist schon etwas komplex, S7 - Neulinge wie du sollten vielleicht doch erst noch mit Schmiermerkerwörtern arbeiten...





Onkel Dagobert schrieb:


> @Jürgen
> Schlaf gut! Auch ich hatte bei Inbetriebnahmen noch nie lange Weile.
> 
> Gruß, Onkel



Hallo Onkel, 
ja, danke auch.

Ich glaub, wenn bei dir mal Langeweile aufzukommen droht, dann mischst du hier das Jungvolk auf, was?    


CU

Jürgen

.


----------



## Kai (22 November 2007)

Onkel Dagobert schrieb:


> Ich möchte ganz einfach mal wissen, ob jemandem auffällt was an dem Vorschlag von Kai nicht stimmt. Ich kann in dieser Runde doch nicht der einzige sein, dem das sofort ins Auge sticht? Ich meine nicht solche "Kleinigkeiten" wie das Sichern und Wiederherstellen des AR1.


 


Onkel Dagobert schrieb:


> Nur soviel, es handelt sich um eine Funktion (FC). Dass die Ein- und Ausgangsparameter nicht in den Lokaldaten liegen, habt ihr mir ja hoffentlich schon mal abgekauft. Weiterhin sollten die 16 Eingänge nicht im selben Operandenbereich, und schon garnicht in geordneter Reihenfolge vorliegen müssen, sonst wäre die Funktion überflüssig. Jetzt sollte es schon etwas klarer werden?


 
Ich glaube, ich verstehe langsam, worauf Onkel Dagobert hinaus will. Zumindest habe ich folgendes Problem gefunden:

Die Funktion FC100 habe ich im OB1 einmal in der FUP-Ansicht im Netzwerk 1 und einmal in der AWL-Ansicht im Netzwerk 2 eingefügt.

Wenn man sich den OB1 nun einmal in der FUP-Ansicht und einmal in der AWL-Ansicht ansieht, kann man einen interessanten Unterschied zwischen den beiden Bausteinen sehen:

Im Netzwerk 1 werden die Eingänge zunächst in Lokaldaten kopiert und mit diesen Lokaldaten wird dann der FC100 beschaltet.

Im Netzwerk 2 wird der FC100 direkt mit den Eingängen beschaltet.

Dieses hat nun zur Folge, dass der FC100 im Netzwerk 1 richtig funktioniert, der FC100 im Netzwerk 2 aber nicht.

Gruß Kai


----------



## Kai (22 November 2007)

Hier noch ein paar Bilder aus der Simulation mit PLCSIM:

*Netzwerk 1:*

FC100 - OUT_WORD = DB100.DBW2

Die Eingänge des FC100 werden richtig im DB100.DBW2 gespeichert.

*Netzwerk 2:*

FC100 - OUT_WORD = DB100.DBW4

Die Eingänge des FC100 werden falsch oder gar nicht im DB100.DBW4 gespeichert. 

Gruß Kai


----------



## Kai (22 November 2007)

*OB1 - Netzwerk 1:*

Der FC100 im Netzwerk 1 arbeitet richtig, weil die Eingänge zunächst in Lokaldaten ab L20.0 kopiert werden und der FC100 dann mit diesen Lokaldaten beschaltet wird. Es wird dann das LW20 als Ausgang OUT_WORD ausgegeben.


```
FC100:
 
      L     P##IN_BIT_00                // Zeiger auf L20.0
      LAR1  
 
      L     W [AR1,P#0.0]               // LW20
      TAW   
      T     #OUT_WORD                   // LW20
```
 
*OB1 - Netzwerk 2:*

Der FC100 im Netzwerk 2 arbeitet falsch. Es wird statt den Eingängen das EW100 als Ausgang OUT_WORD ausgeben.


```
FC100:
 
      L     P##IN_BIT_00                // Zeiger auf E100.0
      LAR1  
 
      L     W [AR1,P#0.0]               // EW100
      TAW   
      T     #OUT_WORD                   // EW100
```
 
Gruß Kai


----------



## marlob (22 November 2007)

IBN-Service schrieb:


> @Kai:
> Klar, dein FC funktioniert und du *musst *auch *nicht *zwingend AR1 / DBreg. retten.


In welchen Fällen das Adressregister geändert wird habe ich ja schon hier geschrieben



IBN-Service schrieb:


> Ein erfahrener Programmierer weis, dass er mit offenem AR-Registern über Bausteingrenzen hinweg eben vorsichtig
> umgehen muss.


Was spricht dagegen, in einem FC/FB indem ich die Adressregister usw. benutze, diese grundsätzlich zu sichern und zurück zu laden. Dann bin ich immer auf der sicheren Seite. Soviel extra code ist das ja schliesslich auch nicht und ich muss mir keine Gedanken machen, ob was schiefgehen kann 



IBN-Service schrieb:


> Das einzigste Argument, dass für das Retten / Laden der Register spricht, ist ein unsynchroner Aufruf
> der FC, z.B. in einem Alarm - OB.


Wird das Programm durch einen OB unterbrochen, dann werden vom Betriebssystem automatisch die aktuellen Inhalte der Akkumulatoren und
Adressregister sowie die Nummer und die Größe der geöffneten Datenbausteine im U-Stack gesichert. Beim Rücksprung in den aufrufenden Baustein werden diese wieder zurück geladen. Wenn du in deinem OB also nur den FC aufrufst, gibt es keine Probleme 
Weitere Infos hierzu Beitrags-ID 14845057


----------



## kiestumpe (22 November 2007)

Kai schrieb:


> Im Netzwerk 1 werden die Eingänge zunächst in Lokaldaten kopiert und mit diesen Lokaldaten wird dann der FC100 beschaltet.
> 
> Im Netzwerk 2 wird der FC100 direkt mit den Eingängen beschaltet.
> 
> ...


 
Da sind wir auch wieder bei einem Thema, was mich vor etlichen Wochen auch sehr verwundert hat - nämlich das Step 7 beim call-Aufruf die IN-Variablen wie IN-OUT behandelt (also quasi called-by-reference), beim FUP/KOP Aufruf jedoch "by value". Hatte damals auch mit dem support telefoniert, der mir dann nochmals bestätigt hat, das dies so volle Absicht sei (  )
Hat nun der Programmierer "sauber programmiert" und von Haus aus nicht auf IN-Variablen geschrieben, spielt das de Facto keine Rolle. Muss man jedoch was Laufendes ändern, so muss man schon genau hinschauen, was da vor sich geht.


----------



## IBN-Service (22 November 2007)

marlob schrieb:


> Was spricht dagegen, in einem FC/FB indem ich die Adressregister usw. benutze, diese grundsätzlich zu sichern und zurück zu laden. Dann bin ich immer auf der sicheren Seite. Soviel extra code ist das ja schliesslich auch nicht und ich muss mir keine Gedanken machen, ob was schiefgehen kann



Hallo marlob,

es spricht nichts dagegen,
aber es ist auch kein FEHLER, es nicht zu machen, m.E.

*Was kiestumpe sagt, bringt eigendlich die Sache auf den Punkt.*
Wie gesagt (Hallo Zotos   ), man muss halt wissen, wie die Lokalvariablen im I/O Bereich der Funktion funktionieren.




marlob schrieb:


> Wird das Programm durch einen OB unterbrochen, dann werden vom Betriebssystem automatisch die aktuellen Inhalte der Akkumulatoren und
> Adressregister sowie die Nummer und die Größe der geöffneten Datenbausteine im U-Stack gesichert. Beim Rücksprung in den aufrufenden Baustein werden diese wieder zurück geladen. Wenn du in deinem OB also nur den FC aufrufst, gibt es keine Probleme
> Weitere Infos hierzu Beitrags-ID 14845057



Das ist Richtig und wieder nicht richtig... 
Z.B. kann bei Multiinstanz - FB Aufrufen das _AR2 _so verbogen werden, 
dass es NICHT wieder herstellbar ist.

Bitte entschuldige, dass ich den entsprechenden FAQ - Link nicht parat habe, 
ich werde ihn ggf. Nachreichen.

CU

Jürgen

.


----------



## marlob (22 November 2007)

IBN-Service schrieb:


> es spricht nichts dagegen,
> aber es ist auch kein FEHLER, es nicht zu machen, m.E.


In diesem Fall (Beispiel von Kai wird es wohl nicht nötig sein.) 
Aber man weiss nie, was andere Programmierer da später noch mit einbauen und was dann alles passieren kann.
Da hab ich schon die dollsten Sachen gesehen :???:



IBN-Service schrieb:


> Das ist Richtig und wieder nicht richtig...
> Z.B. kann bei Multiinstanz - FB Aufrufen das _AR2 _so verbogen werden,
> dass es NICHT wieder herstellbar ist.


Ich habe mich in meiner Aussage auf den FC bezogen, den du ja auch explizit angesprochen hast.
Also ist es richtig! 
Was den FB in diesem Fall betrifft, muss ich selber nachgucken



IBN-Service schrieb:


> Bitte entschuldige, dass ich den entsprechenden FAQ - Link nicht parat habe,
> ich werde ihn ggf. Nachreichen.


Auf jeden Fall, das interessiert mich schon


----------



## IBN-Service (22 November 2007)

marlob schrieb:


> Auf jeden Fall, das interessiert mich schon



Hallo marlob,

habe leider nicht gefunden, was ich gesucht habe... :???: 

Ggf. heute Abend mehr...

CU

Jürgen

.


----------



## moeins (22 November 2007)

Onkel Dagobert schrieb:


> Hallo moeins,
> 
> Dich hätten wir ja fast vergessen. Du hast es sicherich schon so umgesetzt wie OHGN es im fünften Beitrag beschrieben hat! In solch kleinen, überschaubaren Funktionen hat die absolute Adressierung der Lokaldaten durchaus eine Berechtigung.


Schön das wenigsten einer an mich denkt 

Ich habe die erste Variante genommen, bei der zweiten Variante mit dem Pointer bin ich mir nicht sicher ob es auch den Zweck erfüllt den ich möchte. Zu meiner Schande muß ich sagen das ich es nicht ausprobiert habe.

Wird denn bei der Pointervariante  Highbyte und Lowbyte vertauscht, so das ich mit der WinCC-Flexible Bitmeldung konform bin  ?

Mein FC sieht von der Aussenbeschaltung so aus :

Meldung 1 -IN
Meldung 2 -IN
Meldung 3 -IN
...
Meldung 16 -IN

OUT -Meldewort


WinCC Flexible nimmt ja für Meldung 1 aus dem Meldewort das erste Bit aus dem Lowbyte. Also so : 00000001 00000000 (Meldung 1 =1)

?!?


----------



## Kai (22 November 2007)

moeins schrieb:


> Wird denn bei der Pointervariante Highbyte und Lowbyte vertauscht, so das ich mit der WinCC-Flexible Bitmeldung konform bin


 
Falls Du mit der Pointervariante den Programmcode hier meinst:

http://www.sps-forum.de/showpost.php?p=107223&postcount=6

Ja, es werden dort das Highbyte und das Lowbyte vertauscht.

Gruß Kai


----------



## moeins (22 November 2007)

Nein, ich meinte eigentlich diese Variante :



Kai schrieb:


> Hier noch mal ein Lösungsvorschlag mit Pointern:
> 
> 
> ```
> ...


----------



## Kai (22 November 2007)

Auch in meiner Funktion FC100 werden das Highbyte und das Lowbyte vertauscht. Das macht der Befehl TAW.



> *TAW*
> 
> AW kehrt die Reihenfolge der Bytes in AKKU1-L um. Das Ergebnis wird in AKKU1-L gespeichert.


 
Wenn Du meine Funktion FC100 verwendest, dann musst du aber den folgenden Beitrag beachten:

http://www.sps-forum.de/showpost.php?p=107587&postcount=64

Den Aufruf des FC100 musst Du in der FUP-Ansicht in Dein Programm einfügen. 

Der Aufruf des FC100 muss in Deinem Programm dann so aussehen wie der Aufruf des FC100 in dem Netzwerk 1 in den PDF-Files OB1-FUP.PDF und OB1-AWL.PDF. 

Nur dann funktioniert der FC100 richtig.

Gruß Kai


----------



## OHGN (22 November 2007)

moeins schrieb:


> WinCC Flexible nimmt ja für Meldung 1 aus dem Meldewort das erste Bit aus dem Lowbyte. Also so : 00000001 00000000 (Meldung 1 =1)


Was Du hier beschreibst ist aber das erste Bit aus dem High-Byte (also Meldung 9).
Für die erste Meldung ist also richtig: 00000000 00000001

@marlob: Verstehst Du jetzt was ich mit dem "Märchen_der_vertauschten_Bytes" meinte?


----------



## marlob (22 November 2007)

OHGN schrieb:


> @marlob: Verstehst Du jetzt was ich mit dem "Märchen_der_vertauschten_Bytes" meinte?


@OHGN
Da du das Thema unbedingt wieder ansprechen musstest, habe ich hier doch noch mal drauf geantwortet


----------



## Perfektionist (22 November 2007)

ja, ja, das Märchen mit den vertauschten Bytes ...

Selbstverständlich ist es mir auch schon passiert, dass ich die Fehlermeldungen verkehrt zugeordnet habe (ist aber jetzt schon eine Weile her). Aber es ist nicht selbstverständlich einzusehen, wie man Bytes in einem linear geordneten Speicher in Words und Doubles organisiert. Ich kenn da auch einen (meinen Chef, nicht hier im Forum), der gebetsmühlenartig sagt: "Aber in der Speicherzelle mit der höchsten Ordnungszahl, da muss doch auch das höchstwertige Byte drinnestehen!(?)"

Und dann sag ich jedesmal: Tausendeinhundert! was schreibste zuerst hin? Richtig! die Tausenderstelle!!! Und wenn Du neunundsechzig sagst, bist Du als Deutscher allein auf weiter Flur, schreiben tust Du trozdem zuerst den höherwertigen Sechser.

Mehr zum Für und Wider betreffend Big und Little-Endian möge jeder selbst bei Wikipedia nachlesen.


----------



## moeins (23 November 2007)

OHGN schrieb:


> Was Du hier beschreibst ist aber das erste Bit aus dem High-Byte (also Meldung 9).
> Für die erste Meldung ist also richtig: 00000000 00000001


Ja sorry mein Fehler.

Wenn ich  z.B.  das MW10 als Meldewort nutze, ist meine erste Meldung das Bit 11.0 und nicht wie man vielleicht vermuten könnte, das Bit 10.0.
Deshalb meine Frage ob die Reihenfolge passt.




			
				Kai schrieb:
			
		

> Den Aufruf des FC100 musst Du in der FUP-Ansicht in Dein Programm einfügen.
> Der Aufruf des FC100 muss in Deinem Programm dann so aussehen wie der Aufruf des FC100 in dem Netzwerk 1 in den PDF-Files OB1-FUP.PDF und OB1-AWL.PDF.
> Nur dann funktioniert der FC100 richtig.


Ja das könnte durchaus ein Problem werden, wir müssen hier im Betrieb leider alles wissen und beherschen (S5,S7,Profibus, WinCC, Sinamics, MotionControl,EPLAN,WSCAD, TreeCAD u.a. Hersteller) und daher könnte es sein das solche Details einfach mal vergessen werden...


----------



## OHGN (23 November 2007)

moeins schrieb:


> Zitat:
> Zitat von *Kai*
> _Den Aufruf des FC100 musst Du in der FUP-Ansicht in Dein Programm einfügen. _
> _Der Aufruf des FC100 muss in Deinem Programm dann so aussehen wie der Aufruf des FC100 in dem Netzwerk 1 in den PDF-Files OB1-FUP.PDF und OB1-AWL.PDF. _
> ...


Also jetzt nichts gegen Kai, aber ich würde keinen Baustein verwenden den ich nur in FUP oder KOP aufrufen darf damit er funktioniert.
Dann doch lieber der "unsaubere" Lokaldaten- Absolutzugriff, da kann wenigstens nix schiefgehen.


----------



## zotos (23 November 2007)

Auch wenn Kais Lösung nun nicht mehr in Frage kommt, habe ich noch einen Verbesserungsvorschlag bzw. eine Anmerkung dazu.

Bei Funktionen die nur einen Rückgabewert haben, wie der FC100 von Kai, würde ich vorschlagen den RET_VAL und keine VAR_Output zu verwenden. Das macht die Verwendung einer solchen Funktion in SCL deutlich angenehmer. 

OffTopic:



IBN-Service schrieb:


> Hallo Zotos,
> 
> nur weil du kleiner und unsportlicher bist als ich,
> heist dass nicht,
> ...



Nur weil Du mir geistig unterlegen bist, bedeutet das nicht, dass Du mir körperlich überlegen bist ;o)


----------



## vierlagig (9 Dezember 2007)

zotos schrieb:


> Gegebenenfalls ist zwar kein Zufall aber wieder etwas was Du lieber anderen Überlässt?
> 
> Die Information hast Du nun schon zwei mit Berufung auf "ggf." mal vertagt.
> 
> Dabei habe ich mich doch so darauf gefreut wie Du wieder schön vorlaut Deine Phantasie als Tatsache deklarierst ;o)



der herr zotos wieder am sticheln? wer hätte auch was anderes erwartet ...


----------

