MPI Protokoll

arcis

Level-1
Beiträge
129
Reaktionspunkte
9
Zuviel Werbung?
-> Hier kostenlos registrieren
Habe nun etwas gegoogelt, aber nichts relevantes gefunden. Gibt es das MPI Protokoll irgendwo im www verfügbar? Gemeint ist das, was auf der RS232 Ebene oder direkt dahinter abläuft.
 
arcis schrieb:
Habe nun etwas gegoogelt, aber nichts relevantes gefunden. Gibt es das MPI Protokoll irgendwo im www verfügbar? Gemeint ist das, was auf der RS232 Ebene oder direkt dahinter abläuft.

Hallo,

das MPI-Prototokoll ist von Siemens nicht veröffentlicht.

Es gibt aber von verschiedenen Herstellern DLLs,
die das Protokoll enthalten:

Prodave von Siemens
ACCON-AGLink von uns
Info: http://www.deltalogic.de/software/aglink.htm
Demo: http://www.deltalogic.de/download/aglink.htm
PC-S7-Link von Träger /PI
ComDrv von MHJ

Und es gibt mit Libnodave ein Open Source Projekt,
welches das MPI-Protokoll "enthält". Im Forum nach
libnodave suchen oder hier:

http://libnodave.sourceforge.net/index.php

Viele Grüße

Gerhard Bäurle
 
Zuviel Werbung?
-> Hier kostenlos registrieren
+

Die FAQ's aus diesem libnodave Projekt

http://sourceforge.net/project/showfiles.php?group_id=61026

Fragen, die mir schon oefter gestellt wurden und die Antworten:

Q: Meine VB,.NET oder Delphi-Anwendung funktioniert nicht. Ich vermute, Libnodave funktioniert
nicht mit meiner Hardware oder funktioniert gar nicht. Kannst du mir helfen?
A: Du kannst ganz einfach herausfinden, ob Libnodave mit deiner Hardware, SPS, Adapter
usw. arbeitet: Probierer es mit den vorkompilierten Testprogrammen. Wenn die nicht funktionieren
(auch die vorgeschlagenen Optionen probieren, wenn welche vorgeschlagen werden), ist es ganz
klar ein Fehler in Libnodave.
Wenn sie funktionieren, liegt es an deiner Anwendung (oder, selten, koennte das Problem in
der Schnittstelle zu der verwendeten Programmiersprache liegen).

Q: Kannst du mir helfen?
A: Bevor du fragst, probiere die Testprogramme wie oben beschrieben. Wenn die bei dir nicht
funktionieren, schicke mir die Ausgabe mit der Debug-Option, z.B.:
testMPI -d COM1 >debugout.txt
Wenn sie funktionieren, deine Anwendung aber nicht, probier mal:
Fuege die Zeile "daveSetDebug(daveDebugAll)" vor allen anderen Aufrufen von Libnodave in
deinen Code ein.
Dann versuche:
deineAnwendung >debugout.txt
Fuer die Leute, die mit Maeusen gross wurden und die Kommandozeile nicht mehr kennen:
Das funktioniert sogar mit MS-Excel. Erzeuge eine neue Tabelle, importiere das VBA_Modul,
- nimm das "rem" weg vor "call daveSetDebug(daveDebugAll)" am Anfang von sub initialize,
- Speichere das Arbeitsblatt.
- Starte dann von der Kommandozeile (Dos-Box, Ausfuehren/cmd):
excel testsheet >debugout.txt
Alle Debug-Ausgaben gelangen in die Datei debugout.txt.
Wenn meine Zeit knapp wird, schmeisse ich Mails ohne Debug-Ausgabe weg!

Q: Welches E-mail Format bevorzugst du?
A: Na ja, niemand hat danach gefragt, aber ich ziehe PUREN TEXT vor.

Q: Ich moechte auslesen, ob meine CPU in RUN oder STOP ist. Gibt es dafuer eine Funktion?
A: Nein, keine spezialisierte. Verwende bei S7-300/400 daveReadSZL, um die SZL Systemzustandslisten
zu lesen. Step7 macht das auch so. Informationen ueber IDs und Indizes findest du in der Siemens
Dokumentation. Der Zustand aller CPU-LEDs ist in ID 25 (19hex), index 0.
Bei der S7-200 befindet sich diese Information irgendwo in den Systemdaten.

