S7 <> PC über Ethernet

joker76 · 21 April 2005

Wird in Ihrem Projekt auch die Wirtschaftlichkeit
betrachtet? Die 'teuren' Lizenzkosten sind ja oft nur
ein kleiner Teil am Gesamtprojekt.

Naja,

es ist ja nicht so das wir nicht vorankommen....

Wir machen ja ein Wartungs/Instandhaltungstool und unser Projekt besteht aus:

1. S7-Steuerung bestehend aus einer S7-CPU315-2DP
2. Den Ethernet-Prozessor
3. Einer Feldsimulation inkl. Visualisierung der Gesamtanlage
4. Einer Vollständigen Web-Administration für die Gruppen:

Service: Betrachtung der Schaltspiele und Zustand der Aktoren
Berechneter Wartungszeitraum
Kaufleute: Automatische E-Mail-Versendung mit angegebenen Lieferzeiten
Produktmerkmalen.
etc.

Würden wir auf Fertige Tools zurückgreifen (falls überhaupt in der Form vorhanden) wäre es zu teuer.

Zu mindestens für unser Schulprojekt (und unseren Fiktiven Kunden :lol: )

Warum quält ihr euch dann so, etwas, daß auf Linux entwickelt und mit Borlands Tools auf Windows portiert wurde, zuerst unter MSVC zum Laufen zu bringen?

Naja, wir haben in der Schule mit MSVC gelernt, und es ist das einzige was mir zur Verfügung steht.
Und das da Kompatiblitäts-Probleme auftauchen, habe ich mir nicht vorgestellt. Demnächst bekommen ich Borland und dann gehts weiter.

Aber wenn es um die Demonstration a la 1 geht, und ihr wie ihr anderswo geschrieben habt, ihr immer nur einen DB oder einen Bereich daraus lesen wollt, kann ich euch auch das fertige Programm geben (mit BorlandC kompiliert).

Danke, wir werden es erstmal selber versuchen (wegen des Lerneffekts), sollte es aber mit der Zeit knapp werden (Projektvorstellung

), würden wir gerne darauf zurückkommen.

Für die Wirtschaftlichkeit bedeutet das, daß man immer die Einarbeitungszeit für das erste Projekt mit ansetzen muß.

Mach ich Tag-Täglich, sonst würde ich nur Siemens-Komponenten bestellen.
(In den Deltalogic-Produkten musste ich mich auch reinarbeiten ....)

(Ein weiteres Kriterium unseres Projekts, ist die einfache erweiterung auf weitere Anlagen, oder einfache Portierung von neuen Anlagen!)

Nun ist aufgetaucht, daß es eine Inkompatibilität zwischen Borland und MSVC zu geben scheint. Ein versierter C-Programmierer würde einfach die .DLL mit seinem MSVC neu erstellen und mir die nötigen Änderungen zur Verfügung stellen. Dafür wird er sicher nicht mehr als eine Stunde brauchen.

So sehe ich das auch, es muss nicht an meiner Unwissenheit scheitern.
Zur Zeit suche ich noch eine Lösung, hab zwar viele Ansätze ... ein paar Bücher ... aber ich arbeite dran.

Zurück zum Hauptproblem:

Bei MSVC gibt es das Tool "lib.exe", mit welcher sich die dll generieren lässt. Leider zeigt er auch mit lib.exe das die Datei beschädigt ist.

Aber es kann auch daran liegen, das ich die falschen Parameter benutzte.
Ich arbeite daran. :wink:

.... Mühsam ernährt sich das Eichhörnchen .... :roll:

Zottel · 21 April 2005

joker76 schrieb:
Zurück zum Hauptproblem:

Bei MSVC gibt es das Tool "lib.exe", mit welcher sich die dll generieren lässt. Leider zeigt er auch mit lib.exe das die Datei beschädigt ist.

Sorry, bitte mehr Präzision! Was bitte läßt sich mit lib.exe generieren und woraus?
1. Eine .DLL? Wenn ja, aus welchen Files?
2. Oder doch eher die .lib-Datei aus der vorhandenen .DLL?
Falls 2 richtig ist UND die entstehende .lib-Datei angeblich wieder nicht in Ordnung ist, hätte eine Vermutung, was schief gehen könnte und würde euch zu dem Zweck 2 oder drei Testfälle schicken wollen.

Anonymous · 21 April 2005

Folgenden Beitrag habe ich gefunden:

