S7-200 mit Ethernet CP - Kann diese eventgesteuert Socket?

A

Anonymous

Guest
Zuviel Werbung?
-> Hier kostenlos registrieren
Hy, ich habe eine:
6ES7 212 1BB22-0XB0 .... CPU222
und
6GK7243-1EX00-0XE0 .... CP243-1
abgesehen das die beiden noch nicht miteinander reden (anderes Problem) möchte ich mit diesem Aufbau aufgrund eines Events (Eingangsflanke) einen Socket auf eine / bzw. zwei IP Adressen machen. Dort kann ich dann das Signal weiterverarbeiten (Java Programm).

Geht so etwas??

Danke vorab
 
Suche mal im Forum nach libNoDave. Darin ist beschrieben wie es geht. Ist etwas umfangreicher das Thema - musst' Dich auf jeden Fall etwas mit der S7-Kommunikation auskennen.
Berthold
 
Zuviel Werbung?
-> Hier kostenlos registrieren
logout schrieb:
Suche mal im Forum nach libNoDave.
Na ja, in der Frage ging es doch wohl um"eventgesteuert", also sollte die SPS die Initiative zur Kommunikation ergreifen. Gerade das geht mit Libnodave nicht. Du kannst halt "nur" Variablen der SPS abfragen, die kann dir aber keine Änderung mitteilen.
Ist etwas umfangreicher das Thema - musst' Dich auf jeden Fall etwas mit der S7-Kommunikation auskennen.
Berthold
Das wiederum musst du gerade nicht. Du mußt nur eine Funktion aufrufen in der Art: "Gib mir die Werte von Merkerwort 10 bis 20"
Libnodave
http://libnodave.sf.net
ist für C und Pascal verfügbar.
Wenn du JAVA möchtest, schreib eine PN mit deiner e-mail-Adresse und du kannst den gegenwärtigen Stand der pure JAVA Version bekommen.
 
zottel schrieb:
Na ja, in der Frage ging es doch wohl um"eventgesteuert", also sollte die SPS die Initiative zur Kommunikation ergreifen. Gerade das geht mit Libnodave nicht. Du kannst halt "nur" Variablen der SPS abfragen, die kann dir aber keine Änderung mitteilen.

... ist natürlich richtig,
jetzt hatte ich aber, weswegen ich auf die S7-Kommunikation verwies und es nicht weiter auswalzte, begonnen libNoDave in einen Clienten (auf dem PC) zu 'verpacken' der lediglich darauf wartet zu versuchen gesendete CPU-Daten zu 'entschlüsseln'. Aus dem Grunde schrieb ich: 'In libNoDave ist alles Notwendige beschrieben'.
Und das funktioniert - ohne viele der näheren Hintergründe (CPU-Adr. Auswertung, ACKs etc.) bisher zu kennen war es möglich mit Xput/ XGet von der CPU versandte/ angeforderte Telegramme 'auszu(ver)packen'.
Lief allerdings über einen CP243-1IT. Unterschiede zum 243-1 kenne ich (praktisch) nicht kann da nur ansatzweise die HB's vergleichen.
Was ich auch noch nicht kenne ist die Aufschlüsselung der (als zeiger) mitverpackten CPU-Adresse. Ich baute bisher nur 1:1 die (S7)-Kommunikation zwischen zwei CPUs nach. Denke mir die wird dann (wohl intern ?) über den CP auf Ethernet umgeleitet. Das Ganze probiere ich ohne Token etc. weitere Beachtung zu schenken.
Wenn ich den Eingang der CPU (226 mit CP243-1IT) setze erscheint über XPut eindeutig zugehöriges Ausgangsbyre ('EB0 == AB0') zu 98% richtig auf den screen des (Linux-)Pcs.

Da ich diese XPut/ XGets erstmalig im Zusammenhang mit den 200-ern über den CP243 entdeckte suchte ich eigentlich nur danach was ein 'gefälschter' Pointer auf die (MPI) Adresse anrichten würde. Dabei stellte ich fest das eine Art 'MasterSender' (vergl. Netw/ Netr) über TCP/IP so evtl. funktionieren könnte. Weiss aber auch nicht wie/ wo überhaupt eine IP_Adresse des Zielrechners eingegeben werden müsste bzw. entstehen kann. Das denke ich bezieht sich auf die 'S7' (ProfinetGlobaldaten' osä)-Kommunikation. Irgendwo muss der TCP-Header ja entstehen - denn 'dran' ist ja einer.
Berthold
 
logout schrieb:
jetzt hatte ich aber, weswegen ich auf die S7-Kommunikation verwies und es nicht weiter auswalzte, begonnen libNoDave in einen Clienten (auf dem PC) zu 'verpacken' der lediglich darauf wartet zu versuchen gesendete CPU-Daten zu 'entschlüsseln'.
Ist die PC-Anwendung dabei der einzige Kommunikationspartner oder hört sie die Kommunikation zu dem eigentlichen Partner mit?
Und das funktioniert - ohne viele der näheren Hintergründe (CPU-Adr. Auswertung, ACKs etc.) bisher zu kennen war es möglich mit Xput/ XGet von der CPU versandte/ angeforderte Telegramme 'auszu(ver)packen'.
Bei ISO over TCP gibts auch keine ACK oberhalb des TCP Levels. Erfolgt innerhalb von TCP und daher für eine Anwendung, die sockets (und nicht "raw packets") benutzt, unsichtbar.
Lief allerdings über einen CP243-1IT. Unterschiede zum 243-1 kenne ich (praktisch) nicht
Sollte m.E. keine geben. Ist die -IT-Version voll abwärtskompatibel?
Was ich auch noch nicht kenne ist die Aufschlüsselung der (als zeiger) mitverpackten CPU-Adresse. Ich baute bisher nur 1:1 die (S7)-Kommunikation zwischen zwei CPUs nach. Denke mir die wird dann (wohl intern ?) über den CP auf Ethernet umgeleitet. Das Ganze probiere ich ohne Token etc. weitere Beachtung zu schenken.
Wenn ich den Eingang der CPU (226 mit CP243-1IT) setze erscheint über XPut eindeutig zugehöriges Ausgangsbyre ('EB0 == AB0') zu 98% richtig auf den screen des (Linux-)Pcs.
Dein Programm würde mich interessieren. Willst du es offenlegen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
zottel schrieb:
Ist die PC-Anwendung dabei der einzige Kommunikationspartner oder hört sie die Kommunikation zu dem eigentlichen Partner mit?

Mangels zweiten CPs blieb der PC bisher einziger Kommunikationspartner. Somit fehlt noch jeder (Paket) Vergleich CPU&CP : CPU&CP.

Das zudem vollständig abgeleitet von einem vorherigem Aufbau (der hier eben beschrieben sein will) zweier CPUs.
Eine CPU 222 mit lediglich Kontrollampen an den Ausgängen und 6Tastern am Eingangsbyte
dazwischen einige 100m '2-Draht-Bus' (Telefonkabelader) zur dort direkt verbundenen CPU 214. An der sich ausgangsseitig 6Relais befinden. Eingangsseitig auch dort wieder 6Taster/Kontrollampen.
Die Kontroollampen an der CPU222 waren (aufgrund der Entfernung) einzige Rückmeldung der 214 und _musten_ den tatsächlichen stand anzeigen egal von wo aus dadranrumgeschaltet wurde. Über NetW/ NetR sind beide CPUs 1:1 gekoppelt. Andere 'Verbraucher' gibts da nicht- das lief störungsfrei über 1Jahr, war allerdings absolut schlecht, bis unmöglich bei Bedarf umzuprogrammieren. Die Dauerkommunikation blockierte jede möglichkeit eines PC_PG-Eingriffs . Es musten erst beide CPUs von Hand durch Einrasten des Betriebsartenschalters gestopt werden ...

Aus dem Grunde wurde es auf eine Kombination CPU313C und CPU214 übertragen. In der 'Formation' funktioniert an der 300 ja der MPI-Adapter mit Zugriff auf die 200 anscheinend, womit jederzeit ein 'Einlenken' (vom PC als PG aus) möglich war.
(Das natürlich nur sofern zufällig richtig in Step7 'projektiert' - was 'ne riesen Fummelei war, da nirgends das WIE beschrieben war und jeder sofort drauf kommt das die S7-200 bei Siemens unter ' Steuerung anderer Hersteller läuft .....' .)
Bei diesem Aufbau kamen erstmals XPut/ XGet zum Tragen.

Soweit der Ausgangspunkt - stur daran entlang wars nun den Versuch wert über Ethernet zuverlässig eine Rückmeldung der Relaisstellung an der 200-er zu erreichen. Da es für die 21x keine CP243-x gibt wich die 214 einer 226.

Von daher vermute(te) ich einen Zusammenhang als in der neuen Version von MicroWin (4.x) plötzlich XPut/ XGets auftauchten. Das probierte ich mit der 226 + CP aus bis eine Verbindung (zum PC) entstand. Alle verwendeten Parameter entnahm ich der S7-Kommunikation 313C mit 214 . Die PPI-Adresse der 214 || 226 blieb mit '9' dabei unverändert.


Dein Programm würde mich interessieren. Willst du es offenlegen?
Selbstverständlich -
mit Ausnahme des Servers und die versuchte Portansteuerung (LPT) ist alles aus der lib. zusammengesucht. Ist auch kein 'Programm', mehr skriptmässig untereinandergenagelt bis dieser Fall ging. Benötigee dazu nun etwas Vorlauf den Aufbau wieder zusammenzustecken. Wer mich jetzt nämlich fragt auf welchen (TCP)-Ports das lief oder ob/ welche 'Startparameter' da noch übergeben werden mussten könnte ichs auch nicht sagen. Blieb prompt vor wochen liegen nachdem ein CP56xx in den PC operiert wurde der vollständig alle Neugier band. Das hat so garnichts miteinander zu tun bloss vergisst man den ganzen Kleinkram wieder. Ich geh da aber schnellstmöglich bei.

Berthold
 
Zurück
Oben