TIA Aktualisierung eines Eingangs via :P oder TPA

[pxZ]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Abend,

ich habe eine allgemeine Frage: Welcher Zugriff auf einen Eingang ist eigentlich zu bevorzugen, wenn dieser in einem Zeit-OB (in diesem Beispiel "Cyclic interrupt" fix auf 10ms gestellt) ausgewertet/weiterverarbeitet wird. Der Peripheriezugriff via "E1502.0: P" oder über ein Teilprozessabbild welches diesem OB zugeordnet ist, in der nachfolgenden Grafik dargestellt:



Dieser Eingang wird nur in diesem Zeit-OB ausgewertet um Beispielsweise anhand der Signalflanken (Inkrementalgeber) einen Positionswert in einem Global-DB zu aktualisieren welcher dann im restlichen Projekt verwendet wird. Kommen beide Varianten auf das gleiche Ergebnis, oder gibt es hier wesentliche Unterschiede?

mfG

 

[ducati]

Beim Zugriff über ": P" wird der Wert halt mehrmals (am Anfang OB1 und bei jedem ": P" Aufruf) "geholt"... und dadurch in Deinem Programm inkonsistent.
Was für Dich besser ist, musst selber entscheiden.

Kann man in der 1500er überhaupt Bits per Peripheriezugriff holen? das geht doch eigentlich nur für Bytes Worte Doppelworte...

 