Entweder Du lädst die Funktionen der DLL dynamisch, dann benötigst du
keine
> lib.
> Oder du erstellst dir mit dem Kommandozeilentool lib.exe (VC++
Lieferumfang)
> eine passende lib.

Jedoch schlägt bei mir der Versuch fehl, aus der DLL eine passende lib zu erstellen.

Wollte mich Morgen etwas näher damit befasse, dann habe ich auch Borland.

joker76 · 21 April 2005

Böderweise war ich nicht eingelogt.

Es wäre nett, weitere Versionen zu schicken, dann könnte wir morgen Abend damit testen.

Zottel · 21 April 2005

So also wird, wie ich vermutet habe, mit lib.exe eine .lib aus einer .dll erstellt. Lib.exe ist also das Gegenstück zu Borlands implib.exe.
Nun wäre es natürlich gut, wenn du mir die Fehlermeldungen, die lib.exe produziert, nicht vorenthalten würdest.
ICH SHE HIER WIRKLICH EIN PROBLEM UND DAS WAR AUCH IN DEN ANDEREN POSTINGS SCHON SO: ICH MUSS IMMER NACHFRAGEN!

joker76 schrieb:
...
Es wäre nett, weitere Versionen zu schicken, dann könnte wir morgen Abend damit testen.

So also wird, wie ich vermutet habe, mit lib.exe eine .lib aus einer .dll erstellt. Lib.exe ist also das Gegenstück zu Borlands implib
Ich werde es versuchen. Allerdings "blind" Meine Vermutungen sind:
1.#define LITTLEENDIAN beißt sich mit einer Definition in winsock2.h
Es wird daher:
#define LITTLE_ENDIAN
2. Die globale Variable daveDebug in einer dynamischen Bibliothek ist unsauber: Wenn ein Programm sie auf einen Wert setzt, gilt der auch für alle anderen. Das kann ich nicht auf die Schnelle ändern, aber ich werde sie vor dem Compiler "verstecken". Anwenderprogramme müssen dann daveSetDebug() aufrufen, um sie zu verändern und können mit daveGetDebug() den Wert lesen.
Du wirst dann auch ein neues header file nodave.h bekommen und verwenden müssen.
Am besten legst du ein neues Arbeitsverzeichnis an, damit du mit den älteren Sachen unverändert weiterarbeiten kannst, wenn's nix bringt.

Zottel · 22 April 2005

So, im Anhang libnodave mit leichten Änderungen. Es gibt KEIN Unterverzeichnis win. Alles steht in einem Verzeichnis.
Vergleiche testISO_TCP.c, um die Änderungen zu sehen, die wegen daveDebug nötig sind.

Anonymous · 22 April 2005

Ich habe mich oft gefragt, warum bei den kommerziell vertriebenen MPI-Treibern für jedes Programmiersystem (BC, VC, VB, Delphi usw.) getrennte DLLs dabei sind. Nun, wenn ich mir den Rattenschwanz hier ansehe, dann weis ich warum.

Zottel · 22 April 2005

Gast schrieb:
Ich habe mich oft gefragt, warum bei den kommerziell vertriebenen MPI-Treibern für jedes Programmiersystem (BC, VC, VB, Delphi usw.) getrennte DLLs dabei sind. Nun, wenn ich mir den Rattenschwanz hier ansehe, dann weis ich warum.

Soweit ich weiß, ist etwa die AGLink.dll in allen Unterverzeichnissen dieselbe. Libnodave funktioniert darüberhinaus auch auf Linux auf PCs und, nach Angaben von Nutzern, auf Linux mit ARM-Prozessor und FreeBSD.

Anonymous · 22 April 2005

Hallo,
ich weis aus eigener Erfahrung, dass eine z.B. mit BC erstellte LIB/DLL nicht binärkompatibel mit den LIB/DLL von VC ist. Es sind immer Konvertierungen notwendig, wenn der Hersteller der LIB nicht schon Vorkehrungen getroffen hat. Dazu gehören z.B. auch spezielle Schlüsselwörter bei den Export-Funktionen.
Werden diese Kriterien nicht eingehalten, dann werden teilweise Funktionen nicht gefunden oder beim Aufruf passieren Abstürze.

Gruß Borlander

Zottel · 22 April 2005

Borlander schrieb:
Hallo,
... Es sind immer Konvertierungen notwendig, wenn der Hersteller der LIB nicht schon Vorkehrungen getroffen hat. Dazu gehören z.B. auch spezielle Schlüsselwörter bei den Export-Funktionen. ...

