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

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast du die UDTs 'UDT_Keyence_LJ800E_IN' und 'UDT_Keyence_LJ800E_OUT' von eine eksterne Quelle bekommen ?
Wenn ja, gibt es vielleicht auch eine fix-und-fertige Biblioteksbaustein ?

 

[Hexmex]

Hast du die UDTs 'UDT_Keyence_LJ800E_IN' und 'UDT_Keyence_LJ800E_OUT' von eine eksterne Quelle bekommen ?
Wenn ja, gibt es vielleicht auch eine fix-und-fertige Biblioteksbaustein ?

Nein, ich habe eine TIA Projektvorlage erhalten vom Endkunden und da wurden alle EAs per UDT in der Symboltabelle angelegt und zudem werden in TIA ja alle EAs übers PAE/PAA direkt abgebildet

 

[TP-Inc]

Zuviel Werbung?
-> Hier kostenlos registrieren

ja, darauf hab ich geachtet. aber funktioniert scheinbar wirklich nicht mit STAT. oder hängst vielleicht nur damit zusammen, dass ich das Programm hier mit PLC SIM simuliere?! ist schon echt teilweise seeehr seltsames Verhalten hier bei der Simulation....

Das sollte PLCSIM schon können… zeig mal ein Screenshot.

 

[Hexmex]

Definitiv DPRD_DAT und DPWR_DAT um die Daten für jeden einzelne EA Bereich grösser als 4 Byte übertragen.
Die Screenshots mit DRRD_DAT und DPWR_DAT siehen korrekt aus.
edit: Warte mal, es funktioniert nicht mit nur 1 DPRD_DAT und 1 DPWR_DAT für alle E und A Daten auf einmal.
Es muss 1 DPRD_DAT oder 1 DPWR_DAT pro E/A Bereich sein !
'Result Data128 byte', 'Result Data 32 byte', usw. sind einzelne Bereiche !

BLKMOV wird nicht funktionieren.

Schleifen mit Pointer Zugriff auf PEB aund PAB ist sehr problematisch. Die Daten werden nicht konsistent übertragen. Es kann gut sein dass das Keyence Antrieb Zugriffe aus einzel-Daten blokiert.

letzte Variante die ich nun vorbereite...

eine davon muss dann jetz klappen

(ganz am Ende kopiere ich noch auf eine interne statisch IN Struktur; mit den variablen arbeite ich dann im Baustein)

 

[PN/DP]

Die Möglichkeiten, aus Peripherieadressen zu lesen, wurden bereits in #10 genannt. Vorschläge mit SFC20 oder SFC14/SFC15 mehrere Bereiche/Steckplätze/Slots auf einmal einzulesen, sind Mythen und funktionieren nicht. Welche CPU genau hast du eigentlich? Kannst du nicht einfach die Prozessabbilder PAE/PAA groß genug einstellen, und die je 300 Bytes E/A im Prozessabbild projektieren? Dann brauchst du gar nicht um das einlesen kümmern (keinen extra Kopiercode aufrufen).
Achtung: Beim Ändern der Größen der Prozessabbilder wird der Speicher neu organisiert, und ich meine, alle Variablen-Aktualdaten gehen verloren.

 

[Hexmex]

Zuviel Werbung?
-> Hier kostenlos registrieren

ist ne 416F-3 PN/DP


Das Prozessabbild zu vergrößern ist Kundenseitig nicht gestattet und ich würde auch Folgeprobleme fürchen... es ist hier eine Bestandsanlage die 24/5 läuft bei einer 60sek Taktung, mit viel Datengedöns, da will ich keinen unvorhergesehenen Quereinfluss riskieren; auch bzgl. Aktualdaten, etc.


Dann kommt eh nur der LOOP über die PE/PA oder das einlesen/schreiben per DPRDDAT/DPWTDAT


hab jetzt allerdings ein neues Problem

