ISO-On-TCP zwischen CP343-1 und PC

[jeito]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wow, hier herrscht ja ein unfreundlicher Umgangston (Arroganz statt Ignoranz, Question_mark?)

Erst mal vielen Dank an argv_user für die Hilfe!

Ich programmiere erst seit ein paar Tagen mit Step7 und mit vielen Dingen und Begriffen noch nicht vertraut. Wenn ich auf einige Hinweise nicht eingehe, so habe ich sie nicht ignoriert, sondern konnte sie noch nicht umsetzen. Z.B. wie ich in der S7 an die Daten komme, die vom PC aus gesendet werden oder umgekehrt, wo ich die Daten ablegen kann, die ich an den PC senden will.

Auf der PC-Seite arbeite ich mit native TCP-Sockets (in diesem Fall Clients), von denen ich die Daten direkt abholen und auswerten kann. Das geht anscheinend in der S7 nicht. Werde mich wohl erst mal selber kümmern...

 

[Question_mark]

Das ist nicht mein Problem ....

Hallo,

Wow, hier herrscht ja ein unfreundlicher Umgangston (Arroganz kontra Ignoranz, Question_mark?)

Also mal ganz ehrlich, eine ganz grosse Menge der Forumsteilnehmer und der Admin/Moderatorenriege kennt mich persönlich und hat da kein Problem mit meiner Person und Persönlichkeit. Mich hat an diesem Thread einiges besonders gestört :

argv_user hat einige konkrete Fragen zum Problemfall gestellt, die wurden vom TE (also von Dir) komplett ignoriert. Trotzdem hat argv_user Dir nach einem intensiven Blick in seine frisch überholte Kristallkugel die richtige und kompetente Antwort gegeben. Die Du natürlich geflissentlich ignoriert hast.
Dann kommt da noch so ein Quatschkopf "F Ap" in das Spiel, der hier einfach kompletten Bödsinn verzapft. Und wenn ich auf diese Fakten hinweise, dann ist das eher Kompetenz als Arroganz, einverstanden ??

Gruß

Question_mark

 

[Question_mark]

Zuviel Werbung?
-> Hier kostenlos registrieren

PFffttt

Hallo,

Auf der PC-Seite arbeite ich mit native TCP-Sockets (in diesem Fall Clients), von denen ich die Daten direkt abholen und auswerten kann. Das geht anscheinend in der S7 nicht. Werde mich wohl erst mal selber kümmern...

Dann kümmer Dich mal darum. Es geht schon, aber ich weiss nicht ganz genau, wie oft das Rad schon erfunden wurde...
Und viel Spass beim Neuerfinden des ISO on TCP :s1:

Gruß


Question_mark

 

[PN/DP]

zum Thema

Hallo jeito,

bis jetzt hast Du schon viel richtig gemacht.

Die FC5 "AG_SEND" und FC6 "AG_RECV" müssen aufgerufen werden, um die Daten zwischen der CPU und dem CP343-1 auszutauschen.

LADDR :=W#16#100
Ist ganz normal, wenn der CP343-1 direkt neben der CPU steckt. Es ist einfach die Baugruppen-Anfangsadresse des CP343-1: E256 (dez) = 100 (hex) = W#16#100.

Was an ID und LADDR dranstehen muß, wird in Netpro angezeigt.
Besser: direkt im Bausteineditor aus einer Liste auswählen!
rechter Mausklick auf den Bausteinparameter ID oder LADDR
im PopUp-Menü -> Verbindungen

Der Einang ACT von AG_SEND muß nach Auftragsende für mindestens 1 Zyklus false sein (AG_SEND erwartet eine Flanke für einen neuen Sende-Auftrag). Dafür nimmt man praktischerweise den negierten Zustand des Ausgangs DONE.

[FONT=Courier New]UN    M20.0       //Neg. Merker an AG_SEND.DONE[/FONT]
[FONT=Courier New]=     L10.0       //TEMP-Datenbit von FUP/KOP automatisch vergeben[/FONT]
[FONT=Courier New]BLD   103         //für FUP/KOP[/FONT]
[FONT=Courier New]CALL "AG_SEND"[/FONT]
[FONT=Courier New]ACT :=L10.0      //Not M20.0[/FONT]
[FONT=Courier New]ID :=1[/FONT]
[FONT=Courier New]LADDR :=W#16#100[/FONT]
[FONT=Courier New]SEND :=P#DB111.DBX0.0 BYTE 6[/FONT]
[FONT=Courier New]LEN :=6[/FONT]
[FONT=Courier New]DONE :=M20.0[/FONT]
[FONT=Courier New]ERROR :=M20.1[/FONT]
[FONT=Courier New]STATUS:=MW21[/FONT]
[FONT=Courier New]NOP   0           //für FUP/KOP[/FONT]

