# S7 <> PC über Ethernet



## joker76 (22 Februar 2005)

Hallo,

für eine Projektarbeit haben wir uns gedacht, daß wie eine S7-Steuerung an ein PC über Ethernet verbinden. 

Am PC wollten wir dann, die Prozessdaten mit einem PHP-Skript in eine SQL-Datenbank schreiben, und diese auch als Html-Seite im Intranet zur Verfügung stellen.


Hat einer sowas ähnliches schon realisiert ? 
SPS und Ethernet CP haben wir, was brauchen wir aber PC-seitig ? 

Danke


----------



## bs (22 Februar 2005)

Hallo,

schau mal dort nach:



http://www.sps-forum.de/phpBB2/viewtopic.php?t=2439


----------



## Zottel (22 Februar 2005)

Oder libnodave:
http://libnodave.sf.net


----------



## joker76 (5 April 2005)

*Libnodave*

Hallo,

für unsere Schulprojekt haben wir uns für Libnodave entschieden.

Nun stehe ich noch vor ein paar Verständnisprobleme.

Werde die einzelnen Programme hintereinander mit entsprechender Parametrierung aufgerufen? 

Oder muss ich ein C-Programm schreiben, in welchenm die 
C-Quelldateien eingebunden werden ?

Unser Ziel ist es, aus einem Datenbaustein über Ethernet ein Bereich von 64 Integerwerte auszulesen, um diese dann in eine Datei zu schreiben.


Um jede  Hilfe wäre ich Dankbar.


----------



## Zottel (5 April 2005)

*Re: Libnodave*



			
				joker76 schrieb:
			
		

> Hallo,
> 
> für unsere Schulprojekt haben wir uns für Libnodave entschieden.


Am Anfang mancher Bedienungsanleitung wird dem Benutzer su seiner Wahl gratuliert...


> Nun stehe ich noch vor ein paar Verständnisprobleme.
> 
> Werde die einzelnen Programme hintereinander mit entsprechender Parametrierung aufgerufen?


Die verschiedenen Programme sind dazu gedacht, verschiedene Übertragungsverfahren (MPI; PPI, Ethernet mit CP, Ethernet mit IBH Link) zu testen.
Da ihr einen CP habt, ist testISO_TCP das richtige für  euch.
Bezüglich der Parameter: Ruft es ohne jedes Argument auf einer Kommandozeile (DOS-Box) auf. Es sagt dann, was es versteht.
Die beiliegenden Programme sind nur zum Test gedacht und sind nicht wirklich nützlich.
Sie haben zum Beispiel keine Parameter, um ihnen gezielt mitzutelen, was sie aus der SPS lesen sollen.
Libnodave an sich ist eine Bibliothek. Das heißt, sie enthält ein paar spezielle Funktionen zum Einbau in eigene Programme.


> Oder muss ich ein C-Programm schreiben, in welchenm die
> C-Quelldateien eingebunden werden ?


Du mußt keins von beiden. Statt C kannst du auch Pascal benutzen. Von den Dateien mußt du die header Dateien nodave.h und setport.h in dein Programm einbinden, wenn du in C programmierst.
Bei Pascal (oder Delphi) must du nodave.pas benutzen (mit uses nodave.pas).
Beim linken mußt du angeben, daß die Bibliothek libnodave als dynamische Bibliothek eingebunden werden soll. Auf windows ist dazu die Datei libnodave.lib erforderlich, die mitgeliefert wird.
Dies führt dazu, daß dein Programm später beim start Windows (oder Linux?) auffordert, die Bibliothek libnodave zu laden, worauf ihre Funktionen deinem Programm zur Verfügung stehen.


> Unser Ziel ist es, aus einem Datenbaustein über Ethernet ein Bereich von 64 Integerwerte auszulesen, um diese dann in eine Datei zu schreiben.


Wenn du dir den code in testISO_TCP.c anschaust, siehst du vielleicht, daß ein entsprechendes Programm durch einige Änderungen daraus erzeugt werden kann:
1. testISO_TCP liest ja schon 64 bytes von DB1. (Zeile 314 ff.). Was, wieviel und woher es liest wird durch die Parameter von daveReadBytes bestimmt. 
daveReadBytes(dc, area, DBnummer, start, anzahl, puffer). Die Nummer des DBs müßt ihr anpassen. Weiterhin sind 64 Integer 128 bytes. Ihr müßt also die Anzahl auf 128 setzen.
Wenn Ihr nich ab Datenbyte 0 beginnen wollt, müßt ihr auch die Startadresse ändern.
Schließlich druckt das Testprogramm nur die ersten 2 und den letzten Wert aus.
Ihr könnt in einer Schleife 64 mal daveGetWord(dc) aufrufen. Das holt jedes mal den nächsten Wert als Wort aus dem internen Puffer. Diesen Wert könnt ihr ausdrucken. 