Q: Ich versuche, Libnodave mit einem Debugger nachzuvollziehen. Ich brauche Hilfe?
A: Es gibt kaum einen Grund, Libnodave mit einem Debugger zu untersuchen, ausser du vermutest eine
der fogenden Sachen:
- Speicherprobleme (memory leaks)
- Bereichsueberschreitungen (range overflows) bei Zahlen oder Array-Indizes.
- Probleme bei der Uebergabe von Parametern an Bibliotheksfunktionen
Im letzteren Fall uebersetze besser Libnodave neu, nachdem du das Kommentarzeichen vor
#define DEBUG_CALLS in nodave.c entfernt hast.
Um Probleme mit SPS und Adaptern zu finden, ist die Debug-Ausgabe der weit bessere Weg.
Sie zeigt dir alles, was von und zu SPS/Adapter gesendet und empfangen wird und sie
zeigt dir das, was wichtig ist, anstatt es aus Speicher und Registern herauszufinden.

Q: Kannst du mir eine Dokumentation ueber die S7-Kommunikation oder das MPI-Protokoll geben?
A: Nein, kann ich nicht. Was ich darueber weiss, stammt aus "reverse engineering". Das
bedeutet, eine Menge Pakete mitzuschreiben, versuchen, einen Sinn hineinzuinterpretieren
und sie mit eigenem Code nachzubilden. Wenn in Libnodave Dinge Namen haben, so geben diese
meine gegenwaertige Hypothese wieder. Ich koennte versuchen, Dokumentation zu schreiben, aber
die wuerde immer einen Schritt hinter dem Code hinterherhinken: Der Code kann an der gegebenen
Hardware, also an der Realitaet, getestet werden, die Dokumentation nicht. Und der Code ist
recht gut dokumentiert...


Q: Also, warum gibt es diese komplizierten Strukturen (structs)?
A: Was kompliziert erscheint, sind wahrscheinlich zunaechst die Zeiger auf protokollspezifische
Funktionen. In Wahrheit machen sie die Bibliothek einfacher in zweierlei Hinsicht:
- Erstens trennen sie die Bildung der Pakete vom Transport. Wenn jemand herausfindet, wie man
mit der S7 etwas neues machen kann, reicht es, die Paketbildung zu implementieren und schon
wird es hoechstwahrscheinlich mit jedem Transportprotokoll funktionieren. Wenn andererseits
ein neuer Transportmechanismus hinzukommt, werden wahrscheinlich alle Functionen damit
funktionieren, sobald der Transport an sich funktioniert.
Version 0.8 zeigt das klar anhand der Implementierung des Transports ueber s7online.dll.
- Kommerzielle Bibliotheken, die ich gesehen habe, haben meist getrennte Saetze von Funktionen
fuer die 200 und die 300/400 Familie. Libnodave hat das nicht. So musst du weniger ueber das
API der Bibliothek lernen waehrend deine Anwendung ohne Veraenderung des Codes mehr kann.

Q: Warum exportierst du alle diese Strukturen, wenn du sagst, man braucht sie fuer keinerlei
Anwendung?
A: Sie sind nicht ganz bedeutungslos. Es sind auch eine Menge Funktionen dabei, die
"Zwischenschritte" duechfhren un normalerweise fr den Endanwender von keinem Nutzen sind.
Dennoch werden sie aus der .dll exportiert.
- Das ist alles verfuegbar - im Sinne von Open Source - fueer diejenigen, die eigene
Experimente machen wollen. Es mag ja Moeglichkeiten gebn, an die ich nicht gedacht habe.
- Wenigstens einmal konnte ich einem Benutzer helfen, eine neue Funktion (daveForce200) zu
implementiern. Er mute nur ca. 20 Zeilen in sein Programm einfuegen, die zum groessten Teil
solche Zwischenschritte beim Zusammenstellen eines Pakets und zur Analyse der Antwort
aufriefen, wie z.B. _daveAddData.