[HolzigerBambus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann man in der 1500er überhaupt Bits per Peripheriezugriff holen? das geht doch eigentlich nur für Bytes Worte Doppelworte...

Ja das geht, habe ich auch schon für schnelle Drehüberwachungen verwendet.
Ich habe ": P" verwendet, da es nur ein paar wenige Eingänge waren und ich da nicht die ganze Eingangskarte, bzw. mehrere auf das schneller TPA legen wollte.

P.S.: Wenn man : P verwendet und die Baugruppe mal nicht verfügbar ist läuft der Meldepuffer der Steuerung sehr schnell mit Meldungen dazu voll. Ich hatte dann die Abfrage übersprungen, wenn der Busteilnehmer nicht erreichbar war.

 

[StP]

War der Peripheriezugriff nicht eher eine "Krücke" aufgrund der sehr kleinen, fixen Prozessabbilder (zB 128 byte) der frühen S7-300 Steuerungen?
Wenn es um einen "Wald & Wiesen"-Wert geht, würde ich ihn im OB1 Prozessabbild einlesen, wenn er wirklich in einem 10ms Zyklus verarbeitet werden soll (zB Impulserfassung) dann in einem dem 10ms-OB zugeordneten TPA.

 

[ducati]

War der Peripheriezugriff nicht eher eine "Krücke" aufgrund der sehr kleinen, fixen Prozessabbilder (zB 128 byte) der frühen S7-300 Steuerungen?
Wenn es um einen "Wald & Wiesen"-Wert geht, würde ich ihn im OB1 Prozessabbild einlesen, wenn er wirklich in einem 10ms Zyklus verarbeitet werden soll (zB Impulserfassung) dann in einem dem 10ms-OB zugeordneten TPA.

sicherlich ist das historisch gewachsen...

Problem sind halt "gemischte" Karten, wo verschiedene Eingänge einer Karte oder eines EBs in verschiedenen PAs oder TPAs verwendet werden sollen. Da machts halt schon Sinn, einige wenige Eingänge als : P zu lesen. Zumal es auch CPUs gibt, wo man nur ein TPA hat...

Oder halt Standards, wo halt einheitlich im ganzen Werk alle Analogsignale ab EW128 liegen und per PEW128 oder EW128: P gelesen werden...

 

[StP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Problem sind halt "gemischte" Karten, wo verschiedene Eingänge einer Karte oder eines EBs in verschiedenen PAs oder TPAs verwendet werden sollen.

In diesem Fall würde ich die ganze Karte dem TPA des "schnellsten" erforderlichen OBs zuordnen.

 

[IBFS]

Oder halt Standards, wo halt einheitlich im ganzen Werk alle Analogsignale ab EW128 liegen und per PEW128 oder EW128: P gelesen werden...

ein .. : P Zugriff, habe ich festgestellt, lieferte in meinem Fall falsche Werte.
Dabei war das ausgelesen Wort stabil, hat sich also nicht verwendet.

Daher rate ich für die1500er definitiv von der Benutzung von .. : P ab!

 

[Onkel Dagobert]

ein .. : P Zugriff, habe ich festgestellt, lieferte in meinem Fall falsche Werte.
Dabei war das ausgelesen Wort stabil, hat sich also nicht verwendet.

Daher rate ich für die1500er definitiv von der Benutzung von .. : P ab!

Wie bitte? Ich glaube, hier kommen Fragen auf. Kannst du das vielleicht noch etwas näher erläutern?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, das müsste mal genauer erklärt werden. Wieso liefern Peripheriezugriffe "falsche" Werte? Aus was für einem Gerät? Zeige uns mal ein Code-Beispiel.

Im OB1 sollte es egal sein, ob ein Wert aus dem Prozessabbild oder direkt aus der Peripherie gelesen wird - solange nur genau einmal im Zyklus gelesen wird. (Genau das macht ja das automatische Einlesen des PAE auch). Soll ein Peripherie-Wert mehrmals verwendet werden, dann muss er einmal aus der Peripherie auf eine Zwischenvariable umkopiert werden und dann diese Zwischenvariable weiterverwendet werden (also quasi Ad hoc ein eigenes Prozessabbild bilden).
In Zeit-OB und Alarm-OB will man in der Regel möglichst aktuelle Werte verarbeiten, da kann man meistens nicht die älteren Werte vom Beginn des OB1 verwenden, sondern muss "notgedrungen" aus der Peripherie lesen.

 

[IBFS]

Wie bitte? Ich glaube, hier kommen Fragen auf. Kannst du das vielleicht noch etwas näher erläutern?

S7-300 (TIA) geht folgendes Konstrukt. Nach der Migration zu einer 1500 geht es nicht mehr korrekt:



daher nun ohne "P" :



Der Roboter hatte wären des Tests statische stabile Signale.

 

[Larry Laffer]

@IBFS: liegt es denn nun an dem direkten Perepherie-Zugriff oder vielleicht eher an dem BlockMove ? Ich muss dir gestehen, dass ich ähnliches auch oft gemacht habe - dann aber das Byte (oder Wort) direkt geladen und transferiert. Ich hatte damit nie ein Problem ...

 

[IBFS]

Zuviel Werbung?
-> Hier kostenlos registrieren

@IBFS: liegt es denn nun an dem direkten Perepherie-Zugriff oder vielleicht eher an dem BlockMove ? Ich muss dir gestehen, dass ich ähnliches auch oft gemacht habe - dann aber das Byte (oder Wort) direkt geladen und transferiert. Ich hatte damit nie ein Problem ...

naja .. Der Blockmove ist nötig weil ich nur so das EW in eine Bitstruktur umkopieren kann.

Das habe ich im 300er Zeitalter 1000 fach gemacht.

Es ist auch so bis zum Mai 2025 so gelaufen mit dem "P"

Danach habe ich auf 1500 umgestellt, weil ich die komplexen 1500er Samples nicht auf die 300er zurückcodieren wollte.

Danach war im konkreten Fall z.B. ein Bit in der Struktur NULL obwohl es EINS war. Nach der Änderung (ohne P) ging es dann.

Alles sehr merkwürdig.

 

[Larry Laffer]

naja .. Der Blockmove ist nötig weil ich nur so das EW in eine Bitstruktur umkopieren kann.

das verstehe ich nicht ...

Das habe ich im 300er Zeitalter 1000 fach gemacht.

da können wir uns ja die Hand geben (außer das mit dem BlockMove)

Es ist auch so bis zum Mai 2025 so gelaufen mit dem "P"

Danach habe ich auf 1500 umgestellt, weil ich die komplexen 1500er Samples nicht auf die 300er zurückcodieren wollte.

das heißt, dass du bist Mai noch vorrangig mit den 300er gearbeitet hast ?

Danach war im konkreten Fall z.B. ein Bit in der Struktur NULL obwohl es EINS war. Nach der Änderung (ohne P) ging es dann.

Alles sehr merkwürdig.

Ich habe gelesen, dass du als Referenz ein quasi statisches Signal genommen hast. Das ist dann wirklich mehr als unverständlich.

Das Erste oben darfst du aber (mir) gerne noch einmal erklären ...

 

[IBFS]

"das heißt, dass du bist Mai noch vorrangig mit den 300er gearbeitet hast ?"

Die Maschine hatte eine 315PN/DP, die ha ich nur umgerüstet auf eine 1515

" als Referenz ein quasi statisches Signal genommen hast."

Der Roboter - siehe Symbolname - war in den Bits statisch, weil er sich nicht bewegt hat und daher die Bereichsbits immer gleich waren.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

S7-300 (TIA) geht folgendes Konstrukt. Nach der Migration zu einer 1500 geht es nicht mehr korrekt:

Anhang anzeigen 90224

Bist du sicher dass das korrekt ging? BLKMOV auf einer S7-300 kann offiziell gar nicht aus Peripherieadressen lesen. Daran ändert auch TIA nichts. Ich weiß nicht, was das TIA da (heimlich) draus macht bei BLKMOV mit "%IW600":P

 

[PN/DP]

naja .. Der Blockmove ist nötig weil ich nur so das EW in eine Bitstruktur umkopieren kann.

Die S7-1500 braucht dafür kein Blockmove, da kann man direkt die EA-Adressen mit einem UDT deklarieren, der die Bitstruktur des EW hat. Und dann die Struktur per MOVE oder einfache Zuweisung vollsymbolisch kopieren.

Das habe ich im 300er Zeitalter 1000 fach gemacht.

Es ist auch so bis zum Mai 2025 so gelaufen mit dem "P"

das dürfte aber nicht mit BLKMOV aus Peripherieadressen funktioniert haben, weil das gar nicht geht

 

[Onkel Dagobert]

@IBFS: liegt es denn nun an dem direkten Perepherie-Zugriff oder vielleicht eher an dem BlockMove ? ...

Oder liegt es an AWL? AWL und die S71200/1500 sind ja ohnehin keine so guten Freunde.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

AWL und die S71200

1200 kann kein AWL

 

[Onkel Dagobert]

1200 kann kein AWL

Ah ja, also Erzfeinde, so zu sagen .

 

[PN/DP]

S7-300 (TIA) geht folgendes Konstrukt. Nach der Migration zu einer 1500 geht es nicht mehr korrekt:

Anhang anzeigen 90224

Nur weil in TIA der Compiler nicht mehr meckert, heißt das nicht, dass der Code auch "geht". Dazu muss man den Code testen.
Den RETVAL hattest du wohl nicht zufällig ausgewertet? Das sollte man (zumindest testweise bei neuem/geänderten Code) tun - und wenn es auch nur beobachten des Codes und des RETVAL ist.

Wie bereits weiter oben geschrieben: BLKMOV kann nicht aus Peripherieadressen kopieren. Der Code kann nicht funktioniert haben.
Das blöde an diesem Programmierfehler ist, dass keine rote SF-LED angeht und auch keine Diagnosepuffereinträge erzeugt werden. Lediglich der RETVAL teilt mit, dass etwas schiefgelaufen ist. Und bei RETVAL <> 0 wird/wurde nichts kopiert.

Hier mal in AWL Tests des BLKMOV (auf S7-300):

CALL  "BLKMOV"
 SRCBLK :=EW0
 RET_VAL:=#RETVAL
 DSTBLK :=AW0
//liefert RETVAL = 0 : Kein Fehler

CALL  "BLKMOV"
 SRCBLK :=PEW0
 RET_VAL:=#RETVAL
 DSTBLK :=AW0
//liefert RETVAL = 33060 = 16#8124 : Parameter 1 unzulässig

CALL  "BLKMOV"
 SRCBLK :=EW0
 RET_VAL:=#RETVAL
 DSTBLK :=PAW0
//liefert RETVAL = 33573 = 16#8325 : Parameter 3 unzulässig

Bei RETVAL <> 0 wurde das Kopieren nicht ausgeführt!

Aus der Hilfe zu BLKMOV:

Fehlerauswertung mit dem Ausgangsparameter RET_VAL

Fehlercode (W#16#...)
8x24 Bereichsfehler beim Lesen eines Parameters.
8x25 Bereichsfehler beim Schreiben eines Parameters.
Dieser Fehlercode zeigt an, daß sich der Parameter x in einem Bereich befindet, der für die Systemfunktion unzulässig ist. Die Beschreibung der jeweiligen Funktion gibt die Bereiche an, die für die Funktion unzulässig sind.

BLKMOV: Bereich kopieren
Speicherbereiche
Mit der Anweisung "Bereich kopieren" können Sie die folgenden Speicherbereiche kopieren:
• Bereiche eines Datenbausteins
• Merker
• Prozessabbild der Eingänge
• Prozessabbild der Ausgänge
• Nicht ablaufrelevante Datenbausteine

Wobei da "Prozessabbild der ...gänge" (wohl absichtlich?) nicht ganz richtig formuliert wurde, weil gemeint ist eigentlich "Speicherbereiche der Eingänge/Ausgänge" (die auch größer als die Prozessabbilder sein können), damit flüchtige/oberflächliche Leser deutlicher sehen, dass Peripherieadressen nicht möglich sind.