Nachrichten

31

oscat.lib fuer CoDeSys 3 / Stream reader ...

« am: 25. November 2014, 19:44:07 »

Hi,

gibt es was im Oscat repository wie man einen Strema bis zu einem angegeben Zeichen lesen und entsprechend umkopieren kann?

Ich finde da nix oder muss ich mir dann doch das selber bauen?


Danke


MacToolz

32

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 24. November 2014, 12:21:48 »

Hi,

na da steht aber doch verdammt viel drin, genau das was man erwartet :-).
Ich weis was du meinst. Der Stream ist aber genau richtig.

Die Zeitliche Ababreitung ist aber ja falsch weil ich ja nicht direkt mitloggen kann, wie du schon gesagt hast, wegen dem Switch.
Ich wollte nur die Inhalte mal zeigen.

Wie schon erwähnt, die Kommunikation über TCP IP ist genau so wie man es erwarten würde. Das Verhalten oder eher mein Test habe ich ja beschrieben.
Trotzdem würde mich interessieren wieso das sich nicht bei diesem Cliebt so verhält.

Ich werde mir einen Hub besorgen und dann nochmal den WireShark Log posten.
Dann schauen wir nochmal.


MacToolz

33

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 22. November 2014, 23:26:42 »

Hi,

also 192.168.182.33 ist der EQ3 Client
192.168.182.38 ist mein PC.
192.168.182.11. die SPS
192.168.182.45 die VmWare

Ich hatte aber erwähnt das meine SPS nicht zu sehen ist, daher der Mitschnitt vom PC aus. Ich kann dir nicht sagen warum ich keine Kommunikation zwischen SPS und EQ3 mitschneiden kann.
Auf dem Port 62910 wird der Socket aufgebaut.

Aber es wird irgendwie am Anfang über UDP ein Port gesucht usw. um den Port rein theoretisch nach außen zu verschleiern, das man grundsätzlich
nur über die Hersteller Domain sich einloggt oder eine App.

MacToolz

34

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 20. November 2014, 23:18:04 »

Hi,

also ich denke wir können da reden wie wir wollen. Ich habe folgendes getan und es verhält so wie man es erwartet.
Der Client zu dem ich ein Socket aufbaue verhält sich irgendwie wie das UDP Protokoll.

Mit dem Aufruf SysSockRecv ist entsprechend vom Client ein Paket abgerufen worden und wird vermutlich mit diesem Aufruf auch quittiert.
Alles andere macht eigentlich auch keinen Sinn.

Der Client sendet eine gewisse Größe als Paket raus. Die Steuerung ruft mit SysSockRecv die Daten ab. Wenn die Daten im Puffer mit SysSockRecv im Puffer gelandet sind ist das die Quittierung die über das Zielsystempezifische System läuft.

Das habe ich folgendermaßen so getestet. Ich habe mir aus dem Netz eine TCP Server besorgt, habe wie wir das schonmal angedacht haben, mit dem Mailbox[3] Byte den nächste Aufruf blockiert.
Habe das Rücksetzen von dem Mailbox[3] Byte seitlich verzögert, z.B. 2s. Auf der TCP Server Seite kann ich Daten senden auf Knopfdruck.

Ich habe mal 100 Zeichen eingegeben. Jetzt Pole ich Zyklisch den SysSockRecv ab, die ersten 100 Byte kommen, dann 2s verzögert wird die Blockierung wieder aufgehoben.

Aaaaaber, innerhalb dieser 2s drücke ich mehrfach hintereinander das Senden auf der TCP Server Seite, siehe da, 5x gedrückt bedeutet jetzt nicht mehr 100Byte Daten, sondern 500Byte Daten.
Dabei lösche ich auch jedes Mal aufs neue das "Size" aus dem Empfangsbuffer ab.

Mache ich genau das gleiche mit dem EQ3 Client, funktioniert das nicht. Das sieht so aus als würde er sich um die Quittierung nicht mehr Kümmern, was aber nicht auf TCP/IP Protokoll Ebene gehen kann.

So ganz verstehe ich den WireShark nicht. Oben sind zwei Pakete mit dem UDP Protokoll zu sehen, aber dann kommen TCP Pakete.
Was sagt mir das jetzt.

MacToolz


[gelöscht durch Administrator]

35

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 20. November 2014, 21:41:06 »

Hi,

also ich kann machen was ich will. Der Wireshark läuft, alle Netzwerkteilnehmer sehe ich und kann auch entsprechend die Filter setzen.
Nur meinen EQ3 Cube sehe ich nicht. Daten und verwertbare Daten kommen aber in die Steuerung rein.

Jetzt stellt sich die Frage liegt das am Switch, aber andere Teilnehmer sehe ich alle, oder liegt es eher daran das ich mein CoDeSys V3 in der Virtuellen Maschine laufen habe???

Trotz alle dem, lasse ich den Wireshark laufen wenn ich mit der HErsteller Software über dem Browser drauf gehe, sehe ich genau die Daten im Wireshark, genau die gleichen wie in der Steuerung.
Frage bleibt, wie fange ich die Daten kontrolliert ein.

Nochmal zu Erinnerung, nicht das der Faden verloren geht.
Mit kleinem Puffer kein Problem, mit großem ist das Problem vorhanden?

Beides der gleiche Ablauf in der Steuerung???


MacToolz

36

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 19. November 2014, 22:16:45 »

Nabend,

also der EQ3 sprich Maxcube bringt Daten von einem Heizungssystem. Das heisst es gibt Thermostate, Wandthermostate und Fensterkontakte.

Das Gateway dazu ist so zusagen die Schnittstelle zwischen Ethernet Funk von allen Geräten innerhalb dieses Heizungssystems.
Wie gesagt sobald der Socket auf ist, sendet der Client alles raus was er aktuell an Informationen hat.

Wie schaltest du den "Non-blocking mode", wo und wie passiert das.

Es gibt ja einenfertige Funktionnfür einen Sende und Empfangsvorgang dem Betriebssystem sprich dem Client mitteilen zu können aber das Funktioniert auf dem Koppler und der RTE nicjt. Warum auch immer.

Was und wie müsste ich denn jetzt mit dem Non-blocking mode umgehen.


MacToolz

37

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 19. November 2014, 09:21:39 »

Morgen,

der client ist von der Firma Eq3 (MaxCube).

Also ich bin zu dem Entschluss gekommen, das der Client viel schneller ist als ich mit meiner SPS Task, wobei meine Task auf eine 1ms gestellt ist.
Wenn 8000 Byte zur Verfügung stehen dann versucht er die dort rein zu schreiben. Da ich zwar selber das "Size" für den Puffer ablösche,
schafft der Client es trotzdem noch Daten zu schreiben.

Trotzdem bin ich verwundert das dass SysSockRecv ja ein Synchroner Aufruf an das Betriebssystem ist. Der Client aber trotzdem weiter
an die Adresse vom Puffer schreibt, solange der nicht voll ist.
Weil es wird ja niemand dem Client sagen hör mal gerade auf Daten zu senden. Sondern das Betriebsystem kümmert sich auf TCP IP Basis darum wie viel dort rein geschrieben werden kann.

Das sieht so aus das ein einmaliger Aufruf von SysSockRecv dazu führt das dass Betriebssystem auf dem Socket Daten holt und
das Asynchron und solange bis der Puffer voll ist.

Wähle ich einen kleinen Puffer dann funktioniert die Sache. Den Puffer habe ich mal so gewählt weil er nie Daten unter 100Byte sendet.
Das wäre eine Lösung in Bezug auf diesen Hersteller.

Oder liegt es eventuell doch eher an meinem Wago Ethernet Kopper 750-880?

MacToolz

38

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 18. November 2014, 23:14:10 »

Hi,

was meinst du mit Kommunikation genau?

Doch mein Size ist Null, garantiert, alles schon geprüft.


MacToolz

39

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 18. November 2014, 20:45:22 »

Hi,

ich denke das habe ich jetzt im Griff.

Ich bin der Meinung, und das habe ich auch nachgestellt, das wenn der Puffer entsprechend groß gewählt wird, dann wird dieser auch im vollen Umfang befüllt solange Daten kommen.
Das heißt ich muss meinem Puffer klein stellen. Zu einem das intern in der IP_Control der Überlauf eh überwacht wird und das "Size" selber abgelöscht wird,
zum anderen, darf man eigentlich immer bis in die Puffer Grenze laufen. Macht das überhaupt Sinn?

Mir fehlt immer noch das Verständnis wie auf TCP IP Ebene das Abrufen von Daten statt findet. Ich sehe momentan keine schlüssigen Weg für mich.

Was ich auf jeden Fall festgestellt habe ist, das der Client an dem ich mich anmelde und dann den Puffer sehr groß wähle, das er selber in seiner Verarbeitungszeit unterschiedlich große Pakete
in den Puffer sendet.

Was ich gerade selber noch in den Baustein als Test implementiert habe ist,
das wenn ich das Mailbox[3] Byte zum blockieren nehme, da habe ich dann eine neue Methoden Aufrufe genommen die das Betriebssystem anweist
das kein Sende/Empfang Kommunikation zugelassen ist.

--> SysSockShutdown(server_socket, 0);
--> halbes Kommando zurück, diese Funktion ist Systemspezifisch und funktioniert z.B. bei der Wago 750-880 nicht. Andere Zielsysteme wie PLCWinNT habe
 ich nicht getestet weil ich zu faul bin. BEi der 750-880 und der RTE kommt vom Shutdown nicht die Rückmeldung das er das ausgeführt hat !!!

Damit funktioniert das ganze meiner Meinung nach besser und flüssiger, ohne das ich selber dann in meinem Code was zusätzlich als verriegelung machen muss,
außer das Byte in der Mailbox zum blockieren zu bringen

Ich bin mal auf deine Antwort gespannt.


MacToolz

40

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 18. November 2014, 10:56:21 »

Hi,

also ich verwende das TCP Protokoll. Die Daten sind aus dem Zeichensatz Base64. Aber das wäre doch nicht ganz so wichtig oder.
Ist doch alles Byteorientiert.

Für mich sieht das so aus als würden auch noch Daten kommen, nachdem ich wieder die Freigabe für das SysSockRecv wieder gebe.

Kann das sein das die Puffergröße zu groß ist. Weil der Client weis ja wie groß der Puffer ist (SysSockRecv) und befüllt entsprechend,
das heißt er schaufelt solange rein bis der Puffer Voll ist. Ich unterbreche aber zu früh, zu früh meine ich, das der Client in seiner Abarbeitungszeit z.B. die ersten 100Byte von den Maximal möglichen 1000Byte kopiert hat und somit könnten dann beim nächsten Lesen Daten verloren gehen oder,
weil ich ja das "Size" ablösche.


MacToolz

41

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 18. November 2014, 01:34:56 »

Hi,

ich nochmal zur frühen Stunde,
Ich habe das mir nochmal angeschaut und sehe das hier mit der Mailbox die Verriegelungen für das SysSockRecv gemacht werden.

Ok, also was habe ich geamcht, nachdem ich im Size direkt Daten sehe, habe ich die Mailbox[3] := 1 gesetzt damit im nächsten Zyklus
keine Daten mehr vom Client abgeholt werden.

Jetzt kommt das große aber. Es kommen VIELLEICHT Daten im nächsten Aufruf oder auch nicht.
Sobald ich nach meiner Verarbeitung das Byte wieder zurück setze, kommen meistens keine Daten mehr.

Es sieht so aus das der Client von dem ich die Daten habe möchte die alle irgend wie los geworden ist.

Nur wohnin


MacToolz

42

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 18. November 2014, 00:25:38 »

Hi Peewit,

ok das habe ich verstanden. Das heißt ihr bekomme was in dem Empfangspuffer, verarbeite die Daten,
lösche das "Size" wieder ab, muss aber dafür sicher stellen das keine Daten über den Synchaufruf SysSockRecv kommen können.

Was müsste ich denn jetzt in der Oscat Lib dafür tun damit der SysSockRecv nicht mehr aufgerufen wird.

Ist das die Mailbox --> IP_C.MAILBOX[3]


Gibt es da schon was das der Empfang geblockt wird. Weil ich würde ja gerne die LIB unberührt lassen,
außer man findet bei einem Profi einen Fehler ;-) ...


MacToolz

43

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 17. November 2014, 20:41:12 »

Hi Peewit,

das der IP_Control freilaufend ist das habe ich auch gesehen.

Ok, das mit dem Synchronen Aufruf von SysSockRecv habe ich mir fast gedacht.

Aber das mit dem Datenempfang anhalten, da habe ich nicht den Sinn verstanden, warum man das überhaupt macht.
Kannst du das bitte mal erklären?

Das der Puffer anwächst ist auch ok, soll ja auch so sein. Mein Gedanke ist, das ich eigentlich alles was an Empfangsbytes nach dem Synchronen Aufruf von  SysSockRecv kommt "bytes_received" direkt aus dem Empfangsbuffer zu kopieren.

Das sollte doch rein theoretisch funktionieren. Die Bedingung zu dem ist auch klar, das man auch überwacht das auf Daten aus dem SysSockRecv vorhanden sind, sprich "-1" sind natürlich keine Daten vorhanden.

Kannst du dir das erklären was das für ein Verhalten ist, das ich unbedingt Zeit verzögert erst kopieren kann.
Ich habe mal als Hausnummer eine Zeit herausgefunden, unter t#100ms brauch ich nicht anfangen zu kopieren.

Ich habe keine Ahnung warum.
Halte ich die Zeit ein, funktioniert alles wunderbar. Wie schon erwähnt, ich habe mitgeloggt wie die Daten aus dem SysSockRecv rein kommen.
Um erkennen zu können ob ich auch die richtige Anzahl von Bytes umkopiere. So nach dem Motto, nicht schneller oder eher zu viel direkt aus dem Empfangspuffer kopiere,
wo eigentlich noch keine Daten sind.

Das kann ich von mir aus gesehen ausschließen. !!!


MacToolz

44

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 16. November 2014, 19:21:08 »

Hi,

ab wann darf man denn sich Profi nennen :-).
Die Funktionsweise vom "Size" ist mir bekannt, in beide Richtungen.

Aber ich habe ein seltsames Problem. Sobald ich in der gleichen Task das bytes_receveid nehme sozusagen
als Start das Daten im Puffer vorhanden sind, fange ich an die Daten umzukopieren.

Seltsamer weise muss ich die zeitlich versetzt umkopieren. Dann funktioniert es.
Wenn ich z.B. auf den ersten 70 Bytes umkopiere überschreibe ich mir Daten, obwohl ich in der gleichen Task liege.

Arbeiten die Funktionsaufrufe SysSockRecv Synchron oder Asynchron.

Ich kann irgendwie das Problem nicht einkreisen.


MacToolz

45

oscat.lib fuer CoDeSys 3 / Re: Network.lib

« am: 16. November 2014, 10:01:27 »

Hi,

also ich für meinen Teil sehe hier kein Problem. Ich habe das "Size" für den Buffer falsch interpretiert.
Das Size ist ja die Größe die ja gerade im TCP Stack gerade in die Steuerung kopiert wird.

Wenn ich z.B. 5200 Bytes empfangen dann sind die auch im Buffer zu sehen. Das heißt das nach jedem SysSockRecv die Anzahl der Daten in den Buffer kopiert werden.

Ich stelle mir gerade die Frage wann ich die Daten umkopieren soll?

MacToolz