Q: Warum gibts keine Funktionen wie readOutputs, readInputs, readData ?
- Andere Bibliotheken haben ueblicherweise separate Functionen um Eingaenge, Ausgaenge,
Merker, Datenbausteine zu lesen. Libnodave hat das nicht. Schon wieder musst du weniger
ueber das API lernen.
Q: Warum gibt es keine Funktionen wie readBytes, readIntegers, readDWords, readFloat ?
- Andere Bibliotheken haben oft separate Funktionen um Integers, Worte oder Fliesskomma-
zahlen zu lesen. Libnodave hat das nicht. Der Grund ist: Wenn du einen DB (oder einen
anderen Speicherbereich in der SPS) hast, der Daten verschiedener Types enthaelt, koenntest
du mit solchen Functionen nur Teile davon lesen. Oder du benutzt readBytes um den Speicher
als eine Reihe von Bytes zu lesen und bist bei der Umwandlung auf dich allein gestellt.
Libnodave liest generell den ganzen Block als Bytes und stellt dir dann Funktionen zur
Umwandlung von/in SPS-Datentypen und Byte-Anordnung zur Verfuegu

Jetzt mal ernsthaft, benutzt diese libnodave Libraries eigentlich jemand in einer industriellen Anwendung? Wenn ja, dann muss allerdings die Verzweiflung schon beträchtlich sein. Ich halte das unter den oben hervorgehobenen Umständen für eine äussert fragwürdige Angelegenheit, auch wenn es "nur" um das Visualisieren von Prozessdaten geht. Alle Projekte, die auch nur halbwegs in die Nähe von Sicherheitsrelevanz kommen, würde ich bei Anwendung von libnodave als grob fahrlässig bezeichnen.
 
Re: +

arcis schrieb:
Ich halte das unter den oben hervorgehobenen Umständen für eine äussert fragwürdige Angelegenheit, auch wenn es "nur" um das Visualisieren von Prozessdaten geht. Alle Projekte, die auch nur halbwegs in die Nähe von Sicherheitsrelevanz kommen, würde ich bei Anwendung von libnodave als grob fahrlässig bezeichnen.
Im Allgemeinen kann man davon ausgehen, daß eine typische Applikation zu Visualisierung ihre Daten immer von denselben vorher festgelegten Adressen holt und an solche schreibt. Daher ist sie zu 100% testbar. Wenn das einmal klappt, kann man davon ausgehen, daß es immer klappt.
Eine Menge Leute verwenden SAMBA und tauschen durchaus wichtige Daten über das per "reverse engineering" nachgebildete Microsoft-Netzwerk-Protokoll aus.
Und ich vermute mal, daß alle anderen Anbieter außer Siemens selbst mehr oder weniger denselben Weg des "reverse engineering" gegangen sind.
 
+

Das ist wie nachts ein Moor zu durchqueren.

Wenn die Anwendung klein genug ist, um möglichst viele von den Zuständen, die sie annehmen kann, in einem vertretbaren Zeitaufwand durchzutesten, dann kann man ....
Nein, selbst dann hätte ich ein ungutes Gefühl. Es ist eben ein Unterschied, ob mir der Hersteller sagt, in welchem Arbeitsbereich ein Bauteil betrieben werden darf und ich dafür sorge, dass dieser Arbeitsbereich eingehalten wird. Oder ob ich austeste, in welchen singulären Arbeitspunkten sich das Dingens wie verhält. Wie gesagt, wer nächtliche Moorwanderungen spannend findet ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@arcis

Da Siemens das Protokoll nicht veröffentlicht hat, werden es die anderen Treiber-Hersteller auch nicht viel anders machen, oder sie haben für teures Geld die Informationen bei Siemens gekauft. Meist wird diese Kommunikation ohnehin ausschließlich für die Visualisierung verwendet, die Sicherheit bleibt dem SPS-Programm vorbehalten. Es kann also im Enstfall passieren, daß die ANzeigen nicht meht funktionieren, die Anlage nicht mit dem vorgesehenen Rezepten geladen werden kann etc. Wenn durch eine fehlerhafte Kommunikation zur Visualisierung die Anlage in Gefahr gerät, sind doch ganz andere Sachen faul, oder?
 
Hallo,

was arcis hier bemängelt ist das übliche Open Source Problem.

Entweder kenne ich mich mit der Thematik (hier das S7-Protokoll) aus dann weiß ich, auf was ich mich einlasse. Oder ich kenne mich nicht aus, dann kaufe ich eine fertige Bibliothek.