Es wäre jetzt schön gewesen, wenn du mir als Hersteller der .lib, gleich gesagt hättest, welche das sind.

Anonymous · 23 April 2005

Zottel schrieb:
Soweit ich weiß, ist etwa die AGLink.dll in allen Unterverzeichnissen dieselbe. Libnodave funktioniert darüberhinaus auch auf Linux auf PCs und, nach Angaben von Nutzern, auf Linux mit ARM-Prozessor und FreeBSD.

Hi,
ich habe mir die verschiedenen produkte wie aglink, libnodave und andere mal näher angesehen und denke, dass aglink und libnodave kaum vergleichbar sind. aglink läuft zwar nur unter w32, unterstützt aber wesentlich mehr hardware wie libnodave, wie auch die cps, welche in den siemens pcs verbaut sind. leider muss ich prodave von siemens einsetzen, da mein chefe siemenshörig ist.

ciao

markus

Zottel · 23 April 2005

Anonymous schrieb:
.... aglink läuft zwar nur unter w32, unterstützt aber wesentlich mehr hardware wie libnodave, wie auch die cps, welche in den siemens pcs verbaut sind.

Wobei AgLink (und wohl auch Prodave) die darunterliegenden Treiber und den Mechanismus zur "Einstellung der PG-Schnittstelle" nutzen. Beides ist nicht ohne weiteres auf andere Systeme portierbar. Insbesondere gibt es keine frei verfügbaren Informationen über die Hardware der CPs, mittels derer man Treiber schreiben könnte.

joker76 · 25 April 2005

Hi,

hier mal ein kleines Zwischenergebnis unserer Prüfung:

1. Borland installiert:

War leider ien Fehler dafür den gleichen Rechner zu verwenden, danach habe ich 31 Fehler unter MVC gesucht die ich vorher nicht hatte.
Das Ergebnis war, daß Borland die Installationsvariabeln umschreibt, so daß MVC die Pfade nicht mehr findet.
Eine Neuinstallation von MVC löste das Problem.

2. Eine Kompilierung des Projekts ist unter MVC möglich (neue Version von Libnodave), jedoch scheint er bei der Erstellung ein Problem mit "daveDebug" zu haben.

3. Klammert man "daveDebug" aus, so schaffen wir es, daß der Kompiler beim erstellen, diesen Fehler ingnoriert.
Jedoch bekommen wir dann den Fehler:
"libnodave_3_240405.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) void __cdecl _daveDump(char *,unsigned char *,int)" (__imp_?_daveDump@@YAXPADPAEH@Z)"

Aber das liegt ja daran, daß wir die DLL nicht einbinden können.

4. Auf Borland schaffen wir es, daß alles Fehlerfrei kompiliert und erstellt wird. Naja bis auf eine Warnung, aber die eher unwichtig ist, weil die Variabel einfach nicht benutzt wird.
Beim erstellen der Datei, was auch erfolgreich passiert, haben wir das Ergebnis, daß unsere Datei nichts macht. Der Inhalt entspricht der "testISO_TCP".

Unsere Vermutung ist erstmal, unsere Unkenntnis im Umgang mit Borland.
Ist doch schon ein bischen anders aufgebaut als MVC.

5. Das konvertieren der DLL mit "LIB.EXE" hat auch kein positives Ergebnis gebracht. Auch LIB.EXE sagt. daß die Datei beschädigt ist.

-> Morgen werden wir mal mit unserem Lehrer erstmal alles durchgehen, um herauszufinden ob wir irgendwo was übersehen haben, oder falsch gemacht haben.

:roll:

Zottel · 25 April 2005

joker76 schrieb:
Hi,

hier mal ein kleines Zwischenergebnis unserer Prüfung:

1. Borland installiert:

War leider ien Fehler dafür den gleichen Rechner zu verwenden, danach habe ich 31 Fehler unter MVC gesucht die ich vorher nicht hatte.
Das Ergebnis war, daß Borland die Installationsvariabeln umschreibt, so daß MVC die Pfade nicht mehr findet.
Eine Neuinstallation von MVC löste das Problem.

Dazu kann ich natürlich gar nichts sagen.

joker76 schrieb:
2. Eine Kompilierung des Projekts ist unter MVC möglich (neue Version von Libnodave), jedoch scheint er bei der Erstellung ein Problem mit "daveDebug" zu haben.