Von dem Testprogramm könnt ihr danach alles streichen, was nicht nötig ist. Das meiste ist für euch nicht nötig.

Das entstandene Programm schreibt euch nun die 64 Werte hintereinander auf den Bildschirm. Um in eine Datei zu schreiben, ruft ihr nun einfach.
meinprog >meinedatei auf.
Statt auf den Bildschirm zu schreiben, schreibt es nun in die neu erstellte Datei meinedatei.

Auch in PHP kann man das ganz leicht einbinden: PHP kennt einen Befehl (habe den Namen gerade nicht parat), um ein externes Programm auszuführen. Die Ausgabe dieses Programmes steht danach in einem PHP-array und kann in die HTML-Seite eingebaut werden.


----------



## joker76 (13 April 2005)

Hi,

ich bräuchte noch einmal Starthilfe,

ich habe nun unter Visual Studio die C-Quellen importiert.
nodave.h und setport.h als Header-Dateien und testiso_TCP.

Nun bekomme ich beim Kompilieren ein Fehlermeldung :

-> fatal error C1189: #Fehler :  Fill in what you need for your OS or API.<-

Welche Anweisung muss ich den jetzt bearbeiten ?
Ich bekomme irgendwie nicht weiter ....


----------



## Zottel (13 April 2005)

joker76 schrieb:
			
		

> Hi,
> 
> ich habe nun unter Visual Studio die C-Quellen importiert.
> nodave.h und setport.h als Header-Dateien und testiso_TCP.


nodave.h brauchst du immer, setport.h für serielle Verbindungen, openSocket.h für Ethernet Verbindungen. Du brauchst also openSocket,h


> Nun bekomme ich beim Kompilieren ein Fehlermeldung :
> -> fatal error C1189: #Fehler :  Fill in what you need for your OS or API.<-


Du must die Compilerdirektiven BCCWIiN und LITTLEENDIAN definieren, z.B. so:

#define BCCWIN
#define LITTLEENDIAN
#include nodave.h
#include openSocket.h

Für verschiedene Betriebssysteme enthält nodave.h kleine Teile in mehreren Varianten.
Diese Direktiven dienen dazu, die Variante auszuwählen.


----------



## joker76 (14 April 2005)

Hallo,

ich habe die Define-Anweisungen in meinem Programm ergänzt und bekomme folgende Fehlermeldung.

error C2006: #include: Dateinamen erwartet, aber 'identifier' gefunden

Es sieht so aus, als ob die Header-Datei nodave.h einen Dateinamen erwartet. 

Wie kann ich den ein Dateinamen als Argument einer Header-Datei mitgeben ?


----------



## Zottel (14 April 2005)

Sorry, es muß heißen:

#define BCCWIN 
#define LITTLEENDIAN 
#include "nodave.h"
#include "openSocket.h" 

Ich habe zwar die Anführungszeichen vergessen, aber generell solltet ihr die Syntax von #include kennen, bevor ihr euch an so ein Projekt macht.
Schon in einem einfachen Programm wie HelloWorld.c (könnt ihr sicher in fast jedem Lehrbuch und im Internet finden) wird ein #include vorkommen:

#include <stdio.h>
Hier steht der Name nich in Anführungszeichen, sondern in spitzen Klammern:
Der Unterschied:
Bei #include <datei.h> wird datei.h in den vom Compiler-Hersteller vorgegebenen Verzeichnissen gesucht, bei #include "datei.h" im momentanen Arbeitsverzeichnis.

Ich möchte euch nochmal auffordern, zunächst einmal das Testprogramm testISO_TCP.c als Vorlage zu nehmen. Dort habt ihr für eigentlich alles ein Vorbild.
Allerdings fehlen die beiden Zeilen:
#define BCCWIN 
#define LITTLEENDIAN 
Sie sind dadurch ersetzt, daß im Makefile.Mak dem Compiler die Definitionen:
-DBCCWIN -DLITTLEENDIAN 
mit der Kommandozeile übergeben werden. Beide Wege gehen. Der mit der Kommandozeile ist aber einfacher, wenn die Definitionen nicht immer gelten: Man braucht den Quelltext nicht zu ändern, sondern nur eine andere Kommandozeile.
So können die Programme unverändert unter Linux übersetzt werden, wobei in de Kommandozeile steht: -DLINUX -DLITTLEENDIAN 