Wie die Bibliothek-Anbieter zu ihrem Wissen gekommen sind, ist ja zweitrangig - sie bieten ein Stück Software mit einer bestimmten Funktionalität an - und stehen dafür gerade.

Bei open source muss ich nichts zahlen und habe auch keine Ansprüche, ich stehe selbst für die Folgen gerade.

Schönen Tag noch

Viktor
 
@Viktor

Wie, "stehen dafür gerade" ?
Also daß du da jemand haftbar machen kannst ist wohl eher theoretisch, weis das mal nach und vor allem, bezahl den Nachweis.
Was den Support angeht, magst du Recht haben, aber auch da kann keiner zaubern.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ralle schrieb:
Also daß du da jemand haftbar machen kannst ist wohl eher theoretisch, weis das mal nach und vor allem, bezahl den Nachweis.

Vor allem ist der Nachweis bei einem Open-Source Projekt ja noch einigermaßen denkbar, aber wer will denn bitteschön einer Firma wie Siemens ggf. einen Fehler z.B. in Prodave nachweisen, wenn man beim disassemblieren der Executables ja schon eindeutig gegen die Lizenzbestimmungen verstößt ?

Ralle schrieb:
Was den Support angeht, magst du Recht haben, aber auch da kann keiner zaubern.

Da muß ich im Fall von libnodave aber eindeutig widersprechen, da die Unterstützung, die man von Zottel bekommt, dem (kommerzielen) Support von Siemens nach meinen Erfahrungen deutlich in den Schatten stellt.

arcis schrieb:
Jetzt mal ernsthaft, benutzt diese libnodave Libraries eigentlich jemand in einer industriellen Anwendung? Wenn ja, dann muss allerdings die Verzweiflung schon beträchtlich sein. Ich halte das unter den oben hervorgehobenen Umständen für eine äussert fragwürdige Angelegenheit, auch wenn es "nur" um das Visualisieren von Prozessdaten geht. Alle Projekte, die auch nur halbwegs in die Nähe von Sicherheitsrelevanz kommen, würde ich bei Anwendung von libnodave als grob fahrlässig bezeichnen.

Mit grober Fahrlässigkeit hat das nur dann etwas zu tun, wenn man die Bibliotheken ohne ausgiebige Tests in den eigenen Projekten einsetzt. Da die meisten Fehler jedoch beim Aufrufen von Bibliotheksfunktionen gemacht werden, kommt man auch bei kommerziellen Bibliotheken nicht um intensive Tests herum. Bei libnodave hat man dabei sogar den nicht unerheblichen Vorteil, daß man nachschauen kann, was hinter den Funktionsaufrufen eigentlich weiter passiert.

Das die Verzweiflung schon beträchtlich sein kann, ist da schon treffender. Da sieht man mal, wohin einen der Siemens Support treiben kann. :wink:

Gruß Axel
 
Auch ich finde den kostenlosen "Support" von Zottel klasse. Er geht auch immer auf Vorschläge ein und versucht sie umzusetzen. Da klemmt es dann aber meist bei dem Vorschlagendem.

libnodave ist dazu auch sehr übersichtlich strukturiert und in der Verwendung bei allen Protokollen einheitlich.
 
Ralle schrieb:
@Viktor

Wie, "stehen dafür gerade" ?

Da gibt es technische Daten und Spezifikationen die dokumentiert sind und erfüllt werden müssen. Und wenn etwas nicht tut, muss nachgebessert werden.

Bei open source muss keiner nachbessern. Klar macht Zottel das (soweit ich das beurteilen kann) hervorragend, aber man hat keinen Anspruch darauf.

Ich meine das übrigens allgemein, nicht (nur) auf den MPI-Treiber bezogen.

Warum ist denn open source nicht weiter verbreitet Eurer Meinung nach?

Viktor
 
Anonymous schrieb:
seeba schrieb:
Auch ich finde den kostenlosen "Support" von Zottel klasse.

Ja, so ist das im Moment, das glaube ich gerne. Aber Du hat keinen Anspruch darauf.

Viktor

Auf kostenlosen Support hat man auch bei kommerziellen Anbietern keinen Anspruch.
Und keiner kann eine Firma dazu verdonnern, auch morgen noch ihren kostenpflichtigen Support weiterhin anzubieten (abgesehen natürlich von den noch laufenden und bereits bezahlten Verträgen).

