CP341 Kommunikation RK512

mertens2

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

habe in meiner Steuerung einen CP341 und möchte zu einem Fremdrechner über RK512 kommunizieren. Der Fremdrechner ist aktiv. Ich möchte Daten in beide Richtungen übertragen.
Nun die Frage: In der CP-Doku wird immer von passiver und aktiver Kommunikation gesprochen. Muss ich für Datenverkehr in beide Richtung einen aktiven und einen passiven programmieren, also einmal FB7 und einmal FB8?
Wenn ich meinen Kommunikationspartner richtig verstanden habe, ist er für senden und empfangen aktiv.

Gruß und Dank

c. mertens
 
mertens2 schrieb:
Hallo,

habe in meiner Steuerung einen CP341 und möchte zu einem Fremdrechner über RK512 kommunizieren. Der Fremdrechner ist aktiv. Ich möchte Daten in beide Richtungen übertragen.
Nun die Frage: In der CP-Doku wird immer von passiver und aktiver Kommunikation gesprochen. Muss ich für Datenverkehr in beide Richtung einen aktiven und einen passiven programmieren, also einmal FB7 und einmal FB8?
Wenn ich meinen Kommunikationspartner richtig verstanden habe, ist er für senden und empfangen aktiv.

Gruß und Dank

c. mertens
Hallo,

wenn Du Daten in beide Richtungen übertragen möchtest, dann benötigst Du den FB7 (P_RCV_RK) zum Datenempfang und den FB8 zum Senden von Daten an die Gegenstelle.
Den FB7 benötigst Du auch, wenn deine SPS passiver Partner ist und die Gegenstelle mit einem SEND-Telegramm Daten in einem DB deiner SPS addressiert. Den FB7 rufst Du einfach im SPS-Programm zykl. auf.

Beispiel:
Code:
// Aufruf des Funktionsbausteins 7 (Passive Aktionen)
CALL  "P_RCV_RK" , DB3 
       EN_R    :=TRUE         // Freigabe fuer Datenempfang
       R       :=FALSE         // Reset
       LADDR   :=272         // Quelladresse der Daten (HW-Addr CP341)
       DB_NO   :=
       DBB_NO  :=
       L_TYP   :=
       L_NO    :=
       L_OFFSET:=
       L_CF_BYT:=
       L_CF_BIT:=
       NDR     :=
       ERROR   :=
       LEN     :=
       STATUS  :=
Den FB8 rufst Du nur auf, wenn dein Programm Daten zur Gegenstelle senden soll.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
????

also irgendwie hab ich immer noch verständnisprobleme:

ich bin ja passiv. heisst das für mich ich rufe einmal den FB7 auf und bin fertig damit? Für Datenaustausch in beide Richtungen?

Gruß und Dank


c. mertens
 
mertens2 schrieb:
also irgendwie hab ich immer noch verständnisprobleme:

ich bin ja passiv. heisst das für mich ich rufe einmal den FB7 auf und bin fertig damit? Für Datenaustausch in beide Richtungen?

Gruß und Dank


c. mertens

Hallo,

wenn die Gegenstelle deiner SPS mit FETCH-Telegrammen (polling) von deiner SPS Daten liest, dann muss dein Programm im OB 1 nur den FB7 Aufrufen, um gesendete Daten von der Gegenstelle (per SEND-Telegramm) zu empfangen.

Den FB 8 benötigst Du nur, wenn dein Programm aktiv Daten zur Gegenstelle senden soll (z.B. Alarm, Triggerbedingung erfüllt etc.)

Gruss

bimota
 
Generell gibt es also 4 Übertragungsmöglichkeiten:

SPS aktiv - polling: SPS sendet Daten direkt an Gerät oder liest direkt aus Gerät, das Gerät benötigt keine SEND oder RECEIVE - Bausteine

SPS aktiv: SPS sendet Daten oder liest Daten, Gerät muss Daten mit SEND oder RECEIVE bereitstellen

SPS passiv: SPS erhält Daten oder Daten werden angefordert, SPS muss Daten bereitstellen oder diese aus Empfangspuffer lesen, SEND bzw. RECEIVE - Bausteine auf SPS und Gerät notwendig

SPS passiv - polling: Daten werden in SPS geschrieben oder von dieser gelesen, SPS muss keine SEND oder RECEIVE - Bausteine aufrufen


Verstehe ich das richtig?
Kann man irgendwie das verwendete Verfahren festlegen oder bei einem Fremdgerät per "auto - detect" feststellen, welches Verfahren dieses einsetzt?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Stimmt es, das es egal ist ob ich polling verwende oder nicht (bausteintechnisch gesehen)?

Bei polling rufe ich die Bausteine zyklisch auf und ansonsten nur bei Bedarf.

Ist das so korrekt?

Kann man irgendwie die Betriebsart (aktiv, passiv) des Verbindungspartners feststellen?
 
Ist für mich die Betriebsart überhaupt von Bedeutung oder kann ich immer die gleichen Bausteine verwenden?