Habt ihr keinen Betreuer für die Projektarbeit, der euch so was erklärt? Nicht, daß es mir zuviel wäre, aber ich fürchte, wenn ihr jede Woche eine Frage dieser Art habt, wird die Sache ca. 2 Jahre dauern...


----------



## joker76 (15 April 2005)

Hallo,

das mit den Include Einweisungen hatte ich schon versucht in der geklammerten Form zu schreiben. Nur bekommen ich dann ein anderen Fehler.

Nee, aber mein Problem ist, wir haben 1,5 Jahre halbherzig "C" gelernt und sind dann auf Java umgestiegen, so daß ich ein bischen auf C- raus bin.

Desweiteren hat mich mein "Betreuer" am Dienstag im Stich gelassen, und meinte ich sollte in der Hilfsdatei suchen. 

Unser Hauptmerkmal liegt bei unseren Projekt auf Folgenden Punkt:

1. Wir wollen beweisen das mit Open-Source Software eine   Kommunikation 
   zu einer Siemens-Steuerung möglich ist, ohne auf teuere Lizenzsoftware 
  zurückgreifen zu müssen.

2. Wir wollen beweisen das Open-Source Software Plattform unabhängig arbeiten kann, und nicht wie die teure Lizenzsoftware hauptsächlich für 
Windows geschrieben ist.

3. Wollen wir eine Wartungssoftware schreiben, die auf "Lampp" oder "Wampp" basiert und auf einen handelsüblichen Rechner läuft.

4. Die Wartungssoftware soll den Betreiber ermöglichen, alle Informationen einer Anlage (Ventile etc.) auf Verschleiss (in unseren Fall Schaltspiele unsere Ventile) zu entnehmen.



Desweiteren wollte ich mich bei dir noch ganz herzlich für die präzisen und schnellen Anworten bedanken.
Solche Grundlegenden Anworten hätte ich mir eigentlich von meinem Betreuer gewünscht.


----------



## Zottel (15 April 2005)

joker76 schrieb:
			
		

> Hallo,
> das mit den Include Einweisungen hatte ich schon versucht in der geklammerten Form zu schreiben. Nur bekommen ich dann ein anderen Fehler.


Welchen? Und warum geklammert (also <nodave.h>)? Dann müßte nodave.h im Standard-Includeverzeichnis des Compilers stehen.


----------



## joker76 (18 April 2005)

Hi,

ich bin das ganze mal Schrittweise angegangen und habe nach und nach die Headerdateien in mein Projekt importiert. Und vom der C-Datei Schritt für Schritt die einzelnen Funktionen.

Der erste Fehler (Warnung) ist die nicht benutzte, aber Definierte Variabel "c", in der Funktion "wait".
Kann man ja ausklammern oder löschen.

Der letzte Schritt war das Einfügen der Main, bis dahin hatte ich keine Fehlermeldungen beim kompilieren.

Nun kommt eine Fehlermeldung:

-> error C2440: '=' : 'int' kann nicht in 'void *' konvertiert werden

an dieser Stelle:

" fds.rfd=openSocket(102, argv[adrPos]);"

>Die Konvertierung eines ganzzahligen Typs in einen Zeigertyp erfordert ein reinterpret_cast-Operator oder eine Typumwandlung im C- oder Funktionsformat<

Das letzte ist wieder eine Warnung:

"warning C4244: 'argument' : Konvertierung von 'double' in 'float', moeglicher Datenverlust"


an dieser Stelle:

"d=toPLCfloat(d+1.1);"