"Aktiv" und "Passiv" beziehen sich bei ISO-On-TCP-Verbindungen nur darauf, wer die Verbindung aktiv aufbaut, meistens SPS=passiv, PC=aktiv.

Lokal-TSAP und Partner-TSAP: Ich gebe immer beiden den gleichen "Name" (TSAP (ASC)) nach dem Muster "PLC1-PCx" für mehr Übersicht bei vielen Verbindungen.

Verbindungs-Diagnose:
Im Simatic-Manager-Objektbaum rechter Mausklick auf den CP343-1 -> Zielsystem -> Baugruppenzustand
dort dann unten auf Schaltfläche "Spezialdiagnose" klicken
Im Fenster "NCM S7 Diagnose", was nun öffnet, kann man sehen, ob die Verbindung überhaupt aufgebaut wurde und ob Datenpakete gesendet und empfangen werden.

Du kannst OB1 und FC200 nicht in die CPU315-2DP laden? Ist die CPU schon älter?
Versuche mal den FC umzubenennen zu FC100 (irgendwas kleiner als 128 ).
Oder vergleiche CPU315-2DP -> Zielsystem -> Baugruppenzustand -> Reiter "Leistungsdaten" mit Deinem Programm (zu "hohe" Merker/Timer/Counter/FC/FB benutzt?).

 

[heisch]

Was aktiv und passiv ist, hat schon mit etwas mehr zu tun, als mit dem Verbindungsaufbau.

argv user hat's schon angesprochen, Question Mark auch, hat ja nix genutzt, also nutzt's auch nix wenn ich viel schreibe.

Die Prämisse war, dass die SPS passiv ist.

Aber damit nicht das Falsche dabei rauskommt, solltet Ihr vorab mal klären:

Was ist Send und Receive, was ist Fetch und Write ?
Welche von beiden gehören zur Serverfunktionalität?

