TIA Kommunikation S7 315-2DP als PN-Slave und S7 1511-1PN

[PN/DP]

Hat dein PNIO_SEND und PNIO_RECV überhaupt schon einmal fehlerfrei funktioniert?
Der Error 16#8184 kann auch bedeuten, dass der ANY-Parameter an IOCS/IOPS unzulässig ist. Laut Beschreibung PNIO_SEND und PNIO_RECV sind da nur Adressen auf Merker und DB zulässig, NICHT TEMP.

 

[Slimer]

Vielen, vielen Dank,
hab's nun dank eurer Hilfe hinbekommen. Es waren tatsächlich die IOCS/IOPS. Bis 32 Byte EA-Daten (bzw. 32 Bit IOCS/IOPS) am Eingang lief es, aber darüber hinaus ging nix mehr. Als ich dann die Werte statt in den Temp in den Datenbaustein eingegliedert habe, oh Wunder, lief es.
Sogar die Bausteine wurden beide (farblich) grün...
Nun bleiben bei mir wenige Fragen:
A.) ..(nur aus Neugierde) wie merkt der Baustein, dass der IOCS/IOPS "nur" in den Temp schreibt?
B.) vermutlich werden die Daten, in meinem Fall 240<->240Byte, in mehreren Zyklen geschrieben und gelesen. Kann ich 1.) beide Bausteine Send & Recv parallel aufrufen, und wie steht es 2.) mit der Transparenz? Muss man evtl. Noch ein zusätzlichen Puffer mit je 240Byte anlegen und diesen z.B. auf ein Done (gibt es nur beim SEND, aber leider nicht beim RECV) hin in einem "Stück" in die eigentlichen Sende-/Empfangsdaten Übertragen, um einer Änderung der Informationen während der Übertragungen vorzubeugen? Oder gibt es ein (Sende-Empfangs)-Buffer, in welchen die Baussteine von selbst in einem Stück zwischenpuffern?

Schönes WE...

 

[PN/DP]

hab's nun dank eurer Hilfe hinbekommen. Es waren tatsächlich die IOCS/IOPS. Bis 32 Byte EA-Daten (bzw. 32 Bit IOCS/IOPS) am Eingang lief es, aber darüber hinaus ging nix mehr. Als ich dann die Werte statt in den Temp in den Datenbaustein eingegliedert habe, oh Wunder, lief es.
Sogar die Bausteine wurden beide (farblich) grün...

Danke für die Erfolgsmeldung und Aufklärung zum Grund

A.) ..(nur aus Neugierde) wie merkt der Baustein, dass der IOCS/IOPS "nur" in den Temp schreibt?

weil der Speicherbereich als ANY-Pointer übergeben wird, da können die FC die Adresse im Pointer analysieren
Möglicherweise werden die Statusbits in IOCS/IOPS wie die eigentlichen Daten auch nicht alle im selben Zyklus geschrieben und deshalb ist TEMP für den Puffer nicht zulässig.

B.) vermutlich werden die Daten, in meinem Fall 240<->240Byte, in mehreren Zyklen geschrieben und gelesen.

ja, siehe die Hilfe zu den FC das Thema "Konsistenz":

Im Normalfall (abhängig von der Gesamtlänge der IO-Daten) wird der Baustein über mehrere Anwenderprogramm-Zyklen laufen, bis die Anzeige DONE/NDR = 1 meldet.

Kann ich 1.) beide Bausteine Send & Recv parallel aufrufen

ja

wie steht es 2.) mit der Transparenz?

du meinst vermutlich Konsistenz? siehe die Hilfe zu den FC das Thema "Konsistenz"

Muss man evtl. Noch ein zusätzlichen Puffer mit je 240Byte anlegen und diesen z.B. auf ein Done (gibt es nur beim SEND, aber leider nicht beim RECV)

bei PNIO_RECV gibt es NDR

... hin in einem "Stück" in die eigentlichen Sende-/Empfangsdaten Übertragen, um einer Änderung der Informationen während der Übertragungen vorzubeugen?

siehe die Hilfe zu den FC:

Erläuterung der Formalparameter - PNIO_SEND
Hinweis
Ausführungsbestätigung abwarten
Führen Sie folgende Aktionen erst aus, nachdem der Baustein entweder DONE = 1 oder ERROR = 1 signalisiert hat:
· Ausgangsparameter auswerten;
· den Parameter MODE verändern.

Hinweis
Sie müssen davon ausgehen, dass der gelieferte IOCS Status nicht zeitsynchron zu den Daten (SEND Parameter) kommt, sondern um einen Anwenderprogramm-Zyklus verzögert. Das heißt: Anwenderdaten und IOCS sind nicht konsistent.

(aus der Hilfe in TIA, weil die Hilfe in Step7 classic fehlerhaft ist)
Parameter bei PNIO_RECV
Hinweis
Beachten Sie, dass alle Ausgangsparameter erst dann ausgewertet werden dürfen, wenn die Anweisung entweder NDR = 1 oder ERROR = 1 signalisiert.

Oder gibt es ein (Sende-Empfangs)-Buffer, in welchen die Baussteine von selbst in einem Stück zwischenpuffern?

Beachte, dass sich DONE und NDR nicht direkt auf "Daten gesendet" und "neue Daten empfangen" beziehen, sondern nur auf die Übergabe der Daten zwischen CPU/Anwenderprogramm und CP beziehen und der CP die eigentliche Kommunikation übers Netzwerk völlig selbständig und asynchron abhandelt mit eigenen Puffern.