Liegt es vielleicht an meinen Compiler (Microsoft Visual ?


Schönen Gruß


----------



## Zottel (18 April 2005)

joker76 schrieb:
			
		

> Der erste Fehler (Warnung) ist die nicht benutzte, aber Definierte Variabel "c", in der Funktion "wait".
> Kann man ja ausklammern oder löschen.


Kann man ebensogut stehen lasse, Warnungen sind keine Fehler, nur Hinweise des Compiler, daß er da etwas "Ungewöhnliches" gefunden hat. In diesem Fall ist es einfach so:
Die Funktion wait() wurde für LINUX geschrieben. Als sie sich nicht genauso unter Windows verwenden ließ, habe ich mir nicht die Mühe gemacht, das "in Ordnung zu bringen", sondern habe den Code einfach durch #ifdef ausgelassen. Wait() tut auch nichts wichtiges; es wartet einfach auf einen Tastendruck, damit man Zeit hat, die Bildschirmausgabe zu lesen.


> -> error C2440: '=' : 'int' kann nicht in 'void *' konvertiert werden
> an dieser Stelle:
> " fds.rfd=openSocket(102, argv[adrPos]);"
> >Die Konvertierung eines ganzzahligen Typs in einen Zeigertyp erfordert ein reinterpret_cast-Operator oder eine Typumwandlung im C- oder Funktionsformat<
> ...


Ja das ist ein echter Fehler. Aber er wird eben von BorlandC nicht bemeckert. Grund ist: Unter Linux wird eine Datei oder ein Socket gleichermaßen mit einem file descriptor angesprochen. Unter Windows gibt es dafür 2 verschiedene Datentypen: Ein Datentyp "handle" für Dateien oder "socket" für  Sockets (TCP-Verbindungen). Beides soll an dem gleichen Speicherplatz in daveOSserialType abgelegt werden. Der Platz reicht auch (sonst könnte es auch unter BorlandC nicht gehen). Aber die C-Compiler werden immer kritischer bezüglich der Prüfung von Datentypen...
Eine "saubere" Lösung wäre es, eine union der 2 Datentypen zu verwenden. Das kann ich für die nächste Version vorsehen, aber es erfordert eine Neuübersetzung der DLL.
Eine schnelle Lösung sollte folgendes sein:

fds.rfd=(void*)openSocket(102, argv[adrPos]);


> "warning C4244: 'argument' : Konvertierung von 'double' in 'float', moeglicher Datenverlust"
> an dieser Stelle:
> "d=toPLCfloat(d+1.1);"


Wenn du willst, kannst du die Variable d als float statt als double deklarieren.


----------



## Zottel (18 April 2005)

Zottel schrieb:
			
		

> > "warning C4244: 'argument' : Konvertierung von 'double' in 'float', moeglicher Datenverlust"
> > an dieser Stelle:
> > "d=toPLCfloat(d+1.1);"
> 
> ...


Habe gerade gesehen, daß die Variable bereits float ist. Was hier passiert ist: 
Der Compiler kodiert eine Multiplikation der float-Variablen d mit der Konstante 1.1, die er als double auffaßt. Das Ergebnis ist double, daher"Konvertierung  'double' in 'float', moeglicher Datenverlust" Dem kannst du abhelfen, indem du die Konstante als 1.1f schreibst. Dann soltte sie float sein.


----------



## joker76 (19 April 2005)

Hi,

so nun das kleine Problem mit dem Float hatte ich behoben und auch sonst gab es keine Schwierigkeiten.

Nun kann ich zwar mein Projekt kompilieren, bekomme aber beim erstellen der Datei einen Link-Fehler: LNK1136 Ungültige oder beschädigte Datei.


Kann es sein das mein VC6.0 die Borland-DLL nicht versteht ?   


P.S. Ich habe mal versucht mit einen einfachen Link befehl die Datei libnodave.lib zu öffnen. Auch das führte zum Ergebnis das die Datei beschädigt ist.


----------



## Zottel (19 April 2005)

joker76 schrieb:
			
		

> Hi,
> 
> so nun das kleine Problem mit dem Float hatte ich behoben und auch sonst gab es keine Schwierigkeiten.
> 
> ...


Das habe ich heute schon einmal gelesen,


> Linking...
> libnodave.lib : fatal error LNK1136: invalid or corrupt file
> Error executing link.exe.


(Beitrag von johannlinner von heute auf
http://sourceforge.net/forum/forum.php?thread_id=1266429&forum_id=205657
)
Hier aber mit dem wesentlichen Hinweis auf libnodave.lib.
Insgesamt allerdings zum ersten Mal. Ok, andere Leute haben Delphi genommen...
Ich glaube, es ist kein Problem mit der DLL, eher eines von:
1. VC6.0 versteht die datei libnodave.lib nicht (wahrscheinlich). 
2. VC6.0 versteht irgendetwas in nodave.h so, daß es etwas anderes in der .lib oder .dll erwartet als drin ist.
Da kann ich dir jetzt wahrscheinlich nicht helfen. Mein Rat an den anderen Benutzer war:

Im file MAKEFILE.MAK kannst du sehen, daß libnodave.lib erzeugt wird durch:
($BCCPATH)implib libnodave.lib libnodave.dll
"implib" ist ein Werkzeugprogramm. Was es genau tut weiß der Teufel. Ich bin kein Experte für Windows. Vermutlich erzeugt es eine Liste der Funktionsnamen (und der Einsprungadressen?).
Es sollte ein zu VC gehöriges Tool geben, was dasselbe leistet. Damit libnodave.lib neu erzeugen und schauen, was passiert.

Das kanst du auch probieren.
Oder du probierst, die ganze DLL mit VC neu zu erzeugen.
Oder du probierst, nodave.c und openSocketw.c zu Objetdateien zu kompilieren und diese statisch in dein Programm einzubinden
Oder du besorgst dir die Borland-Werkzeuge.
Ansonsten muß du warten, bis sich einer meldet, der es mit VC zum Laufen bekommt und mir sagt, was dazu verändert werden muß.


----------



## joker76 (20 April 2005)

> >> Hätten die Borländer denn eine
> > Einstelloption die lib so erstellen, daß man sie in VC++ ohne Umwege
> > statisch laden kann ? (Für die Zukunft)
> 
> ...




Das habe ich bei meiner Suche für eine Lösung gefunden.

Scheinbar liegt es an den beiden unterschiedlichen Kompilern.

Als Lösung ist das dynamische Laden der DLL vorgeschlagen worden, aber ich habe es bis jetzt noch nicht geschaft.


----------



## Zottel (20 April 2005)

joker76 schrieb:
			
		

> > >> Hätten die Borländer denn eine
> > > Einstelloption die lib so erstellen, daß man sie in VC++ ohne Umwege
> > > statisch laden kann ? (Für die Zukunft)
> >
> ...


----------



## Gerhard Bäurle (21 April 2005)

joker76 schrieb:
			
		

> 1. Wir wollen beweisen das mit Open-Source Software eine   Kommunikation
> zu einer Siemens-Steuerung möglich ist, ohne auf teuere Lizenzsoftware
> zurückgreifen zu müssen.
> 
> ...



Mahlzeit,

beides ist mit endlichem Aufwand sicher technisch machbar.

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

Viele Grüße

Gerhard Bäurle

Edit: -h


----------



## Zottel (21 April 2005)

Nun kann ich's nicht lassen:


			
				joker76 schrieb:
			
		

> 1. Wir wollen beweisen das mit Open-Source Software eine   Kommunikation
> zu einer Siemens-Steuerung möglich ist, ohne auf teuere Lizenzsoftware
> zurückgreifen zu müssen.


Das IST bewiesen. Habe ich 2*365*24 Stunden laufen.


> 2. Wir wollen beweisen das Open-Source Software Plattform unabhängig arbeiten kann, und nicht wie die teure Lizenzsoftware hauptsächlich für
> Windows geschrieben ist.


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?
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). 


			
				deltalogic schrieb:
			
		

> Mahlzeit,
> beides ist mit endlichem Aufwand sicher technisch machbar.


Kostet mich nur 10 Minuten.


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


Die Probleme, die hier bis jetzt behandelt wurden, entstehen durch 3 Teilaspekte:
1.  joker76 ist mit seinem Werkzeugkasten unzureichend vertraut. Dies dominierte den Thread über die ersten 2/3 und er würde mit AGLink vermutlich nicht besser darstehen (ok, AgLink braucht keine conditional defines, da es nur für Windows ist. Wenn 64bit-Windows kommt, hat Deltalogic die Wahl, ebenfalls diesen Weg zu gehen oder eine getrennte Version auszuliefern und getrennt zu pflegen).
2. Die Benutzung fremder Bibliotheken bedeutet immer, sich in die entsprechende Programmierschnittstelle einzuarbeiten; das ist bei AgLink nicht anders. Für die Wirtschaftlichkeit bedeutet das, daß man immer die Einarbeitungszeit für das erste Projekt mit ansetzen muß.
3.  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.


----------



## 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++
> ...



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:
> 
> ...


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)"
> 
> ...


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);
> ...


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).


----------



## RolfB (25 September 2005)

da gibt es ein COM - Objekt in PLCSIM
'S7Prosim'.
Hier mal ein Link:
http://support.automation.siemens.com/WW/view/de/1139855

Ich selbst habe damit noch nichts gemacht und
da ich von Delphi absolut keine Ahnung habe, weiß ich nicht
ob, und wenn ja, wie man das einbindet.

Aber die Richrung könnte stimen. :wink: 

mfg.

Rolf


----------



## HeizDuese (25 September 2005)

Danke für die schnelle Antwort !

Die Beschreibung lässt tatsächlich hoffen.

Schade, dass es nichts Universielles gibt, was für phyiskalische Kopplung und für Kopplung via PLCSIM gleichermaßen geeignet ist. Die Siemens- eigene Software nutzt diese Technik ja - dort kann man im Simatic-Manager und z.B. im WinCC / Protool völlig transparent zwischen echter SPS und simulierter hin- und herschalten - es müsste demnach (seitens Siemens) bereits eine "Schnittstelle" geben (S7API ?).


----------

