WORD aus einzelnen Bits zusammensetzen

[IBN-Service]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

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]

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 :???:

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

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nein, ich meinte eigentlich diese Variante :

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

 

[Kai]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

@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]

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]

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.

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.
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...

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]

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:

Hallo Zotos,

nur weil du kleiner und unsportlicher bist als ich,
heist dass nicht,
dass ich dich nicht auf dem nächsten Forumstreffen / Messe / wasauchimmer
verhauen werde!

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

 

[vierlagig]

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 ...