Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 20

Thema: Socket vs. Modbus

  1. #1
    Registriert seit
    04.02.2013
    Beiträge
    271
    Danke
    12
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo,

    ich habe gerade eine Socketkommunikationnzwishcne PC und Steuerung aufgebaut.

    was sagt ihr denn zur Kommunikation zweier Steuerungen untereinander?
    Ist da ein Socket auch Ok, öde lieber Modbus nutzen?
    Was genau ist der Unterschied? Modbus basiert ja darauf einen Socket zu nutzen.
    Gehe ich recht in der Annahme, dass es wie eine Socketverbindung ist, nur mit unterlagertem Modbusprotokoll?
    Zitieren Zitieren Socket vs. Modbus  

  2. #2
    Registriert seit
    07.06.2007
    Beiträge
    143
    Danke
    2
    Erhielt 24 Danke für 24 Beiträge

    Standard

    Kommt darauf an was du machen willst. Wenn du eine steuerungsunabhängige Lösung willst (du willst ja mit C# kommunizieren) dann wäre eine Socketverbindung in deinem Fall UDP oder TCP sicherlich eine gute Lösung. Du musst dann allerdings in Codesys einiges selbst entwickeln bis das stabil läuft. In C# sind das nur ein paar wenige Zeilen Code. Ich kenne mich mit Modbus nicht gut aus, mit TCP/IP und UDP/IP habe ich allerdings schon viel gemacht. Um da zwei Systeme miteinander zu verbinden geht das eigentlich recht flott. Was später Schwierigkeiten machen sind:

    1. Sicherstellung, dass große Pakete sauber übertragen werden (Grenze von TCP ist typischerweise 1500Bytes) wenn das mehr sind verschickt das TCP automatisch in mehreren Paketen und setzt diese auch wieder sauber zusammen. Du musst dann halt einen ausreichend großen Zwischenpuffer haben den du immer sofort wieder leerst damit die Gegenstelle wieder Daten schicken kann. Dann musst du die Daten selbst wieder zusammensetzen und bei erreichen deiner gesamten Paketlänge kannst du das dann intern weiterverarbeiten sonst hast du inkonsistente Daten.

    2. Ich hatte immer sehr große Probleme festzustellen wenn z.B. das Kabel ausgesteckt wird. Das musst du selbst überwachen. TCP/IP sendet ja nicht zyklisch per se, sondern nur nach Anforderung. D.h. Wenn du das Kabel aussteckst kannst es die Steuerung erstmal nicht feststellen ob die Verbindung noch steht da ja u.U. ein paar Minuten nix geschickt wird und deshalb hier keine Möglichkeit besteht das zu erkennen. Abhilfe schafft dann das KeepAlive (sorry ist schon eine Weile her, Google da besser mal nach genauen Infos). Manche Steuerung können das leider auch nicht. Ich habe dann immer meine Pakete dauernd geschickt auch wenn sich geändert hat um die Verbindung zu überwachen.

    3. Wenn du keine feste Paketlänge hast musst du eine Terminierung definieren die den Abschluss eines Paketes definieren. Mit ioctl kannst du prüfen ob Daten zum Abholen bereit stehen und wieviele Bytes es sind. Diese dann abholen und nach der Terminierung durchsuchen. Macht man normalerweise wenn man nicht mit Binärdaten arbeitet, sondern z.B. ASCII over TCP. Die meisten Kameras (Cognex, Festo, Keyence,..) arbeiten so. Senden: "Trigger$R$N" Empfangen: "OK$R$N" oder so in der Art. Die Pakete werden dann natürlich größer für solche Kommunikationen ist es dennoch gut so zu arbeiten da direkt alles im Klartext zu loggen ist.


    Welche Steuerung hast du? Codesys V2 oder V3,... oder BEckhoff?


    EDIT: Achso, für Taktzeitkritische Signale wie z.B. ein Sollwert an einen Servoantrieb würde ich auf keinen Fall TCP/IP verwenden. Manchmal gibt es hier Pakete die länger oder kürzer "unterwegs" sind. TCP/IP ist nicht echtzeitfähig. UDP/IP ist schneller aber Pakete die verlorern gehen bleiben verloren,... echtzeitfähig ist beides nicht.
    EDIT2: Bei Beckhoff ist die ADS Kommunikation am besten (je nach Anforderung!), da brauchst dann auch nicht den TCP Client zu kaufen
    Geändert von excelite (21.03.2016 um 12:46 Uhr)

  3. #3
    SY50 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    04.02.2013
    Beiträge
    271
    Danke
    12
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Ich habe eine CodesysV3 Steuerung.
    Also ich mache es so:
    wenn in meineWindows Form ein Button gedrückt wird, dann sende ich eine bestimmte Date an die Steuerung. die Steuerung sendet mir dann eine Quittung.
    im nächsten Zyklus (Timer ruft alle 100ms im C# Programm das senden auf) sende ich nur eine Anforderung, dass die Steuerung mir allgemeine Daten sendet.
    jetzt sendet die Steuerung mir auf diese Anfrage Positionen und Geschwindigkwiten von Antriben zurück.
    das funktioniert sehr gut. Bin bis jetzt echt zufrieden.
    mein einziger Punkt den ich eben nicht schön finde, ist, dass ich mir quasi ein eigenes Protokoll aufbauen muss und wissen muss wo welche Date steht. Sicherlich könnte man das durch entsprechende deklarierungen ändern, aber das würde auch wieder ein zu hohen Overhead liefern.
    zugriff über Symbolkonfiguration wäre schon genial, aber der socket funktioniert so auch ganz gut.
    ps. Die Socketkommunikation auf der Steuerung läuft einwandfrei. Haben das schon öfter gemacht. Auch mit diversen Fehler und abbruchreaktionen. Startet schön selbst wieder in allen lagen

  4. #4
    Registriert seit
    14.08.2004
    Beiträge
    824
    Danke
    45
    Erhielt 73 Danke für 66 Beiträge

    Standard

    TCP oder UDP ist nicht echtzeitfähig, aber wenn man nur einen Switch zwischen den Teilnehmern hat, ist der Jitter recht klein. Ich habe mit Python auf Windows einen Jitter von 1ms auf 50ms Scanzeit erreicht. Damit lässt sich schon etwas machen. Servos würde ich damit trotzdem nicht steuern.

  5. #5
    SY50 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    04.02.2013
    Beiträge
    271
    Danke
    12
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Nein ich will auch keine Servos damit ansteuern.
    Die Daten dienen rein zur Visualisierung auf dem Windows Rechner.
    Im Moment habe ich es auch so aufgebaut, dass ich in den ersten 10 Byte immer verschiedene Befehle (Ansteuerbefehle) sende. (Bis jetzt immer nur 1 Byte lang.
    Je nachdem welche Befehl gesendet wird, werden verschiedene Funktionen dadurch in der Steuerung aktiviert. (Simuliert bspw. einen Button in der realen HMI).
    Als Antwort sendet mir die Steuerung genau diesen Befehl auch wieder zurück und ab dem 11. Byte sendet die Steuerung noch weitere Daten wie Position einer Achse, Geschwindigkeit, Fehler usw. zurück.

    Die Daten wie Position Geschwindigkeit usw. hole ich mir in einem 100ms Zyklus ab.
    Meine Frage jetzt... wenn ich mal andere Anwendungen habe, bei denen nicht zyklisch etwas abgeholt werden muss, sondern nur auf ein bestimmtes Ereignis hin.
    Bspw. von einer Kamera oder so .... sagen wir mal jede Minute oder alle 30s einmal... Würdet Ihr dann nach dem Abholen bzw. empfangen der Daten den Socket wieder schließen, oder würdet Ihr ihn offen lassen und
    nur wieder zu gegebener Zeit einen Schreibbefehl vom Client an den Server senden?

  6. #6
    Registriert seit
    07.06.2007
    Beiträge
    143
    Danke
    2
    Erhielt 24 Danke für 24 Beiträge

    Standard

    offen lassen... stört ja nicht. Bei Kameras lese ich in den Pausenzeiten immer irgendwas aus um die Kommunikation zu prüfen wie z.B. die Version oder sonst was. Dann weiß man alles OK

  7. #7
    SY50 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    04.02.2013
    Beiträge
    271
    Danke
    12
    Erhielt 0 Danke für 0 Beiträge

    Standard

    OK, danke. Dachte ich mir schon... mache ich ja jetzt im Prinzip auch so. lese eben einfach die Achspositionen ein.

    Wenn die Steuerung als Server agiert, dann wird nachdem der Client sich connected hat ein Receive() ausgeführt.
    wird etwas anfangen, dann habe ich es so programmiert, dass die Daten zwar in dem RxBuffer landen, jedoch zusätzlich ein Callback aufgerufen wird und die Daten verarbeitet werden, bzw. die TxDaten aufbereitet werden können. Im gleichen Zyklus wird dann direkt das Senden des TxBuffer angestoßen.
    ist dies passiert, so wird im nächsten Zyklus wieder ein Recieve() ausgeführt. ..... Wird nun für eine Timeoutzeit lang nichts empfangen (sprich de Client sendet nichts), so gibt es einen Timeoutzeit und der Server wartet auf ein erneutes Connect vom Client.

    Dadurch habe aber ich den Client natürlich so ausgeführt, dass dieser auch wenn keine speziellen Befehle dauerhaft gesendet werden sollen doch einen Dummywert sendet und Daten zurückbekommt.
    Somit können diese beiden grundprogramme schonmal miteinander reden.
    Geändert von SY50 (23.03.2016 um 23:29 Uhr)

  8. #8
    SY50 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    04.02.2013
    Beiträge
    271
    Danke
    12
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Server öffnet manchmal den Socket nicht.
    gerade wenn ich Änderungen mache und einen Download einspiele, dann öffnet die Win V3 den Socket nicht mehr und liefert als Result den Code 519 "erfror bond 519".
    durch wechseln des Ports oder beenden der Wien V3 und Neustart dieser geht es dann meistens wieder. Was kann das sein und gibt's da irgendwo ne fehlerbeschreibung?

  9. #9
    SY50 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    04.02.2013
    Beiträge
    271
    Danke
    12
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Habe jetzt raus gefunden, woran es liegt.
    der Fehler tritt auf, wenn die Steuerung in Stopp geht (beim Download) und der Socket noch geöffnet ist.
    Schließe ich ihn vorher, so passiert es nicht. Nachdem die Steuerung wieder startet, ist der handle allerdings nicht mehr gültig und die Steuerung kann den Socket weder auf noch zu machen.
    was kann ich dagegen tun? Kann man irgendwie abfragen, welche handle noch den Port auf hat?

  10. #10
    Registriert seit
    07.06.2007
    Beiträge
    143
    Danke
    2
    Erhielt 24 Danke für 24 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    ja das ist immer das Problem bei den Codesyssteuerungen. Die Sockets werden insbesondere beim Onlinechange irgendwo "vergraben" im System und sind nicht mehr gültig.

    Es gibt nur eine Möglichkeit die sinnvoll ist. Erstelle eine Callbackfunktion die auf das Event Onlinechange, Download, Reset,... eingehängt wird. Dort schließst du den Socket dann beim entsprechenden Event und nach dem Onlinechange öffnest du einen neuen.

    Das ist übrigens nicht nur beim Server so, sondern auch beim Client.

    SysCallbackRegister(INDEXOF(callbackCloseSocket), EVENT_BEFORE_RESET);
    SysCallbackRegister(INDEXOF(callbackCloseSocket), EVENT_BEFORE_DOWNLOAD);
    SysCallbackRegister(INDEXOF(callbackCloseSocket), EVENT_SHUTDOWN);
    SysCallbackRegister(INDEXOF(callbackCloseSocket), EVENT_ONLINE_CHANGE);


    Kann sein,dass die bei V3 etwas anders heißen.

    In der FC callbackCloseSocket dann:


    Code:
    FUNCTION callbackCloseSocket : BOOL
    VAR_INPUT
     dwEvent:DWORD;
     dwFilter:DWORD;
     dwOwner:DWORD;
    END_VAR
    
    SysSockShutdown(dwSocket,2);
    SysSockClose(dwSocket);

    Shutdown sollte eigentlich nicht notwendig sein vor Close. Stören tut es aber auch nicht also was solls...

    dwSocket dann natürlich global deklarieren oder sonst irgendwie drauf zugreifen.

Ähnliche Themen

  1. TIA SPS Daten Abfrage über Socket
    Von Shatex im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 25.08.2015, 16:27
  2. Daten zu BC9050 über Socket Interface schicken
    Von ranni im Forum CODESYS und IEC61131
    Antworten: 0
    Letzter Beitrag: 17.06.2014, 21:23
  3. Socket Kommunikation
    Von Dust80 im Forum CODESYS und IEC61131
    Antworten: 0
    Letzter Beitrag: 04.11.2013, 19:38
  4. TCP-SOCKET Kommunikation mit WinAC RTX
    Von rostiger Nagel im Forum Simatic
    Antworten: 97
    Letzter Beitrag: 11.02.2013, 16:15
  5. Wie funktioniert ein Kamerasystem Socket
    Von Bensen83 im Forum CODESYS und IEC61131
    Antworten: 4
    Letzter Beitrag: 20.01.2013, 23:44

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •