Sonstiges S7 via MPI-USB von Linux auslesen

skymon

Level-1
Beiträge
8
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich versuche seit geraumer Zeit eine S7 313C von Ubuntu aus auszulesen. Mein USB-MPI-Kabel ist ein 6ES7972–0CB20–0XA0. Unter Win7 mit Simatic 5.5 funktioniert das auch problemlos.

Die bisher "erfolgreichste" Variante unter Linux war die Nutzung von libnodave (0.8.5.1) mit testMPI (testMPI -d -3 --listall /dev/ttyUSB0). Hierbei bekomme ich so jedes 3.-5. Mal, wenn ich es starte, zumindest etwas sinnvolles zurückgegeben. Das, was ich zurückgegeben bekomme ist aber leider immer noch falsch (jeweils exakt 10 Blöcke für FC, DB etc. obwohl eigentl. jeweils unterschiedliche Anzahl). Falls es hilfreich sein sollte, kann ich gerne auch noch eine vollständige Ausgabe nachreichen. Die Optionen "ohne -3", "-2" und "-4" habe ich leider auch erfolglos probiert, genau wie testUSB.

Hat irgendjemand diese Kombination (Linux, 6ES7972–0CB20–0XA0, libnodave) zufällig bei sich in Betrieb und Hinweise, was ich beachten muss? Irgendeinen Parameter, den ich auf jeden Fall mal überprüfen sollte? Ansonsten würde ich mich auch über Hinweise für andere Kombinationen, die unter Linux laufen, freuen.

Viele Grüße und vielen Dank schonmal
skymon
 
Hallo Skymon,

schau dir mal die Demoversion von ACCON-AGLink an (im Reiter unter Downloads). Da gibt es auch entsprechende Beispiele für Linux. Vielleicht ist dies ja die bessere Wahl für dich. Die Jungs von DELTA LOGIC sind auch hier im Forum unterwegs und zusätzlich noch über eine offizielle Support Hotline erreichbar.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Sven,

vielen Dank für Deine Antwort. Die Software hatte ich mir tatsächlich schon angeschaut, allerdings auch nicht mit meinem USB-MPI-Kabel in der Demoversion zum Laufen bekommen. Hat das jemand schon erfolgreich unter Linux realisiert?

Leider scheint es die Linux-Versionen auch nur als Entwicklerversion zu geben, die anscheinend bei 2.000€ anfangen, wenn ich die Webseite richtig interpretiere. Wenn dazu dann auch noch ein neuer Konverter kommen sollte, wäre ich vermutlich mit einer neuen Steuerung fast günstiger unterwegs, da meine Versuche erstmal auf die eine Steuerung beschränkt sind.

Vielen Dank nochmal und viele Grüße
skymon
 
Probier doch mal das ganze mit anderer Hardware und / oder auch einer anderen Distribution (z.B. Fedora oder Arch).

Gruß
Blockmove
 
Der 6ES7972–0CB20–0XA0 benötigt normalerweise einen entsprechenden Gerätetreiber von Siemens. Dieser ist allerdings nur unter Windows verfügbar. ACCON-AGLink würde dann über das Modul S7-PC/CP diesen Adapter unterstützen. Aber wie gesagt, nur unter Windows.
Um die Investitionen gering zu halten, würde ich an dieser Stelle z. B. den ACCON-NetLink-PRO compact als Kommunikationsadapter in Verbindung mit libnodave empfehlen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo nochmal,

vielen Dank für die wertvollen Hinweise. Der andere Kommunikationsadapter scheint mir wirklich sinnvoller zu sein.

@Rainer Hönle: Weißt Du zufällig, ob der dann direkt auch mit node-red, bspw. unter Nutzung der https://flows.nodered.org/node/node-red-contrib-s7comm oder https://github.com/netsmarttech/node-red-contrib-s7 funktioniert? Auf der Ethernet-Seite scheint das Ganze ja RFC1006 zu sein, daher müsste das gehen, oder? Hast Du Erfahrungsberichte dazu?