Muss ich immer mit SEND und RECEIVE - Bausteinen arbeiten, unabhängig von der Betriebsart?

Wenn ich die Daten wieder mit RECEIVE aus dem Eingangspuffer lesen muss, wozu ist dann die Angabe des Ziels gut oder werden die Daten automatisch in das Ziel geschrieben?
 
Rk 512

Hallo,

In der CP-Doku wird immer von passiver und aktiver Kommunikation gesprochen

Ja, und genau da fehlt jetzt eine Information : Ist bei Deiner Frage damit die Einstellung in der Hardware-Konfiguration des Protokoll "RK512" beim CP341 gemeint ????

Wenn ja, dann vergesse alle bisher hier geschriebenen Beiträge ....

Bei RK512 hat diese Einstellung nur Auswirkungen auf den Protokollrahmen. Der passive Partner stellt im Kollisionskonflikt (d.h. beide Partner senden gleichzeitig) seinen Kommunikationswunsch zurück und antwortet auf das Telegramm vom aktiven Kommunikationspartner. Es sollte logischerweise also immer ein Partner "aktiv" und der andere Partner "passiv" eingestellt sein, sonst kann das Protokoll diesen Konflikt nicht auflösen.

Einen anderen Zusammenhang mit den Begriffen "aktiv" und "passiv" kenne ich beim RK512 nun mal überhaupt nicht.
Einige Antworten hier lassen vermuten, dass hier eine Verwechslung mit Begriffen aus anderen Protokollen vorliegen (wobei z.B. für einen empfangenen FETCH-Auftrag der Begriff passiv durchaus verständlich, bei RK512 aber nicht üblich ist).

Gruss

Question_mark
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Rk 512

Hallo,

wenn die Gegenstelle deiner SPS mit FETCH-Telegrammen (polling) von deiner SPS Daten liest, dann muss dein Programm im OB 1 nur den FB7 Aufrufen, um gesendete Daten von der Gegenstelle (per SEND-Telegramm) zu empfangen.

Ganz einfache Antwort : Für das FETCH-Telegramm ist dieser Aufruf nicht erforderlich. Der Aufruf wird nur benötigt, wenn die S7 auf eigene Initiative Daten per "SEND" verschicken will.

Ergo :

Ein FETCH-Telegramm wird ohne expliziten Aufruf eines Bausteines beantwortet. Basta...

Gruss
Question_mark

PS : Dies betrifft natürlich nur die hier angesprochene S7, bei der S5 trifft das nicht zu.
 
Zuletzt bearbeitet:
Danke,

also bei RK - 512 ist es mehr oder weniger egal wer aktiv und wer passiv ist, die Einstellungen greifen nur im Kollisionsfall.

Das Fremdgerät kann ohne RECEIVE - Baustein an der SPS Daten in die Ziele schreiben.

Der SEND - Aufruf wird nur benötigt, wenn die Steuerung auf Eigeninitative Daten senden will.

Verstehe ich das richtig?

PS: Ja, es ist das RK - 512 Protokoll beim CP341 in der Hardwarekonfiguration gemeint.
 
Rk 512

Hallo,

Question_mark schrieb:
Bei RK512 hat diese Einstellung nur Auswirkungen auf den Protokollrahmen. Der passive Partner stellt im Kollisionskonflikt (d.h. beide Partner senden gleichzeitig) seinen Kommunikationswunsch zurück und antwortet auf das Telegramm vom aktiven Kommunikationspartner. Es sollte logischerweise also immer ein Partner "aktiv" und der andere Partner "passiv" eingestellt sein, sonst kann das Protokoll diesen Konflikt nicht auflösen.

Da muss sich das kleine Fragezeichen doch erstmal selber korrigieren. Ich war zu faul, in das Handbuch zu schauen. Da habe ich dann mal ganz kurz zwei Begriffe durcheinandergeschmissen. Mein obiges Zitat bezieht sich auf die Einstellungen der Priorität im Protokollrahmen, hier heisst es richtig "high" und "low".

Gut dass es keiner gemerkt hat.... und wechducken ......

CrazyCat schrieb:
Das Fremdgerät kann ohne RECEIVE - Baustein an der SPS Daten in die Ziele schreiben.

Der SEND - Aufruf wird nur benötigt, wenn die Steuerung auf Eigeninitative Daten senden will.

Ja.

CrazyCat schrieb:
möchte zu einem Fremdrechner über RK512 kommunizieren. Der Fremdrechner ist aktiv. Ich möchte Daten in beide Richtungen übertragen.

Es ist im allgemeinen sinnvoll, dass sich der Fremdrechner über einen "FETCH"-Auftrag die Daten selber aus der SPS ausliest. Der Fremdrechner ist dann der aktive Partner. In der SPS braucht dann ausser der Hardwarekonfiguration nichts gemacht werden.
Konflikte entstehen, wenn beide Partner aktiv mit "SEND"-Aufträgen unkoordiniert auf der Verbindung rumhacken, das verursacht sporadische Konflikte, die auch das Protokoll nicht mehr auflösen kann.

Gruss