Weil ich ja so etwas auch vermutet habe, habe ich euch doch die geänderte Version geschickt (Als Anhang hier im Forum).

joker76 schrieb:
3. Klammert man "daveDebug" aus, so schaffen wir es, daß der Kompiler beim erstellen, diesen Fehler ingnoriert.
Jedoch bekommen wir dann den Fehler:
"libnodave_3_240405.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) void __cdecl _daveDump(char *,unsigned char *,int)" (__imp_?_daveDump@@YAXPADPAEH@Z)"

Aber das liegt ja daran, daß wir die DLL nicht einbinden können.

4. Auf Borland schaffen wir es, daß alles Fehlerfrei kompiliert und erstellt wird. Naja bis auf eine Warnung, aber die eher unwichtig ist, weil die Variabel einfach nicht benutzt wird.
Beim erstellen der Datei, was auch erfolgreich passiert, haben wir das Ergebnis, daß unsere Datei nichts macht. Der Inhalt entspricht der "testISO_TCP".

Warnungen sind keine Fehler! Bei der kompletten Erstellung von libnodave mit BCC gibt es eine ganze Reihe (20+?) Warnungen. Ein Teil davon wäre auch bei sorgfältiger Überarbeitung des Codes nicht vermeidbar.
"Nichts macht" ist mir schon wieder viel zu ungenau.

joker76 schrieb:
Unsere Vermutung ist erstmal, unsere Unkenntnis im Umgang mit Borland.
Ist doch schon ein bischen anders aufgebaut als MVC.

Um die dll und alle Testprogramme zu kompilieren, sollte es reichen die Datei winmake.bat zu starten. Vorraussetzung: Libnodave befindet sich im Verzeichnis BCC/libnodave-x.x.x.
Dabei wird das Make-Tool von Borland mit der der Datei Makefile.MAK aufgerufen. Um diesen Mechanismus zur Kompilierung eigener Programme zu nutzen, entweder:
1. Eine entsprechende Zeile in Makefile.MAK einfügen.
2. Oder testISO_TCP so verändern, daß es das macht, was ihr wollt.
Eins noch: Die Testprogramme werden "statisch" gelinkt. Sie benutzen libnodave.dll gar nicht! Statt dessen binden sie direkt die Objekt-Dateien nodave.obj und setportw.obj bzw openSocketw.obj ein.
mit: ../imake -fMakefile.MAK dynamic
oder winmake.bat dynamic (hoffe, das geht)
wird eine 2. Serie von Testprogrammen erzeugt, die so heißen wie die statischen, mit einem zusätzlichen "d" also testISO_TCPd.exe u.s.w. .Diese benutzen libnodave.dll.

joker76 schrieb:
5. Das konvertieren der DLL mit "LIB.EXE" hat auch kein positives Ergebnis gebracht. Auch LIB.EXE sagt. daß die Datei beschädigt ist.
-> Morgen werden wir mal mit unserem Lehrer erstmal alles durchgehen, um herauszufinden ob wir irgendwo was übersehen haben, oder falsch gemacht haben.

joker76 · 27 April 2005

Hallo,

also wir habe uns gestern wieder um die Sache gekümmert.

Hier mal das Ergebnis (zur Info):

1. Das Ausführen von Winmake.bat ist daran gescheitert, das wir das Make-Tool von Borland nicht hatten.

Das von MVC geliefert Tool heißt: nmake.exe , interpretiert leider das
Makefile.mak nicht richtig und hat Probleme mit der Verzeichnisangabe.

Ein korrektur der Makfile.mak-Datei , brachte uns dann ein kleines Stück weiter, jedoch versagte die Erstellung der *.Exe-Dateien.

2. Nach etwas forschen haben wir herausgefunden, das der Compiler von Borland 5.5 verwendet wurde. Der von Borland 6.0 ist leider nicht kompatibel und führt auch zu keinen positiven Ergebnis.

3. Nachdem wir uns den Compiler von Borland 5.5 besorgt hatten, und zu unseren Glückseligkeit die make.exe mit vorhanden war, haben wir Winmake erneut aufgerufen.

4. Seit gestern können wir erfolgreich eine Verbindung zu unseren S7-Steuerung aufbauen und die gewünschten Daten auslesen.
Ein for-Schleife sorgt dafür das wir alle 64 Ventil-Zustände auslesen. Mit dem Parameterzusatz >testfile.csv bekommen wir auch alles in eine Datei.

Echt easy!

5. Jetzt brauchen wir nur noch alles aus dem C-file rauszunehmen was wir nicht brauchen.

:wink:

Und an dieser Stelle, wollen wir uns nochmal für die freundliche Unterstützung von Zottel bedanken. :lol:

Zottel · 27 April 2005

joker76 schrieb:
Hallo,
4. Seit gestern können wir erfolgreich eine Verbindung zu unseren S7-Steuerung aufbauen und die gewünschten Daten auslesen.

Gut. Scheiße, daß Borland 6 nicht mit 5.5 kompatibel ist. Ich werde das kenntlich machen.

Ein for-Schleife sorgt dafür das wir alle 64 Ventil-Zustände auslesen. Mit dem Parameterzusatz >testfile.csv bekommen wir auch alles in eine Datei. Echt easy!

Schön. Ein Wort noch zur Schleife:
die Schleife sollte so aussehen:

daveReadBytes(dc, bla,bla,,bla,64,NULL);
for (i=0;i<64;i++) {
wert=daveGetU8(dc);
fprintf("<format>", wert);
}

oder für Worte:

daveReadBytes(dc, bla,bla,,bla,128,NULL);
for (i=0;i<64;i++) {
wert=daveGetU16(dc);
fprintf("<format>", wert);
}

Aber auf KEINEN FALL:

for (i=0;i<64;i++) {
daveReadBytes(dc, bla,bla,,bla,1,NULL);
wert=daveGetU8(dc);
fprintf("<format>", wert);
}

64 Bytes oder auch 64 Worte kann man in einem einzigen Aufruf von daveReadBytes lesen (vielleicht nicht bei einer 212).
Aufrufe von daveReadBytes(dc, bla,bla,,bla,1,NULL) kommunizieren wirklich mit der CPU und brauchen richtig viel Zeit.
wert=daveGetU8(dc); hingegen ist nur "Umschaufeln" im Speicher des PC.

joker76 · 27 April 2005

Ich habe bestehende Funktion wie folgt abgeändert:

res=daveReadBytes(dc,daveDB,301,260,128,NULL);
if(0==res) {

for (i=1;i<65;i++)
{

a=daveGetWORD(dc);
printf("%d,ESG00%i \n",a,dc);
}

...

??? Die Werte werden korrekt ausgelesen. :?

Zottel · 27 April 2005

joker76 schrieb:
for (i=1;i<65;i++)
{

a=daveGetWORD(dc);
printf("%d,ESG00%i \n",a,dc);
}

Ich kanns ja nicht lassen:
for (i=0;i<64;i++)
ist immer dann empfehlenswert, wenn man Arrays indiziert. Es ist aber möglicherweise auch schneller und kürzer als
for (i=1;i<65;i++)
weil der Compiler für j=1 eine Konstante anspricht "MOX EAX,1", während er für j=0 ein "XOR EAX,EAX" einsetzen kann.
for (i=64;j>0;--) ist möglicherweise noch schneller, weil die meisten Prozessoren so einen Befehl wie "zähle runter und springe bei nicht 0" haben (LOOP auf dem x86).
Hier kommt's bestimmt nicht drauf an, aber wenn man sich das so angewöhnt ist es hier und da zum Vorteil.

joker76 · 27 April 2005

for (i=1;i<65;i++)

hui,

hab es falsch vom Laptop abgeschrieben.
Es soll heißen: (i=0;i<65;i++)

Die 65 habe ich reingetan, weil er mir das letzte Integer-Wort nicht mir übertragen hat.

[/code]

HeizDuese · 25 September 2005

Hi !

Auch wenn der Thread schon was älter ist, nutze ich Ihn mal für meine Frage, weil das Bisherige da schon zu passt:

"Gibt es eine Möglichkeit / Tool, um z.B. über Delphi auch auf PLCSIM zu zugreifen, um die z.B. die DB's auszulesen / zu beschreiben?"

Die Sachen, die ich bisher kenne (Prodave), machen den Verbindungsaufbau grundsätzlich über die physikalische Schnittstelle (z.B. COM1).

S7 <> PC über Ethernet

Level-2

Level-3

Anonymous

Guest

Level-2

Level-3

Level-3

Anhänge

Anonymous

Guest

Level-3

Anonymous

Guest

Level-3

Anonymous

Guest

Level-3

Level-2

Level-3

Level-2

Level-3

Level-2

Level-3

Level-2

Level-1

Similar threads

Wir schützen deine Privatsphäre