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

Ergebnis 1 bis 9 von 9

Thema: Wechsel von S7 Beans zu libnodave (bzw. C#)

  1. #1
    Registriert seit
    25.08.2010
    Beiträge
    49
    Danke
    3
    Erhielt 4 Danke für 4 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Moin, endgültig am Verzweifeln,

    ich habe eine S7-200 über UMTS (Ping im Schnitt 300 bis 600 ms) ... die Anbindung erfolgt bisher über S7 Beans API - also rein Java ... nachdem nun eine zweite S7-200 ins Netz gesteckt wurde, muss die S7 Beans API raus ... da bei einer Fehlfunktion zu einer SPS die andere ebenfalls mit in den Abgrund gerissen wird ... und am rumzicken ist nur die SPS hinter der UMTS-Verbindung

    das Auslesen via libnodave oder S7.Net funktioniert - aber auch nicht so wirklich richtig ... die Verbindung ist irgendwie instabil ... schreiben kann ich gar keine Werte

    der Verbindungsaufbau erfolgt so:
    Code:
            private void ConnectSPS()
            {
                fds.rfd = libnodave.openSocket(102, this.ip);
                fds.wfd = fds.rfd;
                di = new libnodave.daveInterface(fds, "IF1", 0, libnodave.daveProtoISOTCP243, libnodave.daveSpeed187k);
                di.setTimeout(5000);
                dc = new libnodave.daveConnection(di, 0, rack, slot);
                int res = dc.connectPLC();
                if (res != 0)
                {
                    logger.warn("Konnte nicht mit SPS verbinden -> Error:" + res);
                    CloseSPS();
                }
                else
                {
                    connected = true;
                    Program.BroadCast(CreateStatusUpdate());
                }
            }
    dabei ist das Interessante das in der Console steht das er die Verbindung aufgebaut hat ... aber dc.connectPLC liefert einen Fehler
    Code:
    openSocketw.c: Connected to host: 192.168.1.197 
    system 26.08.2011 23:26:47.055 0000000C(192.168.1.197-23:26:46) SPS ConnectSPS WAR - Konnte nicht mit SPS verbinden -> Error:-1
    openSocketw.c: Connected to host: 192.168.1.197 
    system 26.08.2011 23:26:49.170 0000000C(192.168.1.197-23:26:46) SPS ConnectSPS WAR - Konnte nicht mit SPS verbinden -> Error:-1
    openSocketw.c: Connected to host: 192.168.1.197
    als Fehler kommt statt der -1 auch -1025 ... was ja bedeutet das die SPS nicht erreichbar ist - aber kurz vorher sagt er ja das die TCP-Verbindung steht ... wenn ich via telnet die Verbindung aufbaue, dann kommt auch eine Antwort -.-

    irgendwann - wenn der Netzwerkgott es will, funktioniert auch ein dc.connectPLC ... dann lese ich wie folgt alle Werte aus der SPS

    Code:
                    int res = dc.readBytes(libnodave.daveFlags, 0, 10, 18, null);
                    logger.info("lese MW10.0 bis MW26.0 -> " + libnodave.daveStrerror(res));
    
                    int m0 = dc.getS16();   // MW10.0
                    dc.getS16();            // MW12.0
    
                    int v = dc.getS16();    // MW14.0
                    int status = (v & 0xff00) >> 8;     // M14.0
                    int errors = (v & 0x00ff);          // M15.0
    
                    dc.getS16();                // MW16.0
                    dc.getS16();                // MW18.0
                    int height = dc.getS16();   // MW20.0
                    dc.getS16();                // MW22.0
                    int m1 = dc.getS16();       // MW24.0
                    int m2 = dc.getS16();       // MW26.0
                    logger.info("MW10.0: " + m0 + " - MW24.0: " + m1 + " - MW26.0: " + m2);
    was auch super funktioniert ... nur das Schreiben funktioniert gar nicht

    Code:
                                int res = dc.writeBytes(libnodave.daveFlags, 0, 10, 2, new byte[] { (byte)ui, 0 });
                                logger.info("Result -> " + res);
    liefert mir als Fehlercode immer -1025 ... das Auslesen der Werte nach ca. 1 Sekunde erfolgt aber wiederum Problemlos

    ich habe also eine instabile Verbindung und kann keine Werte schreiben ... was mache ich falsch?

    danke, mogel
    Zitieren Zitieren Wechsel von S7 Beans zu libnodave (bzw. C#)  

  2. #2
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.758
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard

    Schau dir doch mal den ganzen Telegrammverkehr mit Wireshark an, um zu sehen was da falsch läuft.
    Am besten nutzt du dazu den Dissector von hier https://sourceforge.net/projects/s7commwireshark/ , dann werden diem Telegramme schön aufgeschlüsselt! Oder stell halt mal ne aufzeichnung des Telegrammverkehrs mit Wireshark hie rein, vielleicht kann man dann leichter helfen!
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten
    Zitieren Zitieren Wireshark  

  3. #3
    Registriert seit
    25.08.2010
    Beiträge
    49
    Danke
    3
    Erhielt 4 Danke für 4 Beiträge

    Standard

    Moin,

    im Anhang ist das gewünschte Protokoll

    gibt es eigentlich in den Tiefen der Siemens-Support-Seite eine Protokollbeschreibung zur Kommunikation mit einer SPS ... im Grunde fehlen mir die (Fach)begriffe zum Suchen

    hand, mogel
    Angehängte Dateien Angehängte Dateien

  4. #4
    Registriert seit
    29.03.2004
    Beiträge
    5.797
    Danke
    144
    Erhielt 1.707 Danke für 1.239 Beiträge

    Standard

    Häng den Mitschnitt doch bitte nochmal als .pcap Datei (evtl. vorher gezippt, oder die Endung ändern) an, dann kann man das direkt in Wireshark reinladen.

    Was man zumindest sehen kann ist, dass wenn du dich versuchst auf ISO Ebene zu verbinden (CR Connect Request) die SPS/CP daraufhin die TCP-Verbindung trennt (FIN, ACK).

    Ursache könnten falsche TSAPs sein. Aus deinen Telegrammen kann man sehen dass du einen Destination TSAP von 0x0102 übermittelst. Habs zwar noch nicht nachgeschaut ob das libnodave bei der 200er mit CP anders macht, aber eigentlich wird der Destination-TSAP aus den rack und slot Angaben kombiniert. Das kann man aus deinem gezeigten Programmcode leider nicht sehen was du in diese Variablen hineinschreibst.

    Laut Handbuch der CP243 kannst du in einer Konfiguration den lokalen TSAP einstellen, und dass der CP beim TSAP nur auf das erste Byte achtet, fragt sich nur von wo aus gesehen das erste. Was hast du dort eingestellt?

    Da es aber laut deiner Aussage manchmal doch funktioniert ist das schon sehr seltsam. Evtl. mach doch mal den Mitschnitt so lange bis auch eine Verbindung zu stande kommt. Dann müsste man ja sehen können was an diesem Telegramm anders ist.

  5. #5
    Registriert seit
    29.03.2004
    Beiträge
    5.797
    Danke
    144
    Erhielt 1.707 Danke für 1.239 Beiträge

    Standard

    Ich habe mir das gerade nochmal im Detail angesehen.
    Und zwar ist eindeutig der Destination-TSAP falsch.
    Laut Handbuch darf das linke Byte (also da wo du jetzt 0x01 stehen hast) nur den Wert 0x02 oder Werte zwischen 0x10 bis 0xfe annehmen. Das Rechte Byte wo bei einer S7 die Rack/Slot Kombination relevant ist wird von dem CP ignoriert.

    Libnodave trägt allerdings bei korrekter Verwendung, d.h. wenn du daveNewInterface mit daveProtoISOTCP243 aufrufst, für den CP243 gültige TSAPs ein. Das habe ich gerade nochmal mit der aktuellen libnodave (0.8.4.6) geprüft. Allerdings habe ich direkt die C-Quellen verwendet.

    Laut deinen Wireshark-Logs sieht es aber stark danach aus dass du nicht daveProtoISOTCP243 sondern daveProtoISOTCP verwendest. Entweder da ist irgendwo die Definition der Konstanten 'daveProtoISOTCP243' falsch, oder du hast ein komplett falsches Programm gestartet.
    Welche libnodave Version verwendest du denn? Oder lass dir mal den Wert der Konstanten 'daveProtoISOTCP243' auf der Konsole ausgeben, dieser muss 123 sein. Oder setze mal anstelle des Symbols direkt diesen Wert 123 ein.

  6. Folgender Benutzer sagt Danke zu Thomas_v2.1 für den nützlichen Beitrag:

    mogel (27.08.2011)

  7. #6
    Registriert seit
    25.08.2010
    Beiträge
    49
    Danke
    3
    Erhielt 4 Danke für 4 Beiträge

    Standard

    Also,

    da war im Programm wirklich daveProtoISOTCP gesetzt ... nachdem ich das jetzt geändert habe funktionierte es zumindest in der VM erstmal besser ... schreiben ging auch und das Wehr ist verfahren

    ich hatte mit daveProtoISOTCP/daveProtoISOTCP243 rumgespielt in der Hoffnung das Ganze stabiler zu bekommen ... und anschließend aus den Augen verloren ... im Moment bricht er teilweise beim Lesen von MW10.0 bis MW26.0 mit -128 (oder -1025) ab ... ich habe den Dienst jetzt mal in die Produktivumgebung geschoben ... mal schauen wie stabil der über Nacht läuft

    hand, mogel

  8. #7
    Registriert seit
    29.03.2004
    Beiträge
    5.797
    Danke
    144
    Erhielt 1.707 Danke für 1.239 Beiträge

    Standard

    Was du mal prüfen könntest:
    Wie oft fragst du bei dem CP Daten ab? Evtl. schließt der CP die Verbindung automatisch wenn nach einer (evtl. einstellbaren) Timeoutzeit kein Telegramm reinkommt. So wie es aussieht hältst du den Socket ja kontinuierlich offen. Zur Not musst du dann eben eine neue Verbindung aufbauen.

  9. #8
    Registriert seit
    25.08.2010
    Beiträge
    49
    Danke
    3
    Erhielt 4 Danke für 4 Beiträge

    Standard

    ich frage den CP ca. jede Sekunde ab - wollte den gerade auf 2 Sekunden beschränken (reicht auch aus) ... ich habe mir gerade mal das Logfile angeschaut, was ich erzeuge ... läuft soweit ganz gut ... im Moment trenne ich die Verbindung zum CP bei jedem kleinen Fehler - und bau na 5 Sekunden die Verbindung wieder auf ... da will ich nochmal schauen ob das besser wird wenn ich vernünftiger auf die Fehlerrückmeldungen reagiere

  10. #9
    Registriert seit
    25.08.2010
    Beiträge
    49
    Danke
    3
    Erhielt 4 Danke für 4 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Moin, folgendes zu Info

    Zitat Zitat von mogel Beitrag anzeigen
    im Moment trenne ich die Verbindung zum CP bei jedem kleinen Fehler - und bau nach 5 Sekunden die Verbindung wieder auf ... da will ich nochmal schauen ob das besser wird wenn ich vernünftiger auf die Fehlerrückmeldungen reagiere
    öhm nein - wird eher unmöglich ... wenn eine Lesevorgang fehlgeschlagen ist, dann werden alle weiteren Leseversuche mit -128 quittiert ... daher bleibt es bei "Fehler->Trennen->Verbinden"

    ich vermute das libnodave intern beim Lesen bzw. Schreiben keine Synchronisation eingebaut hat ... nach dem ich das entsprechend in meinem Programm vorgesehen habe funktioniert es fast ohne Fehler beim Lesen bzw. Schreiben

    wenn auf dem Produktivsystem der Dienst zum Auslesen der Daten läuft, dann erhalte ich in der Entwicklungsumgebung beim Verbindungsaufbau immer -1 ... die Socketverbindung steht aber - wird also aufgebaut ... ich vermute das der CP nur eine entsprechende Datenverbindung zu lässt ... da nur eine Datenverbindung existiert, muss ich eben auf dem Produktivsystem den Dienst beenden, wenn ich was testen will ... ist also das kleinere Übel

    ungünstig wirken sich die Videodaten auf die Verbindung zum CP aus, da parallel noch ein JPEG Bild übertragen ... sowie das JPEG angezeigt wird, bricht die Verbindung zum CP öfter mal zusammen ... da beim JPEG die UMTS-Leitung "verstopft" dürfte das der Grund dafür sein

    hand, mogel

Ähnliche Themen

  1. Über HMI Programm wechsel
    Von Silversurger im Forum CODESYS und IEC61131
    Antworten: 4
    Letzter Beitrag: 21.08.2009, 09:37
  2. WinAC und Java-Beans
    Von jck0815 im Forum Simatic
    Antworten: 1
    Letzter Beitrag: 23.01.2009, 13:01
  3. Wechsel programmieren
    Von Lucky2409 im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 15.09.2008, 19:49
  4. Wechsel der CPU, z.B. von 315-2DP auf 317-2DP
    Von plc_tippser im Forum FAQ
    Antworten: 0
    Letzter Beitrag: 12.07.2006, 09:18
  5. Wechsel von 308-B auf 308-C
    Von INST im Forum Feldbusse
    Antworten: 2
    Letzter Beitrag: 21.09.2005, 15:43

Lesezeichen

Berechtigungen

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