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

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

Thema: MPI Protokoll

  1. #1
    Registriert seit
    24.12.2005
    Beiträge
    127
    Danke
    1
    Erhielt 9 Danke für 9 Beiträge

    Standard


    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.
    Wo nichts ist,
    da kann nichts sein.
    Zitieren Zitieren MPI Protokoll  

  2. #2
    Registriert seit
    20.10.2003
    Ort
    Biberach
    Beiträge
    5.081
    Danke
    963
    Erhielt 1.471 Danke für 929 Beiträge

    Standard

    Zitat Zitat von arcis
    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
    Beste Grüße Gerhard Bäurle
    _________________________________________________________________

    Die Signatur ist den allgemeinen Sparmaßnahmen zum Opfer gefallen.
    Zitieren Zitieren Re: MPI Protokoll  

  3. #3
    arcis ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    24.12.2005
    Beiträge
    127
    Danke
    1
    Erhielt 9 Danke für 9 Beiträge

    Standard

    Die FAQ's aus diesem libnodave Projekt

    http://sourceforge.net/project/showf...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.
    Wo nichts ist,
    da kann nichts sein.
    Zitieren Zitieren +  

  4. #4
    Registriert seit
    19.06.2003
    Beiträge
    2.200
    Danke
    85
    Erhielt 259 Danke für 175 Beiträge

    Standard

    Zitat Zitat von arcis
    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.
    Zitieren Zitieren Re: +  

  5. #5
    arcis ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    24.12.2005
    Beiträge
    127
    Danke
    1
    Erhielt 9 Danke für 9 Beiträge

    Standard

    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 ...
    Wo nichts ist,
    da kann nichts sein.
    Zitieren Zitieren +  

  6. #6
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.262
    Danke
    537
    Erhielt 2.707 Danke für 1.956 Beiträge

    Standard

    @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?
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  7. #7
    Anonymous Gast

    Standard

    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

  8. #8
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.262
    Danke
    537
    Erhielt 2.707 Danke für 1.956 Beiträge

    Standard

    @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.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  9. #9
    Registriert seit
    19.09.2005
    Ort
    Freudenstadt
    Beiträge
    811
    Danke
    64
    Erhielt 101 Danke für 64 Beiträge

    Standard

    Zitat Zitat von Ralle
    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 ?

    Zitat Zitat von Ralle
    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.

    Zitat Zitat von arcis
    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.

    Gruß Axel
    Man muß sparn wo mn knn!

  10. #10
    Registriert seit
    25.07.2005
    Ort
    Vogelsbergkreis
    Beiträge
    1.717
    Danke
    48
    Erhielt 68 Danke für 60 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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.

Ähnliche Themen

  1. IEC Protokoll
    Von Memnon im Forum Maschinensicherheit - Normen und Richtlinien
    Antworten: 15
    Letzter Beitrag: 18.02.2009, 00:19
  2. Protokoll für BVS
    Von Montancy im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 14.04.2008, 12:15
  3. Protokoll
    Von rene im Forum HMI
    Antworten: 2
    Letzter Beitrag: 04.07.2007, 11:56
  4. AK- Protokoll
    Von borromeus im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 27.02.2007, 17:30
  5. MPI-Protokoll
    Von Anonymous im Forum Feldbusse
    Antworten: 16
    Letzter Beitrag: 16.12.2004, 02:21

Lesezeichen

Berechtigungen

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