Da es wohl noch ein wenig dauert, bis ich den anderen Adapter bekomme, hab ich mich mal ein wenig intensiver mit dem Protokoll auseinandergesetzt und ein kleines Python-Skript geschrieben, das zumindest die Verbindung aufbaut. Vielen Dank an der Stelle schonmal @Jochen Kühner und @Zottel, ohne deren WPFToolBoxForPLCs bzw. libnodave ich nie soweit gekommen wäre. Mittlerweile bekomme ich mit dem Skript zumindest die Verbindung genauso aufgebaut, wie die WPFToolBoxForPLCs das unter Nutzung der S7 DLL unter Windows zu machen scheint. Das heißt, ich bekomme zumindest die gleiche Rückmeldung des angeschlossenen Geräts am Ende. Sobald mein Code nichtmehr das hässlichste ist, was ich je gesehen habe, werde ich ihn mal teilen...

Jetzt muss ich nur noch rausfinden, wie die Reihenfolge an Nachrichten ist, mit denen ich die aktuellen Werte der Bausteine abfragen kann. @Jochen Kühner: Die Funktion hab ich nicht direkt in der Toolbox gefunden. Hab ich das übersehen, oder gibt es das dadrin nicht?

Viele Grüße
skymon
 
Der ACCON-NetLink-PRO compact kann RFC1006 (ISO on Top Of TCP) "reden", sollte also mit jeder Biobliothek funktionieren, die dieses Protokoll beherrscht.
Ich verstehe allerdings nicht, was Du tun möchtest. Denn "wie die Reihenfolge an Nachrichten ist, ..". Die Antworten (Responses) kommen so, wie Du die Fragen (Requests) stellst, also in der Regel immer eine nach der anderen, passend zu Deiner Frage. Oder wo ist genau das Problem?
 
Hi Rainer,

ja, ich glaube mein Post war vermutlich ein wenig verwirrend. Insgesamt will ich eigentlich nur die aktuellen Werte der Register in drei Bausteinen DBxx auslesen.

Der erste Teil bezog sich auf den ACCON-NetLink-PRO compact. Sobald ich den habe, werde ich dann einfach mal ausprobieren, ob das geht.

Der zweite Teil bezog sich auf die Interaktion mit dem 6ES7972–0CB20–0XA0. Hier habe ich mir mit Wireshark angeschaut, welche Pakete die WPFToolBoxForPLCs schickt und was dann für eine Antwort vom Adapter kommt. Genauer habe ich mir das für das "Connect" angeschaut, bei dem am Ende der Nachrichtensequenz das angeschlossene Gerät vom Adapter zurückkommt (
leider kann ich irgendwie das .pcapng hier nicht anhängen, siehe Edit). Die Sequenz an Nachrichten habe ich im python-Skript rekonstruiert und bekomme die gleiche Antwort am Ende, d.h. ein Paket, das "6ES7313-..." beinhaltet. Um jetzt die DBxx auszulesen, muss ich (wenn ich das richtig verstehe), eine ähnliche Reihenfolge an Paketen abschicken. Als einziger Unterschied müsste ich dann vermutlich an irgendeiner Stelle ein Paket mit der korrekten PDU schicken. Das war das, was ich mit "Reihenfolge an Nachrichten" meinte.

Viele Grüße
skymon