Das einzig Wichtige für mich ist, ob ich dem Anbieter vertraue, egal ob kommerziell oder nicht !

Gruß Axel.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
nur mal so zur Erinnerung: Protool Pro 6.0 war auch eine dicke Macke drinn warum hätten Sie sonst SP1A gleich nachgeschoben??? WinCC flexible 2004 hat der Tacho nicht hingehauen usw usw Windows XP ........
da ist man bei Zottel schon besser dran, der sagt wenigstens wo es happert.
 
Anonymous schrieb:
Da gibt es technische Daten und Spezifikationen die dokumentiert sind und erfüllt werden müssen. Und wenn etwas nicht tut, muss nachgebessert werden.

Bei open source muss keiner nachbessern. Klar macht Zottel das (soweit ich das beurteilen kann) hervorragend, aber man hat keinen Anspruch darauf.

Nachgebessert werden muß (und wird oftmals) nur, wenn der problembehaftete Anwendungsfall auch von der Spezifikation abgedeckt ist. Das kann bei manch einem Hersteller schon nach Installation des neuesten Servicepacks oder eines Sicherheitspatches im Betriebssystem nicht mehr der Fall sein, und dann heißt es plötzlich vom Support: "Das ist ja auch eine nicht freigegebene Konfiguration, das unterstützen wir nicht !"
Und dann ?

Kann einem bei Open-Source zwar auch passieren, da hat man in diesem Fall aber immer noch die Möglichkeit, die notwendigen Änderungen selbst durchzuführen oder, wenn man dazu nicht in der Lage ist, jemanden damit zu beauftragen.

Anonymous schrieb:
Ich meine das übrigens allgemein, nicht (nur) auf den MPI-Treiber bezogen.

Warum ist denn open source nicht weiter verbreitet Eurer Meinung nach?

Wie weit müssen sich Linux, Samba, Apache, MySQL, Mozilla/Firefox, OpenOffice usw. denn noch verbreiten, damit Open-Source als weiter verbreitet gilt ?

Gruß Axel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das viel bessere Beispiel ist eigentlich Apache,
denn der ist so gut das sogar Microsoft den
für ihren Internet - Auftritt nutzen.

Allerdings hat Apache natürlich einen Vorteil gegenüber den meisten anderen
OpenSource Sachen.
Apache orientiert sich nicht an einen Standard sondern ist Standard.

Mfg
Manuel
 
Anspruch auf Support

Also nur kurz mal meine Meinung zu Anspruch auf Support.

Vor einiger Zeit habe ich Siemens eine Fehler in ihrem OPC-Server nachgewiesen. Es gab weder einen Patch noch einen Work-Around! Lapidare Antwort wird evtl. im nächsten Release behoben.

Bei Intouch ging so manches nicht an ihrem I/O Server. Der Support wusste nicht weiter und ich bekamm vom Vertrieb eine Siemens-OPC Server geschenkt.

Bei Helmholz erhielt ich die Mitteilung das ich der einzige mit diesem Problem sei und da die Mage eh so gering sei, soll ich das Produkt zurückgeben.

Ich kenne keine Firma die umgehen dafür sorgt, dass Ihr Produkt auch wirklich das erfüllt, was die Werbung verspricht. Der Anspruch auf Support ist nur theoretisch!
In den meisten Fällen hilft der Support nur weiter, wenn es um User-Fehler geht. Hat das eigene Produkt aber eine Macke kann man ewig warten bis es eine Lösung gibt (obwohl ich hier auch viel Ausnahmen kenne!).

Der Siemen Vertreter sagte mir in Ihren AGB`s steht klar, dass man keine Anspruch auf die angepriesene Funktionalität hat. Siemens erklärt sich lediglich bereit bei Fehlfunktion die Software zurückzunehmen.

Wer hat schon wenn er bei einer Firma bestellt einen Vertrag in dem steht was die Software können muss? Die meisten suchen wohl die Bestellnummer heraus und ordern! Wenn ich mich da noch an mein Studium erinnere spricht man da wohl von "Vertraglich zugesicherte Eigenschaft". Eine solche habe ich noch von keiner Firma erhalten!

Da habe ich lieber Open-Source Software, bei der kann ich wenigstens (wenn auch mangels Fähigkeit meinerseits wohl er nicht) selber Hand anlegen.
 
Zurück
Oben