Gibts für den IP_CONTROL ein Beispiel

[mg]

Ich sollte eine Verbindung zum einem Gerät (Thermokon STC_Ethernet) aufbauen. Mit dem original-Wago Baustein stürzt mir die Verbindung zu oft ab. Nun täte ich das gerne über den IP_Control probieren:
Komm aber nicht richtig zurecht. Bei mir gibts immer SEHR viele Compilierfehler. Ich mache da sicher was falsch!

Danke

PS: Ich glaube inzwischen ich muß da noch zusaätzliche Datenstrukturen und Variablen einbinden. Nur wie weiß ich welche? Wo stehen die? (zB.: STRING_LENGTH:INT:=255 ... die habe ich mal herausgefunden)

[peewit]

mehr details

welche sps / Programmiersoftware verwendest du
welche schritte hast du schon unternommen
welche compilerfehler ?

tcp oder udp verbindung
welche seite baut die verbinung auf aktiv / passiv ?
welche portnummer

welche daten musst du austauschen

[mg]

Hallo peewit

Entschuldige daß ich SOOOO lästig bin. Aber ich stehe auf dem Schlauch ... aber nicht nur mit einem Fuss!

Regelstation: 750-871 (ist ident mit 750-841) derzeit mit einer etwas älteren FW aber das ist glaub ich mal egal.

a) welche schritte hast du schon unternommen: Inzwischen habe ich herausgefunden, daß ich für die network.lib auch die basic.lib brauche.

b) welche compilerfehler: wegen der fehlenden basic.lib hatte ich die 100derten compilierfehler.

c) tcp oder udp verbindung: Derzeit TCP und der Server ist das externe Gerät aber ich kann das ändern nach Lust und Liebe.

d) welche seite baut die verbinung auf aktiv / passiv: siehe c) ... Das externe Gerät baut die Verbindung auf. ==> Passiv mit IP-Adresse, die auf das externe Gerät zeigt. Auch das ist änderbar nach Lust und Liebe.

e) welche portnummer: Derzeit verwende ich Port 5000 aber auch das wäre einstellbar.

f) welche daten musst du austauschen: Ich emfange und sende Daten. Die Daten sind identisch mit dem EnOcean-Protokoll. Aber das hat schon mit dem original WAGO-Netzwerk-Exchange funktioniert. Das habe ich im Griff. Ein Datenpaket kann zum Beispiel so aussehen: A55A0B0700007515000392510000 derzeit habe ich Datenpakte mit konstanter Länge (26Bytes) aber ich passe das mal sicherheitshalber NICHT darauf an sonst habe ich mich für die Zukunft zu sehr festgelegt.
Die Umrechung der Bytes ist sehr gewöhnungsbedürftig, aber wie gesagt das funktionierte schon mal.  


Zusammenfassung:
Derzeit konnte ich zumindest das Ganze mal fehlerfrei kompilieren und downloaden. Ich versuchte das Ganze auch mal mit dem Beispiel aus dem oscat_netlib112_de.pdf Seite 100 aber da ging gar nix. Das habe ich im Moment wieder aufgegeben und halte mich an ein kleines Testbeispiel http://www.oscat.de/community/index.php/topic,862.0.html, das Du schon mal im Forum veröffentlicht hast (wie gesagt momentan ohne Erfolg der Controller hat noch kein Bit gelesen.)

Nachtrag: Inzwischen habe ich mir diesen doch älteren Beitrag weiter durchgelesen und stieß auf folgenden Eintrag von dir (11.2.2010 ... GILT DAS NOCH? und gilt das auch für die WAGO-Station?)
   Bekanntes Problem:
   Plattform: Codesys SP PLCWinNT 2.4 + syslibsockets.lib
   UDP Client + Server = läuft
   TCP SERVER = läuft
   TCP CLIENT = läuft nicht !

[peewit]

lästig  ?  nein kein problem

im anhang ist ein kleines beispiel
das programm versucht aktiv eine tcp verbindung mit dem angegebenen partner aufzubauen
und sendet einen text



für den datenempfang must du nur folgendes überwachen

R_BUF.SIZE :=   anzahl er empfangenen bytes im buffer
R_BUF.BUFFER[idx1] :=  hier kannst du alle empfangenen bytes auslesen
     

wenn du die daten verarbeitet hast dann solltest du
R_BUF.SIZE := 0 wieder machen
ansonsten werden alle empfangenen daten als stream aneinander gereiht, bis der buffer voll ist

damit kannst du entscheiden ob der datenempfang zeitüberwacht wird
IP_C.R_OBSERVE := FALSE; (* Datenempfang ueberwachen                      *)


[gelöscht durch Administrator]

[mg]

Hallo peewit

Ich bin's schon wieder ...  ::)

Ich habe das nun so gut es geht analysiert. (Bin noch nicht ganz fertig)
Die Sende-Daten werden vom Controller geschrieben. Das funktioniert!
Die Emfangsdaten-Daten werden zwar emfangen (zumindest gibt es bei der Netzwerkkommunikation keine grundlegenden Fehler) aber danach verschwindet das im Nirwana.
Ich habe nun den IP_Control mal genauer angeschaut. Zuerst ist mir da aufgefallen, daß es einen Datenpunkt gibt, der plc_841 heißt. Der ist bei mir zwar auch TRUE (ich nehme mal an, daß das bedeutet daß der IP_CONTROL einen sog. 841-Modus hat) aber ich will nur nochmals darauf hinweisen, daß ich einen 750-871 habe (Bis auf die 2. IP-Schnittstellen - ident mit dem 841)
Interessanterweise bekomme ich beim "Empfangen" von Daten bei Zeile 277: bytes_received := SysSockRecv(socket, ADR(R_BUF.BUFFER[r_offset]), r_count, 0); eine Meldung daß da was gelesen wurde (in meinem Fall 16#38 Bytes). Aber wohin der das schreibt habe ich noch nicht herausgefunden.

Danke Mario

PS: Heute abend analysiere ich mit eine Netzwerk-Profi nochmal die wire-shark-mittschnitte. Aber ich glaube nicht, daß es daran liegt.

[mg]

Hallo Peewid

... jetzt gehts ...

1.) R_BUF.SIZE ist der Offset im Puffer.  ??? Das ist SEHR suspekt.
Wenn R_BUF.SIZE:=1024 dann schreibt der Baustein ab R_BUF.BUFFER[1024] die Daten rein. Ich verstehe das zwar nicht warum das so sein soll, aber seihs drum.
2.) Aktiv bedeutet Client, Passiv bedeutet Server. Es wäre schön wenn das auch in der pdf-Beschreibung stehen würde. (... ist zwar richtig aber hat mich ganz gewaltig ausw dem Konzept gebracht)

Danke für Deine Hilfe ... morgen starte ich dann die Dauertests.

Mario

[peewit]

hallo

R_BUF.SIZE      sagt dir wieviele bytes im buffer sind


dass funktioniert folgend

1. eine verbindung wird eingerichtet
2. dann ist zuerst R_BUF.SIZE := 0    (also es befinden sich 0 bytes im buffer)
3. dann werden irgendwann daten empfangen
4. R_BUF.SIZE = xxx  (dann siehst du hier wieviele bytes im empfangsbuffer sind (mit index 0 beginnend)
5. dann solltest du diese daten verarbeiten, und danach R_BUF.SIZE = 0 machen

da man bei tcp nicht immer sicher vorhersagen kann wieviele daten in welche blockgroesse ankommen arbeitet
man hier im stream-modus

klassisches beispiel ist das laden eine http-seite
diese besteht aus zwei teilen (einen beschreibungsteil und einen datenteil)
manchmal steht aber im beschreibungsteil nicht drinnen wie gross die datenmenge sein wird.
dann kann man nur abwarten bis keine weiteren daten mehr kommen, und so erkennen das theoretisch alles empfangen wurde.
diese daten werden dann im streammodus im empfangsbuffer gesammelt (aneinandergreiht) und so zu einem einzelnen grossen
datenblock vereint. die neuen empfangenen daten werden an das ende der schon vorhandenen daten kopiert

das ist das was du entdeckt hast    ->   SysSockRecv(socket, ADR(R_BUF.BUFFER[r_offset]), r_count, 0)


wenn du z.b. 4000 bytes vom partner erwartest, dann können die daten in form von mehreren einzelnen paketen ankommen
das ist von vielen faktoren beinflusst

darum ist es notwendig dieses einzelnen pakete als datenstrom zu betrachten.
und deshalb werden ankommenden datenpakete prinzipiell aneinandergereiht (also gesammelt)
wenn du das so nicht benötigst , dann musst du einfach immer wenn R_BUF.SIZE > 0 ist (also daten vorhanden sind), diese daten im selbern zyklus verarbeiten und R_BUF.SIZE  danach wieder 0 setzen.


ja, das ist alles nicht so einfach
in der network.lib stecken einige hunderte stunden unbezahlte arbeit

aber mit dem IP_CONTROL haben ich eine lösung entwickelt, die einheitlich auf mehreren plattformen funktioniert
sowas ist einzigartig !!
keine andere bibliothek kann das

bin aber immer froh , wenn ich rückmeldungen bekomme.

danke

[mg]

Hallo pewid

Soll keine Kritik sein: Ich bin HEIL-froh daß sich jemand diesem Problem angenommen hat und ICH WILL DAS VERWENDEN!
Mehr Lob kann es für Euch/Dich eigentlich dafür nicht geben!

Mario

PS: und das mit dem .SIZE habe ich falsch verstanden: Bei der orig. WAGO-Lib konnte ich die maximale Sizegröße angeben somit meinte ich das seie hier auch so. Aber das ist hier VIEL intelligenter gelöst! Hier ist es ein Output-Zähler der gesendeten Daten. -> Jetzt erst verstehe ich das! Ist super einfach zum handhaben!

[Langen]

Hallo,

ich habe das Problem, dass ich Daten schreiben kann, aber nicht lesen.


welche sps / Programmiersoftware verwendest du:   
Moeller/Eaton/Micro Innovation XV-252-57MPN Zielsystem XV-2xx-V2.3.9 SP4,  SoftwareX: Soft Codesys 2.3.9 SP4

welche schritte hast du schon unternommen

IP Control integriert, kann von Xv- zu einem Server senden, Signale kommen dort an, aber von da kommt nichts. Testweise 2 identische Displax miteinander verbunden und versucht mit der selber Soft untereinander zu kommunizieren- NICHTS.

welche compilerfehler ?
Keine, immer wieder mal Error 0000FF00, Timeout Empfang


tcp oder udp verbindung
UDP


welche seite baut die verbinung auf aktiv / passiv ?
Server frsgt an, ich antworte, Versand von Byte-Array flexibel (wie Buffer) max 320 Byte, zum Testen nur ein Byte.

welche portnummer:

8760 Server-XV, Testweise Xv-Xv Port 1202

welche daten musst du austauschen
Flexibles Array of Byte senden, aktuell wird nur 1 Byte hin und zurück gesendet.


Daher erstmal die grundsätzliche Frage:

Kann ich den IP Control ohne weiteres dazu verwenden mit einer XV Die Daten vom Server zu empfangen oder gibt es dort etwas spezielles (ähnlich Beckhoff).

Gruss Stefan

[peewit]

öffne die network.lib selbst als projekt
dort gibt es einen ordner "demo" mit ausgeblendeten demo-programmen

deine sps dürfte keine der getetesteten varianten sein, somit ist es leicht möglich das die empfangsdaten nicht korrekt übernommen werden.

ein erster schritt wäre eine datenaufzeichnung mittels wireshark
damit kann ich sehen was am netzwerk wirklich passiert

[Langen]

Hallo,

das ging ja schnell ;).

Mit wireshark habe ich derzeit Null Erfahrung.  Über die NETVARUDP.lib konnte ich aktuell zumindestens die Grösse der Daten lesen.

Erster Erfolg... Somit scheint die Kommunikation an sich zumindestens was unser Firmennetz angeht, zu funktionieren.


Gruss