Edit: Offensichtlich mag es hier nur das Dateiformat oder die Endung (.pcapng) nicht, gezippt geht's:
Anhang anzeigen s7online-connect.pcapng.zip
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie schon geschrieben, zu einem USB-Gerät gehört immer ein passender Gerätetreiber, den Siemens meines Wissens nach für diesen Adpater nicht für Linux zur Verfügung stellt. Hier werden die kompletten Initialisierungen etc. vorgenommen, ohne die der Adapter nicht funktioniert. Was Du am Ende dann siehst, ist die Kommunikation mit einem ordentlich konfigurierten Gerät, und das sollte dann wieder zur den bekannten Telegrammen passen.
Hast Du schon versucht, ein unbekanntes USB-Gerät unter Windows einzustecken unhd dann geschaut, was unter dem Blech alles abgeht? Was passiert, wenn z. B. die inf-Dateien fehlen etc.? Genau das musst Du hier unter Linux nachprogrammieren. Wenn Zeit keine Rolle spielt, ist das sicher interessant.
 
Hi Rainer,

es stimmt, dass unter Linux das Äquivalent eines Windows-Treibers erforderlich ist. Einen grundlegenden "Treiber" hat "Thomas Hergenhahn" in 2005 geschrieben (ich glaube er ist auch hier im Forum unterwegs, ich kann allerdings den Benutzernamen gerade nichtmehr ganz zuordnen, https://github.com/netdata/libnodave/tree/master/usb2mpi-Linux-2.6). Mit Hilfe von "Christian Daschill" ist das dann auch anscheinend für Kernel 2.6.13 erst als eigenes Modul reingepatcht und später dann mit einigen weiteren Modulen im Modul "usb_serial_simple" zusammengefasst worden (https://github.com/torvalds/linux/blob/master/drivers/usb/serial/usb-serial-simple.c). Mit dem Modul wird der 6ES7972–0CB20–0XA0 auch korrekt als Adapter unter Linux erkannt. Daher kann ich den Adapter auch in meinem Python-Skript als "/dev/ttyUSB0" verwenden und bekomme - wie beschrieben - auch die korrekten Antworten für die Verbindungsherstellung. Im weiteren Sinne könnte man dies auch als Teil einer Art von "Treiber" unter Linux betrachten. Dann wäre libnodave eben auch ein "Treiber" - ich würde es allerdings eher etwas allgemeiner als "Bibliothek" bezeichnen.

Für meinen Anwendungsfall fehlt mir zur Fertigstellung einer solche Bibliothek mittlerweile daher "nur" noch ein Beispiel für eine korrekte Nachrichtensequenz der Abfrage von Datenbausteinen. Alternativ freue ich mich auch über Hinweise auf funktionierende Bibliotheken für den Adapter unter Linux oder wo die aktuellen Werte von Datenbausteinen in der
WPFToolBoxForPLCs abgefragt werden.

Viele Grüße
skymon

 
Also der User heißt thomas_v2.1.
Aber zunächst die Frage:
Findest du unter Ubuntu den Adapter? Ich habe leap und da kann man mit yast prüfen ob eine Hardware gefunden wurde.
Ich brauchte einen bestimmten Adapter mit einem speziellen Chip, dass ich auf die PLC zugreifen konnte, gerade bei USB auf MPI / seriell oder AS511


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi bike,

ahja stimmt, der Benutzer wars. Ja, der Adapter wird gefunden. Grundsätzlich kommunizieren eben auch sowohl libnodave (Eingangspost) als auch mein Python-Skript mit dem Adapter. Unter libnodave funktioniert aber eben weder "--listall" richtig, heißt das "Ergebnis" ist falsch (s. Eingangspost), noch die Abfrage eines bestehenden Datenblocks ("--many=6" da hab ich allerdings auch die Größe des abzufragenden Blocks angepasst).

Als "Beweis" hier noch die dmesg-Ausgabe:
[68307.590035] usb 1-2: new full-speed USB device number 26 using ohci-pci
[68307.909886] usb 1-2: New USB device found, idVendor=0908, idProduct=0004
[68307.909890] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[68307.909892] usb 1-2: Product: SIMATIC PC Adapter USB
[68307.909895] usb 1-2: Manufacturer: SIEMENS AG
[68307.909897] usb 1-2: SerialNumber: 6ES7 972-0CB20-0XA0
[68307.940621] usb_serial_simple 1-2:1.0: siemens_mpi converter detected
[68307.940701] usb 1-2: siemens_mpi converter now attached to ttyUSB0

Viele Grüße
skymon
 
Mhh, dann bin ich wohl nicht der einzige der den Benutzernamen nicht ganz zuordnen kann, oder er hat 2 hier...

@Harald: Vielen Dank für den Link. Den hatte ich tatsächlich nicht auf dem Schirm, weil es bei mir nicht TCP sondern eben vermutlich die testS7online ist. Das muss ich dann jetzt erstmal kompilieren, aber einen Test unter Windows ist es auf jeden Fall mal wert.

Viele Grüße
skymon
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Falls es hilfreich sein sollte, kann ich gerne auch noch eine vollständige Ausgabe nachreichen.

Um auch der Vollständigkeit halber noch meine Ausgabe für "sudo ./testMPI -d -3 --many=6 /dev/ttyUSB0" (mit ner geringeren Größe des Datenblocks, 20 - aber die Antwort für die Standardgröße 2000 ist identisch) nachzureichen, findet Ihr in hier die Anhang anzeigen debug.txt mit ein paar mehr debug-Meldungen noch aktiviert. Man sollte daran den grds. eigentl. richtigen Verbindungsaufbau erkennen, aber die Antwort auf die Anfrage des Datenblocks passt eben nicht (wobei ich mir gar nicht sicher bin, ob ich damit genau das mache - aber so meine aktuelle Hypothese).

Heißt, ich vermute, dass das hier richtig ist (s. debug.txt):

0:0x7E,0x77,0x20,0xDF,0x04,0x82,0x80,0x0C,0x12,0x14,0xF1,0x02,0x32,0x01,0x00,0x00,
10:0x00,0x01,0x00,0x0E,0x00,0x00,0x04,0x01,0x12,0x0A,0x10,0x02,0x00,0x0A,0x00,0x06,
20:0x84,0x00,0x00,0x00,0xE8,0xEE,0x7E

Aber die Antwort hier nicht:

0:0x7E,0x66,0x1C,0xE3,0x04,0x82,0x80,0x0C,0x14,0x12,0xF1,0x00,0x32,0x03,0x00,0x00,
10:0xFF,0xFF,0x00,0x08,0x00,0x00,0x00,0x00,0xF0,0x00,0x00,0x01,0x00,0x01,0x00,0xF0,
20:0x55,0xFE,0x7E,

Die Antwort hieße: Datenlänge in der PDU ist 0 und am Anfang der PDU-Parameter der falsche Code (0xF0 statt 0x04). Aber wie gesagt, alles nur Vermutungen...

Viele Grüße
skymon
 
Libnodave und der Linux-Treiber sind von mir.
Der Linux-Treiber bestand im Grunde nur aus dem Treiber für einen Standard USB-Seriell-Konverter-Chip, in den ich die passende Vendor- und Product-ID eingetragen habe.
Das ist heute nicht mehr nötig, da man einfach dem Universal-USB-Seriell-Treiber von Linux die passenden Nummern beim Aufruf mitgeben kann:
Code:
modprobe usbserial vendor=0x0908 product=4
Libnodave hat Bugs beim Auslesen der Bausteinliste. Möglicherweise gab es noch keine Bausteinnummern, die mehr als ein Byte umfassen, als ich das geschrieben habe...
 
Zuletzt bearbeitet:
Mhh, dann bin ich wohl nicht der einzige der den Benutzernamen nicht ganz zuordnen kann, oder er hat 2 hier...
Es sind zwei verschiedene Benutzer:
Thomas_v2.1 hat das wireshark-Plugin geschrieben und Thomas Hergenhahn (aka Zottel) hat libnodave geschrieben.
@Zottel: Schön mal wieder etwas von Dir zu hören. Was machst Du so in der letzten Zeit?
 
Zurück
Oben