Zur Verdeutlichung:
Client ist aktiv: "Hallo Frollein, den DB 65 bitte".
Die Server(in) ist passiv: sie entscheidet nicht von sich aus, welchen DB sie liefert.
Es steht der Server(in) trotzdem frei, den Verbindungsaufbau zu initiieren
( Tach, Woll'nSe was bestellen ?), dennoch bleibt sie die Server(in).

Noch'n Tipp:
Es ist aber einfacher rechnerseitig zu programmieren, wenn der Client den Verbindungsaufbau auch erledigt ( Hallo Frollein, die Karte bitte)

FETCH / WRITE ( S5-kompatible Kommunikation) setzt ein beidseitig bekanntes Protokoll voraus, deshalb funktioniert das Ganze auch ohne Software in der CPU, da der CP schon erkennt, was er tun muss.

Gleiches gilt auch für PUT und GET (S7-Kommunikation).

Ihr müsst also ein vorgegebenes Protokoll realisieren, wenn die S7 passiv sein soll.


Oft wird auch von S7-Kommunikation auch als RFC1006-Kommunikation gesprochen, das ist aber Nonsense.
RFC1006 ist nur eine zusätzliche Verpackung, mit der die (ehemaligen) ISO-Protokolle (Paket-orientiert) so verpackt werden, dass sie auf dem Bytestrom TCP als erkennbare Blocks ankommen.
Zwar ist die S7-Kommunikation per Definition RFC1006-verpackt, aber Gleiches geht auch mit der S5-Kommunikation und eigentlich jedem beliebigen Datenblock.

Meine Homepage //sites.inka.de/heisch betrifft eigentlich nur die Linux-Fraktion, aber das eine oder andere ist dort unter know-how bzw. im Handbuch des rktcp_servers (in rkx_demo) erklärt.
Im Quickstart sind auch ein paar Hinweise zur HW-Konfig beim Aufbau mit der S5-Kompatiblem Kommunikation.

Gruss Werner

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zu jeito:
für ISO-on-TCP
* Send/Receive ist richtig gewählt
* Senden und Empfangen auf der selben Verbindung
* in Step7 gibt es eine ausführliche Hilfe, auch für AG_SEND
(Cursor auf CALL "AG_SEND" -> F1 -> Industrial Ethernet -> siehe auch -> Formalparameter)

Falls Du mit "die S7 soll der passive Teil sein" tatsächlich meinst, der Datenaustausch soll ohne aktives Zutun deines SPS-Programms laufen, dann muß Du ein anderes Protokoll wählen, ähnlich wie OP/Visu-Verbindungen. Diese "passiven" Verbindungen werden nicht in Netpro projektiert.

Zu argv_user #10:
Woher soll der CP wissen, welche Daten er senden soll und wohin er die Empfangsdaten legen soll?
Genau dafür sind AG_SEND und AG_RECV. Hier werden die Quell/Ziel-(DB-)Adressen angegeben.

Und zu einigen "Erfahrenen Benutzern" (will ich als "Neuer" hier nicht namentlich nennen):
Zur Frage des TE sollte sich besser nur jemand äußern, der die Frage des TE verstanden hat und mit ISO-on-TCP wirklich praktische Erfahrung hat.
Das erspart so einige Emotionen ...
Fundiert und zielführend finde ich nur die Beiträge von Grubba und F_Ap.

Ich lese hier im HG schon länger, habe auch schon oft den Kopf geschüttelt über so manche hahnebüchenen Tips, aber daß Question_mark derart "kompetent" hochgeht und wie er Threatteilnehmer betitelt, die die Frage des TE anders verstanden haben als er ... PFffttt

 

[Paule]

Ich lese hier im HG schon länger, habe auch schon oft den Kopf geschüttelt über so manche hahnebüchenen Tips, aber daß Question_mark derart "kompetent" hochgeht und wie er Threatteilnehmer betitelt, die die Frage des TE anders verstanden haben als er ... PFffttt

Ist ja toll dass Du Dich endlich einbringst und nicht nur den Kopf schüttelst wenn Du schon alles weißt

 

[Ralle]

Ok, ich hoffe, ihr habt das nun geklärt und geht wieder zum Thema über.

@qm
Ich denke, man darf auch mal was falsch machen, sowohl als Fragesteller, als auch beim Antworten. Keiner soll Angst haben, sich hier zu äußern. Wenn jemand eine falsche Antwort gibt, kann man das sicher auch ein wenig freundlicher rüberbringen. Allerdings, bei nicht lernfähigen Zeitgenossen, darf es dann auch deutlicher sein. Den Fall hatten wir hier aber sicherlich nicht!

 

[jeito]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke an PN/DP und heisch für die ausführlichen und auch amüsanten Tipps !

Ein paar Hintergründe zu meinen Fragen:
Das mit "PC=aktiv" und "S7=passiv" war eine Projektvorgabe: ich programmiere einen embedded Controller unter VxWorks, der nur über einen Ethernet-Port mit der "Außenwelt" verbunden ist. Darüber soll er gesteuert werden (in diesem Fall von einer S7) und auch Messdaten senden (an die S7). Die S7-Umgebung ist Neuland für mich. Es geht mir hier nur um den Datenaustausch von Steuer- und Messdaten, die ich irgendwie simulieren, d.h. auch verändern muss.

@PN/DP:
Die Aktivierung des AG_SEND über eine Flanke hat mich schon ein Stück näher gebracht. Laut CP-Diagnosetool wird die Verbindung aufgebaut und auch Daten gesendet und empfangen. Allerdings werden nicht die aktuellen Sendedaten zum PC übertragen. Erst dann, wenn der Client die Verbindung unterbricht und wieder neu aufbaut. Auch auf Gefahr von "Erfahrenen-Prügel": muss bei zyklischem Datenaustausch die Verbindung vom Client jedesmal neu initialisiert werden?

@heisch:
D.h., der Client muss wissen, welchen DB er aus der S7 ausliest, wenn er Daten anfordert? Dazu müsste ich die Speicheradresse wissen und bei der Anfrage mitsenden (ähnlich wie bei Modbus). Falls ja, wie funktioniert sowas?
Zu deiner Homepage: Arbeiten deine convert_lib mit dlls (wie libondave) oder könnte ich den Code auch für VxWorks-RTOS verwenden?

@Question_mark:
du kannst mir gerne helfen, ein passendes RFC1006-Rad für meinen embedded Controller zu finden, der ohne externe Gateway-HW läuft. Dann brauche ich das Rad nicht neu zu erfinden.

 

[argv_user]

@heisch:
D.h., der Client muss wissen, welchen DB er aus der S7 ausliest, wenn er Daten anfordert? Dazu müsste ich die Speicheradresse wissen und bei der Anfrage mitsenden (ähnlich wie bei Modbus). Falls ja, wie funktioniert sowas?

Ja, der Client muss wissen, auf welche Daten er zugreifen will.
"Speicheradressen" sind in diesem Fall zB: DB-Nummer, Startadresse, Länge.

Welche RFC-1006-Implementierung auf PC-Seite verwendest Du denn?
In der Regel gibt es da Funktionsaufrufe, denen man Parameter übergibt.
Details hierzu findet man in der zugehörigen Dokumentation, manchmal
hilft auch F1.

Bitte hau mich nicht:
Momentan sieht es so aus, als hättest Du zwar eine Bibliothek, nur
noch nicht ins Handbuch geschaut.

 

[jeito]

Auf der PC-Seite verwende ich die 10 ISO8073-TPDUs (preferred Class 0). Die entsprechenden Sequenzen für "open request", "connection request", "data exchange" und "close connection" mit den zugehörigen Fehlerbehandlungssequenzen habe ich aus dem Siemens-Handbuch übernommen, jeweils für PC->S7 und S7->PC.

@argv_user:
Danke für den Hinweis! Jetzt dämmerts bei mir auch, dass die TSAP-Adressierung in den TPDU-Headern alleine nicht ausreicht, um die Daten aus der S7 auszulesen. Bitte auch nicht hauen: Ich hatte in der Tat den ersten Teil im Handbuch "Send/Receive-Schnittstelle" etwas flüchtig durchgelesen und mich mehr auf die Sequenzen gestürzt. Jetzt wird mir auch klar, dass man durch die entsprechende DB-Adressierung u.U. auch die FC5 und FC6 bei "S7 passiv" weglassen kann, wie es anfangs von dir vorgeschlagen wurde.

 

[heisch]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo jeito

> Ein paar Hintergründe zu meinen Fragen:
> Das mit "PC=aktiv" und "S7=passiv" war eine Projektvorgabe: ich
> programmiere einen embedded Controller unter VxWorks, der nur über
> einen Ethernet-Port mit der "Außenwelt" verbunden ist. Darüber soll er
> gesteuert werden (in diesem Fall von einer S7) und auch Messdaten
> senden (an die S7). Die S7-Umgebung ist Neuland für mich. Es geht mir
> hier nur um den Datenaustausch von Steuer- und Messdaten, die ich
> irgendwie simulieren, d.h. auch verändern muss.

OK, jetzt wird' klarer

Die S7 kommandiert, der Controller soll was tun.
In diesem Fall würde ich die S7 zum client und den Controller zum Server machen.

Ich denke auch, Du ersparst Dir einiges wenn Du in diesem Fall trotzdem Send-Receive nimmst, denn dann brauchst Du keines der Server-Protokolle zu realisieren sondern kannst einfach Rohdaten schieben.
Was darin steht, ist dann deine Sache und Du kannst sie interpretieren wie Du willst. ( Eine Sende-Anforderung für Parameter xx, z.Beispiel, also quasi ein Fetch )

Wichtig: Verpasse den Daten einen Header, damit Du sicher bist, was Du bekommst. ( Kein Mensch mit klarem Verstand würde eine Multiprozessing-Kommunikation ohne timeout programmieren - Siemens hat's getan.
Irgendwo hier läuft eine Parallel-Diskussion zum Thema variable Datenlänge, sollte für Dich auch interessant sein. )

Auch hier der Vorteil von S7 als Client (per Send): Wenn die S7 beim Controller 20 Bytes bestellt hat, dann erwartet sie eben .. 20 Bytes - womit das Telegrammlängenproblem beim Receive gelöst wäre.

> @heisch:
> D.h., der Client muss wissen, welchen DB er aus der S7 ausliest, wenn er
> Daten anfordert? Dazu müsste ich die Speicheradresse wissen und bei der
> Anfrage mitsenden (ähnlich wie bei Modbus). Falls ja, wie funktioniert
> sowas?

Jow, genau so. argv user hat's schon geschrieben:
Du forderst z.B. einen DB, beginnend ab byte 4 Anzahl 20 Bytes an.
Oder : Schreibe die folgenden Daten nach DB 12, beginnend ab byte 4 Anzahl 20 Bytes, <daten >

Die entsprechenden Protokolle, in die das verpackt wird, sind das S7-Protokoll bzw. das S5-kompatible Protokoll.

S5 -.. scheidet aus, denn das können die aktuellen CPs nur als server, bleibt also das S7-Protokoll .. und das ist nicht offengelegt, mußt Du also re-engineeren.
Deshalb (s.o.) : bau Dir für den o.a. Zweck lieber selbst ein Protokoll, das geht mit Sicherheit schneller.

> Zu deiner Homepage: Arbeiten deine convert_lib mit dlls (wie libondave)
> oder könnte ich den Code auch für VxWorks-RTOS verwenden?

Die convert_lib liefere ich als C-quellcode, sollte also gehen, wenn dein C-compiler nicht all zu rudimentär ist.
( Vor Jahren haben wir sie mal aus Jux im C-Builder eingebaut, es mußten nur die Bibliotheken-includes angepasst werden.)


Gruss Werner

 

[Question_mark]

?

Hallo,

bleibt also das S7-Protokoll .. und das ist nicht offengelegt, mußt Du also re-engineeren.

Aber den Begriff "LibNoDave" hast Du doch schon mal irgendwo gelesen, oder ?

Gruß

Question_mark

 

[heisch]

Hallo,



Aber den Begriff "LibNoDave" hast Du doch schon mal irgendwo gelesen, oder ?

Gruß

Question_mark

Jow, da kann er's auch raus-engineeren.

Gruss Werner