Question_mark
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mein obiges Zitat bezieht sich auf die Einstellungen der Priorität im Protokollrahmen, hier heisst es richtig "high" und "low".

High und Low sind Prioritätseinstellungen der Blockübertragungsprozedur 3964(R).
Die beiden kommunizierenden Geräte müssen dabei unterschiedliche Einstellungen haben.


Es ist im allgemeinen sinnvoll, dass sich der Fremdrechner über einen "FETCH"-Auftrag die Daten selber aus der SPS ausliest. Der Fremdrechner ist dann der aktive Partner. In der SPS braucht dann ausser der Hardwarekonfiguration nichts gemacht werden.
Konflikte entstehen, wenn beide Partner aktiv mit "SEND"-Aufträgen unkoordiniert auf der Verbindung rumhacken, das verursacht sporadische Konflikte, die auch das Protokoll nicht mehr auflösen kann.

Dasselbe gilt auch, wenn beide FETCHen.

Bei Kopplung zu einem PC kommt das aber normalerweise garnicht vor, denn der PC ist immer aktiv (oder es nenne mir jemand eine PC-Implementierung der passiven Seite, Soft-PLCs einmal ausgenommen).

Im allgemeinen tritt der Konflikt auch bei nur einem aktiven Partner auf, nämlich wenn es zu Übertragungsfehlern kommt. Gründe können sein: Kabel abgezogen, EMV Einstreuungen, SPS auf STOP oder ausgeschaltet etc.

Wichtig ist dann, dass anschließend wieder geordnete Verhältnisse herrschen.
Ich löse das dadurch, dass ich der SPS die 3964R-Priorität HIGH zuweise, dem PC LOW.

PS:
Ich weiß nicht, aber bei dem Begriff "Fremdrechner" schüttelt es mich immer, keine Ahnung warum...
 
Rk512

Hallo,

argv_user schrieb:
Konflikt auch bei nur einem aktiven Partner auf, nämlich wenn es zu Übertragungsfehlern kommt. Gründe können sein: Kabel abgezogen, EMV Einstreuungen, SPS auf STOP oder ausgeschaltet etc.

Kannst Du mir denn jetzt noch erklären, wie unter den Umständen
1) Kabel abgezogen,
2) SPS auf STOP
ein Konflikt mit der Kommunikation in Bezug auf die Priorität des Partners entstehen kann ???
Es findet unter diesen Umständen eigentlich keine Kommunikation mehr statt, wie kann da jetzt ein Konflikt entstehen :ROFLMAO:

Gruss

Question_mark
 
Rk512

Hallo,

argv_user schrieb:
High und Low sind Prioritätseinstellungen der Blockübertragungsprozedur 3964(R).
Die beiden kommunizierenden Geräte müssen dabei unterschiedliche Einstellungen haben.

Vielen Dank dafür, dass Du meine zuvor getroffenen Feststellungen bestätigt hast.

Gruss

Question_mark
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Rk 512

Hallo,

argv_user schrieb:
Bei Kopplung zu einem PC kommt das aber normalerweise garnicht vor, denn der PC ist immer aktiv

Im Idealfall ja, aber jeder depperte Programmierer kann ohne Probleme fälschlicherweise den PC gleichzeitig zum passiven und aktiven Partner machen. Er hat dann halt nur einige Probleme mit der Kommunikation :ROFLMAO: :ROFLMAO: :ROFLMAO:
Aber um solche Probleme zu beseitigen, bin ich ja da...

Gruss

Question_mark
 
Zuletzt bearbeitet:
Rk 512

Hallo,

argv_user schrieb:
Wichtig ist dann, dass anschließend wieder geordnete Verhältnisse herrschen.
Ich löse das dadurch, dass ich der SPS die 3964R-Priorität HIGH zuweise, dem PC LOW.

Wer die Priorität hat ist im Falle eines klar definierten und koordinierten Datenaustausches eigentlich sch...egal. Der von IBM (ja, da stammt das Protokoll im Ursprung her) definierte 3964R-Treiber kann nur eine Konflikttiefe über die Priorität im Faktor von 1 auflösen, danach funktioniert kein RK3964 und folglich auch keine Ableitung a la RK512 mehr...
Da hilft eigentlich nur, ein freundliches "NAK" an den Treiber und alles wird wieder neu initialisiert. Aber soweit sollte man es eigentlich nicht kommen lassen...

Gruss

Question_mark

PS : @Markus
Toller Effekt im IE 6.x : Meine Überschrift "RK512" wird vom Forumseditor ganz konsequent in "Rk512" umgewandelt. Bitte ganz genau die Zeichen im Quote lesen...
 
Das Problem ist nur das die Daten wahrscheinlich nicht direkt von der SPS gelesen werden können, sondern nur in diese geschrieben werden können.

Zitat: "Neue Einstellungen müssen vom Partner bereitgestellt und gesendet werden, diese werden nach der Ausführung des aktiven Prozesses übernommen"

Um einen SEND - Aufruf werde ich daher, vermute ich mal, nicht herumkommen.
 
Zurück
Oben