Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 19

Thema: SCL: FB-Inputs/-Outputs elegant in DB schreiben und auslesen

  1. #1
    Registriert seit
    10.12.2015
    Beiträge
    13
    Danke
    4
    Erhielt 1 Danke für 1 Beitrag

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo zusammen,

    ich habe in einem Projekt paar FC und FB für eine 1513-1 und 315-2 geschrieben (alles in AWL). Jetzt soll ich das auf eine 1212C übertragen, aber die kann ja kein AWL (und kein BLKMOV, und keine Anypointer,...) und muss deshalb alles nach SCL umschreiben. Ich verwende TIA Portal V13 SP1 Update 5 und STEP7 5.5.

    Ein FB hat dabei beispielsweise die Eingänge DBnummer [INT] und 8 BOOLs mit aussagekräftigen Namen. Die BOOLs sollen in ein DB gespeichert werden. Auf der Ausgangsseite des FB stehen wiederrum andere 16 BOOLs mit Namen, die ihre Zustände einfach aus dem DB auslesen sollen.

    In AWL konnte ich einfach
    Code:
    L %DIB0
    T %DBB0
    schreiben, um die 8 BOOLs in den aufgeschlagenen DB zu laden. In SCL bekomme ich das mit der Adressierung irgendwie nicht hin. Die "optimierten Bausteine" habe ich abgeschaltet. Ich könnte zwar 8 mal POKE_BOOL aufrufen, aber geht das nicht einfacher? Die anderen PEEK-/POKE-Befehle wollen alle ARRAYs haben, aber dann kann ich die DB-Einträge nicht mehr mit Namen versehen.


    1513
    Zitieren Zitieren SCL: FB-Inputs/-Outputs elegant in DB schreiben und auslesen  

  2. #2
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.197
    Danke
    926
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Wenn man schön sauber jedes Bool einzeln anfasst, dann läßt sich das auch prima in SCL umsetzen.

    Mit den unsauberen Byte-Zugriffen nagelt man sich sowieso auf bestimmte CPU-Familien fest, wo diese Zugriffe zufällig funktionieren - diese sind also kein Mittel, was man in heutigen Programmen verwenden sollte.

    Im übrigen zwingst Du Deine S7-1200 oder S7-1500 nicht in die Knie, wenn Du denen den einzel-Bool-Zugriff zumutest.
    Eher mit den Byte-Zugriffen zwingst Du die CPUen in einen langsamen Kompatibilitäts-Emulationsmodus. Für die Byte-Zugriffe gibt es vermutlich keinen ernsthaften Grund? Falls Du tatsächlich Bools in Bytes/Words übertragen mußt, dann gibt es dafür die AT-Sicht und Slice-Zugriffe.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  3. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    1513 (11.12.2015)

  4. #3
    Registriert seit
    27.06.2009
    Ort
    am Nordharz
    Beiträge
    3.717
    Danke
    443
    Erhielt 920 Danke für 740 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    Für die Byte-Zugriffe gibt es vermutlich keinen ernsthaften Grund?
    Doch. Schreibarbeit ersparen.




  5. Folgender Benutzer sagt Danke zu hucki für den nützlichen Beitrag:

    1513 (11.12.2015)

  6. #4
    1513 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    10.12.2015
    Beiträge
    13
    Danke
    4
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Zitat Zitat von hucki Beitrag anzeigen
    Doch. Schreibarbeit ersparen.



    So siehts aus Na dann werde ich erstmal symbolisch programmieren, wenn noch was ist melde ich mich.

  7. #5
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.727
    Danke
    398
    Erhielt 2.404 Danke für 2.002 Beiträge

    Standard

    Wenn du auf SCL umschwenken willst dann ist es ggf. sinnvoller, das Baustein-Konzept noch einmal zu überdenken.
    In SCL läßt sich sehr vieles elegant lösen, wenn man nicht AWL als Vorlage nimmt und meint, das irgendwie nachprogrammieren zu müssen ...

    Gruß
    Larry

  8. #6
    1513 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    10.12.2015
    Beiträge
    13
    Danke
    4
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Zitat Zitat von Larry Laffer Beitrag anzeigen
    Wenn du auf SCL umschwenken willst dann ist es ggf. sinnvoller, das Baustein-Konzept noch einmal zu überdenken.
    In SCL läßt sich sehr vieles elegant lösen, wenn man nicht AWL als Vorlage nimmt und meint, das irgendwie nachprogrammieren zu müssen ...

    Gruß
    Larry
    Die Bausteine werden wohl so bleiben, weil die Funktionenaufteilung von meinem Projektgeber so gewünscht ist. Aber ich schau natürlich, was man in SCL vereinfachen oder gar weglassen könnte.


    Bin gerade dabei, einen REAL-Eingang am FC in ein DB zu schreiben:
    Code:
    POKE(area := 16#84, dbNumber := #DBNo, byteOffset := (#instno_tmp-1)*4, value := #Value);
    Der Wert wird im DB als DWORD (16#.....) angezeigt; in AWL war das nicht so. Kann man das in Gleitkommadarstellung ändern? Bei PEEK kann man ja DWORD_TO_REAL() nehmen.

  9. #7
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.727
    Danke
    398
    Erhielt 2.404 Danke für 2.002 Beiträge

    Standard

    Peek und Poke arbeiten m.E, nur mit den Grund-Datentypen, also Byte, Word und DWord. Das mußt du bei deiner Code-Erstellung beachten und ggf. notwendige Typ-Casts einbauen ... oder vielleicht doch das Konzept überdenken ...

  10. #8
    1513 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    10.12.2015
    Beiträge
    13
    Danke
    4
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Zitat Zitat von Larry Laffer Beitrag anzeigen
    Peek und Poke arbeiten m.E, nur mit den Grund-Datentypen, also Byte, Word und DWord. Das mußt du bei deiner Code-Erstellung beachten und ggf. notwendige Typ-Casts einbauen ... oder vielleicht doch das Konzept überdenken ...

    Es klappt jetzt mit der Darstellung. Musste den Eingangsparameter von Real auf LReal ändern, dann in der POKE-Zeile zweimal casten (LReal zu Real und Real zu DWord)...



    Keine Sorge, deine Zweifel am Konzept sind nicht an mir vorbeigegangen

  11. #9
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.197
    Danke
    926
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Zitat Zitat von 1513 Beitrag anzeigen
    Es klappt jetzt mit der Darstellung. Musste den Eingangsparameter von Real auf LReal ändern, dann in der POKE-Zeile zweimal casten (LReal zu Real und Real zu DWord)...
    Was hat der zum FC übergebene Datentyp mit dem Anzeigeformat eines DWord zu tun?
    Wozu soll die Übergabe eines REAL als LREAL gut sein???

    Ich habe gewisse Sorgen, ob Du verstehst, was Du da programmierst


    Zitat Zitat von 1513 Beitrag anzeigen
    Bin gerade dabei, einen REAL-Eingang am FC in ein DB zu schreiben:
    Code:
    POKE(area := 16#84, dbNumber := #DBNo, byteOffset := (#instno_tmp-1)*4, value := #Value);
    Der Wert wird im DB als DWORD (16#.....) angezeigt; in AWL war das nicht so. Kann man das in Gleitkommadarstellung ändern?
    Wo wird der DB-Wert "im DB" als 16#... angezeigt? (Hast Du ein Bild?)
    Ist das DB-DWord als REAL deklariert?

    Oder meinst Du den Wert, der beim Beobachten des Programms angezeigt wird?
    Da wird nicht angezeigt, welcher Wert (und welcher Datentyp) in der DB-Adresse nach dem POKE steht, sondern der Wert den der Übergabeparameter "value" hat, und "value" hat einen Bitfolgen-Datentyp -> daher die Anzeige als 16#.. Frag' mal Siemens, ob man das Anzeigeformat der Übergabeparameter umstellen/wählen kann.
    POKE schreibt nicht einen Datentyp sondern ein Bitmuster einer bestimmten Speichergröße an die angegebene Speicheradresse.

    Wenn Du den Wert Deines FC-Eingangs #Value als Gleitkomma beobachten willst, dann könntest Du ihn auf eine temporäre REAL-Variable umkopieren. Dann ist das TIA vermutlich so schlau beim Beobachten der Zeile den Wert als Gleitkomma anzuzeigen.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  12. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    1513 (11.12.2015)

  13. #10
    1513 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    10.12.2015
    Beiträge
    13
    Danke
    4
    Erhielt 1 Danke für 1 Beitrag

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von PN/DP Beitrag anzeigen
    Ist das DB-DWord als REAL deklariert?
    Ja. Im DB benutze ich nur REALs und BOOLs. Vorher wurden im FC/FB Ein- und Ausgangsparameter für Gleitkommawerte als REAL deklariert. Jetzt sind die FC-/FB-Eingänge LREALs, die Ausgänge wie vorhin "nur" REAL (es gibt FCs/FBs nur mit Gleitkomma-Eingängen, nur mit Gleitkomma-Ausgängen oder mit beidem).

    Oder meinst Du den Wert, der beim Beobachten des Programms angezeigt wird?
    Ja genau das meinte ich; hatte in TIA den DB geöffnet und beobachtet (die Werte mit dem orangegelben Hintergrund). Hatte zwischendurch auch mal den Wert temporär umkopiert und so. Auf jeden Fall zeigte er mal den Gleitkommawert als DWord an (16#...), und beim anderen mal (ohne LREAL) hatte die Genauigkeit des im DB gespeicherten Werts gelitten.

    Jetzt klappt aber alles.



    1513

Ähnliche Themen

  1. Wert in Array schreiben/überschreiben und auslesen (FUP)
    Von frigidolf im Forum CODESYS und IEC61131
    Antworten: 8
    Letzter Beitrag: 19.03.2015, 08:40
  2. Antworten: 3
    Letzter Beitrag: 23.11.2011, 15:26
  3. Antworten: 3
    Letzter Beitrag: 25.11.2008, 20:08
  4. Antworten: 7
    Letzter Beitrag: 30.07.2008, 13:13
  5. PS3 auslesen und Werte in MySql-DB schreiben
    Von Anonymous im Forum Sonstige Steuerungen
    Antworten: 2
    Letzter Beitrag: 22.01.2006, 15:08

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •