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

[mogel]

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:

        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

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

                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

                            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

 

[Jochen Kühner]

Wireshark

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!

 

[mogel]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

 

[Thomas_v2.1]

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.

 

[Thomas_v2.1]

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.

 

[mogel]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

 

[Thomas_v2.1]

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.

 

[mogel]

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

 

[mogel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin, folgendes zu Info

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