Step 7 S7 Classic Sensor Ein-/Ausgänge außerhalb des Prozessabbildes einlesen u. beschreiben

Hexmex

Level-2
Beiträge
72
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich muss für eine neue Anwendung in einer Step7 Bestandsanlage Sensorik einbinden, nur leider sind hier nur noch E/A-Adressen außerhalb des Prozessabbildes (=2300 Bytes E/A) frei.

Da ich nicht sehr erfahren mit S7 Classic bin, möchte ich mein Vorhaben im Vorfeld mal diskutieren und meine Idee absichern und daher wollte euch fragen, ob ich mit meinem Ansatz irgendwelche Probleme bekommen könnte.

Ich habe es aktuell so gelöst wie in den Bildern im Anhang. Müsste ich ggf. mit PEB u. PAB (Peripheriezugriff) arbeiten?

Oder wäre ggf. eine Variante mit DPRD_DAT (SFC14) u. DPWT_DAT (SFC15) besser?


Vielen Dank für eure Meinungen!
 

Anhänge

  • SensorHwKonfig.png
    SensorHwKonfig.png
    64,9 KB · Aufrufe: 63
  • SensorEingängeEinlesen.png
    SensorEingängeEinlesen.png
    21 KB · Aufrufe: 61
  • SensorAusgängeBeschreiben.png
    SensorAusgängeBeschreiben.png
    21 KB · Aufrufe: 48
  • SensorSstDB.png
    SensorSstDB.png
    9,5 KB · Aufrufe: 59
Zuletzt bearbeitet:
Soweit ich mich erinneren kann, kannst du mit SFC14 nur einen Steckplatz auf einmal lesen. Ich denke aber ein SFC20 auf die Peripheriedaten müsste in einem Ruck gehen.

PS: BMW?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mal eine Frage am Rande : warum willst du den Keyence überhaupt auf Eingänge schreiben ? Um mit dem, was das Gerät dir liefert, etwas anfangen zu können musst du es doch sowieso noch weiter verarbeiten. Ich habe mir, speziell bei Keyence, immer einen FB erstellt, der den Sensor oder das Gerät ausliest, die Infos aufbereitet und mir am Ende "nur" das ausgibt, was mich wirklich interessiert.
Innerhalb des FB's habe ich mir das Eingelesene dann in die Instanzdaten geschrieben.
Ich habe da auch nie mit AWL gearbeitet sondern immer mit SCL - ich kenne dein Modell nun nicht, kann mir aber auch da gut vorstellen, dass für das Aufbereiten der Daten eine Programmiersprache mehr Sinn macht ...
 
Mal eine Frage am Rande : warum willst du den Keyence überhaupt auf Eingänge schreiben ? Um mit dem, was das Gerät dir liefert, etwas anfangen zu können musst du es doch sowieso noch weiter verarbeiten. Ich habe mir, speziell bei Keyence, immer einen FB erstellt, der den Sensor oder das Gerät ausliest, die Infos aufbereitet und mir am Ende "nur" das ausgibt, was mich wirklich interessiert.
Innerhalb des FB's habe ich mir das Eingelesene dann in die Instanzdaten geschrieben.
Ich habe da auch nie mit AWL gearbeitet sondern immer mit SCL - ich kenne dein Modell nun nicht, kann mir aber auch da gut vorstellen, dass für das Aufbereiten der Daten eine Programmiersprache mehr Sinn macht ...

Die Eingänge möchte ich einlesen und die Ausgänge zum Gerät beschreiben. Hier geht´s um eine Vermessung mit Trigger für die Messung (Out) und Ergebnisse der Messung (IN)....

SCL wäre auch meine erste Wahl gewesen, wenn es sich um TIA handelt, aber bei S7 Classic war ich mangels Erfahrung hier etwas vorsichtig...


Meintest du mit "einlesen auf Instanzdaten" in etwa so? Würde das denn gehen außerhalb des zyklischen PAE u. PAA?
 

Anhänge

  • statIN.png
    statIN.png
    32,6 KB · Aufrufe: 18
  • statOUT.png
    statOUT.png
    35,1 KB · Aufrufe: 16
Zuletzt bearbeitet:
Das stimmt 😄


Und du meinst, dass ich mit dem SFC20 einfach alle 300Byte Eingänge in einem Aufwasch einlesen bzw. am Bausteinende dann auch beschreiben kann?

Die Lösung erschien mir von Beginn an zu einfach, sodass ich mich darauf gar nicht erst konzentriert habe 😅
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich dachte, ich hätte es in früheren Bausteinen eher mit den SFC14 / SFC15 gesehen wie im Anhang, aber wie du schon gesagt hast, sollte der nur je einen Steckplatz lesen oder beschreiben, denke ich...

Bin aber nicht mehr 100% sicher und finde leider kein altes Projekt wo das angewendet wurde... zu lange ist´s her das Step7 :(
 

Anhänge

  • SFC14_15.png
    SFC14_15.png
    17 KB · Aufrufe: 10
Ich habe es aktuell so gelöst wie in den Bildern im Anhang. Müsste ich ggf. mit PEB u. PAB (Peripheriezugriff) arbeiten?
Aus Speicheradressen aus dem Speicherbereich der Eingänge lesen (z.B. L EW...), die außerhalb des Prozessabbildes liegen, ist ein vergebliches Unterfangen, weil da einstellungsgemäß eben nicht der Inhalt der Baugruppen hineingeschrieben wird und alle 0 liefern (oder bis man selbst etwas hineinschreibt). Es muss aus den Peripherieadressen gelesen werden.

Oder wäre ggf. eine Variante mit DPRD_DAT (SFC14) u. DPWT_DAT (SFC15) besser?
Mit SFC14/SFC15 kann man nur auf Peripheriebereiche zugreifen, für die eine Konsistenz 3 Bytes oder > 4 Bytes projektiert ist. Und es kann nur auf jeden projektierten Steckplatz einzeln zugegriffen werden (d.h. nicht mehrere Steckplätze auf einmal). Bei Konsistenz 1, 2 oder 4 Bytes muss mit L PEB/PEW/PED... / T PAB/PAW/PAD... zugegriffen werden. siehe Hilfe zu den SFC14/SFC15

Und Hinweis: der SFC20 BLKMOV kann nicht auf Peripherieadressen zugreifen. siehe Hilfe zum SFC20
 
Es funktioniert bei mir mit DPRD_DAT (SFC14) u. DPWT_DAT (SFC15) ohne Probleme, auch ohne irgendwelche Konsistenzeinstellungen.
Die Daten gehen dann eben nicht in das/aus dem Prozessabbild sondern in einen entsprechenden DB.
Also am Zyklusanfang SFC14 und am Zyklusende SFC15 und zwischendurch mit den "Eingängen" und "Ausgängen" arbeiten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es funktioniert bei mir mit DPRD_DAT (SFC14) u. DPWT_DAT (SFC15) ohne Probleme, auch ohne irgendwelche Konsistenzeinstellungen.
Die Daten gehen dann eben nicht in das/aus dem Prozessabbild sondern in einen entsprechenden DB.
Also am Zyklusanfang SFC14 und am Zyklusende SFC15 und zwischendurch mit den "Eingängen" und "Ausgängen" arbeiten.
Aber da muss man jeden Steckplatz einzeln lesen oder? In einem Ruck geht bei soviel Submodulen nicht, oder irre ich mich?

Da merkt man erst wie Praktisch die UDTs in den E/As bei TIA sind…
 
Wenn in der Hardware alle Slots schön hintereinander sind ist es kein Problem alles in einem Rutsch einzulesen, z.B.:

CALL "DPRD_DAT"
LADDR :=W#16#300
RET_VAL:="d_DMC_Datenaustausch".Scanner.IN_RET_VAL
RECORD :=P#DB101.DBX0.0 BYTE 300

Auch bei Tia muss für einen UDT alles schön hintereinander sein.

Leider hat die automatische Adressvergabe da andere Ansichten drüber, was sinnvoll ist ...
 
Ok, ich habe jetzt viele Ansätze und weil das IBN Zeitfenster recht eng ist, bereite ich gleich mal mehrere Varianten vor und davon wird hoffentlich schon eine funktionieren :)

Danke schon mal für Eure Hilfestellungen! Ich berichte, ob bzw. was am Ende geklappt hat ;)

Jetzt hätte ich aber noch eine andere Step7 Frage:
Kann es sein, dass Flanken (also mit dem --(N)-- bzw. --(P)-- Symbol) ausschließlich mit Merkern als Operanden funktionieren?
Gibt es in S7 keine Möglichkeit in einer Multiinstanz Flanken im statischen Bereich zu deklarieren? Ich baue gerade einen Baustein und mit Merker an der --(N)-- Flanke klappts, mit einer stat. Variable geht die Flanke nicht...


Edit: per INOUT übergebener Global-DB in dem die Flanken gespeichert sind, funktioniert offenbar :unsure:
 
Zuletzt bearbeitet:
... SCL wäre auch meine erste Wahl gewesen, wenn es sich um TIA handelt, aber bei S7 Classic war ich mangels Erfahrung hier etwas vorsichtig....
In einer FOR-Schleife indiziert auf Peripherieadressen zu zugreifen, ist m.E. die einzige Möglichkeit für dein Vorhaben. Das funktioniert sowohl im Abbild als auch außerhalb. Wenn die Datenblöcke allerdings als "Block-konsistent" deklariert worden sind bzw. werden können, dann würde ich natürlich SFC14/15 verwenden.

... mit Merker an der .. Flanke klappts, mit einer stat. Variable geht die Flanke nicht...
Auch dann nicht, wenn man die Instanz nur 1x verwendet?
 
Zuletzt bearbeitet:
Eine For-Schleife macht hier doch keinen Sinn?! Einfach mit SFC14/15 die beiden E/A-bereiche der beiden Keyence-Kamera-Kontroller lesen/schreiben in verschiedene DB oder getrennte Bereiche in einem DB funktioniert einwandfrei.
Das funktioniert in allen Sprachen.
Tip am Rande: Keyence mag beim Taufen nur standardkonforme PN-Namen. In TIA kann man das umgehen, indem man das Keyence-Gerät auf den umgewandelten Namen tauft, der wird automatisch aus dem vergebenen Namen standardkonform gebildet. (Eigenschaftenfenster)
 
Zurück
Oben