der Slot16 hat in der Hw-Konfig 7 Bytes, wenn ich die 7 Bytes als Array im UDT projektiere, schreibt der DPWTDAT trotzdem auf 8 Bytes weil Step7 das automatisch auf 8 Bytes erweitert.... auch wenn ich gerade nicht sicher bin ob das ein Problem macht... ich geh kurz weinen

 

[JesperMP]

der Slot16 hat in der Hw-Konfig 7 Bytes, wenn ich die 7 Bytes als Array im UDT projektiere, schreibt der DPWTDAT trotzdem auf 8 Bytes weil Step7 das automatisch auf 8 Bytes erweitert.... auch wenn ich gerade nicht sicher bin ob das ein Problem macht

Das Bereich in den DB ist 7 Bytes gross.
STEP7 hat nur den nächsten DB Struktur bei den nächsten gerade Byte-Adresse gestartet.
Es sollte funktionieren.
Es bedeutet 'nur' dass in das STEP7 Anwenderprogramm ist den DB Struktur unterschiedlich zu den E/A Struktur. Also, die Byte-Offsets sind ein bisschen unterschiedlich.

 

[JesperMP]

Dann kommt eh nur der LOOP über die PE/PA

Das wird mMn. nicht funktionieren.

 

[Richard P.]

Zuviel Werbung?
-> Hier kostenlos registrieren

... ist schon echt teilweise seeehr seltsames Verhalten hier bei der Simulation....

Hast du es denn mit der Flankenauswertung hin bekommen? Ohne hierfür die Ursache gefunden zu haben, solltest du nicht am lebenden Objekt operieren! Nicht dass sich die Spaltmaße urplötzlich vergrößern.

In #19 verwendest du zum Adressieren das Adressregister 2. Was es bei Verwendung des AR2 in einem FB zu beachten gibt ist dir bekannt?

letzte Variante die ich nun vorbereite...

Das sollte funktionieren, sofern die Slots als "konsistent über gesamte Länge" konfiguriert sind. Sind sie das denn?
Und warum der Umweg über die Arrays? Wenn anstatt der Arrays Structs mit den entsprechenden Datentypen und Symbolen oder eventuell auch UDTs angelegt wären, müsstest du nicht noch einmal umkopieren.

 

[Hexmex]

Hast du es denn mit der Flankenauswertung hin bekommen? Ohne hierfür die Ursache gefunden zu haben, solltest du nicht am lebenden Objekt operieren! Nicht dass sich die Spaltmaße urplötzlich vergrößern.

Ja, arbeite nun mit einem globalen-DB in dem die Flanken gespeichert sind und übergebe diesen per INOUT an den Multiinstanz-FB. Das lässt sich simulieren und scheint zu passen

 

[Hexmex]

In #19 verwendest du zum Adressieren das Adressregister 2. Was es bei Verwendung des AR2 in einem FB zu beachten gibt ist dir bekannt?

Bin gerade nicht sicher, magst du mir da vielleicht auf die Sprünge helfen?

 

[Hexmex]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das sollte funktionieren, sofern die Slots als "konsistent über gesamte Länge" konfiguriert sind. Sind sie das denn?
Und warum der Umweg über die Arrays? Wenn anstatt der Arrays Structs mit den entsprechenden Datentypen und Symbolen oder eventuell auch UDTs angelegt wären, müsstest du nicht noch einmal umkopieren.

Stimmt, das hab ich wohl etwas zu kompliziert gedacht, werde ich noch anpassen

 

[PN/DP]

Bin gerade nicht sicher, magst du mir da vielleicht auf die Sprünge helfen?

In Multiinstanzfähigen FB hält das AR2 die Anfangsadresse der Instanz und darf deshalb nicht verändert werden bzw. man kann nicht mehr auf die Stat-Variablen zugreifen, solange AR2 verändert ist. Such-Stichworte: Multiinstanz offset AR2

 

[Richard P.]

Ja, arbeite nun mit einem globalen-DB in dem die Flanken gespeichert sind und übergebe diesen per INOUT an den Multiinstanz-FB. Das lässt sich simulieren und scheint zu passen

NEIN! Wenn die Flankenauswertung mit den statischen Lokaldaten nicht funktioniert, dann hat das einen schwerwiegenden Grund! Wahrscheinlich verwendest du die Instanz mehrmals? Wer schmuggelt dich eigentlich bei BMW durch's Tor?

 

[Hexmex]

Zuviel Werbung?
-> Hier kostenlos registrieren

NEIN! Wenn die Flankenauswertung mit den statischen Lokaldaten nicht funktioniert, dann hat das einen schwerwiegenden Grund! Wahrscheinlich verwendest du die Instanz mehrmals? Wer schmuggelt dich eigentlich bei BMW durch's Tor?

Die Instanz hatte ich eben nicht mehrfach verwendet... das war ja das merkwürdige
hab dann sogar den Baustein in einem ansonsten leeren OB1 und 100% eindeutigen und mit exklusiven IDB aufgerufen - gleiches Verhalten... ich bin darüber ja genauso ratlos wie schockiert, aber kann´s eben nicht wegzaubern

 

[PN/DP]

Wurde der IDB in die CPU geladen?
Hast du die Flankenerkennung vielleicht mit TEMP-Variablen programmiert anstatt mit Stat-Variablen?
Haben die Variablen vielleicht eine falsche Vorbelegung?
Wie sieht der Programmcode aus?
Gibt es Einträge im CPU-Diagnosepuffer? Leuchten/blinken rote LEDs?

 

[Richard P.]

... ich bin darüber ja genauso ratlos wie schockiert, aber kann´s eben nicht wegzaubern

Ach so, na dann ist ja alles gut .

 

[Hexmex]

Zuviel Werbung?
-> Hier kostenlos registrieren

In Multiinstanzfähigen FB hält das AR2 die Anfangsadresse der Instanz und darf deshalb nicht verändert werden bzw. man kann nicht mehr auf die Stat-Variablen zugreifen, solange AR2 verändert ist. Such-Stichworte: Multiinstanz offset AR2

Danke für den Hinweis - ich denke das war das Problem bei meinen nicht funktionierenden statischen Flanken



Ich hatte die Adressregister zu Beginn des Multiinstanz-FBs nicht weggesichert und da ich bereits beide Instanzen aufgerufen hatte, haben sich wohl die Instanzen überschnitten!


.
.
.


Danke für den Hinweis!
Sollte mit jetzt aber mit der aktuellen Variante und den DPRD_DAT u. DPWT_DAT aufrufen eh keine Probleme mehr bereiten, da nicht mehr mit AR1+AR2 gearbeitet wird

 

[PN/DP]

AR1 braucht nicht gesichert werden. Nur AR2 muss man sichern und wiederherstellen, wenn man AR2 verändern und danach nochmal auf STAT-Variablen zugreifen will. Solange AR2 nicht den Inhalt vom Anfang des FB-Durchlaufs hat, kann man nicht auf die eigenen STAT-Lokaldaten zugreifen. AR2 ist quasi ein Pointer und man kann sich vorstellen, was passiert, wenn man mit einem Pointer, der nicht den erwarteten Inhalt hat, auf Speicheradressen zugreift ...
Alternative: FB nicht als "multiinstanzfähig" markieren, dann wird AR2 nicht verwendet.

 

[PN/DP]

PS: übrigens kann man die Inhalte der AR1/AR2 direkt in/aus TEMP-Variablen speichern/laden:

TAR2 #tempAR2  //AR2 sichern

L P#DBX123.4
LAR2
//ab hier kein Zugriff mehr auf STAT-Variablen möglich!
...
LAR2 #tempAR2  //AR2 wiederherstellen
//ab jetzt wieder Zugriff auf STAT-Variablen möglich
L #statVariable
...