Libnodave mit CP443-1 ISO

Zuviel Werbung?
-> Hier kostenlos registrieren
Ok, das sieht schon gut aus.
Ich habe gestern ein bischen herumgespielt, um eine Möglichkeit zu finden, Ethernet-Pakete beliebigen Inhalts (nicht TCP/IP) aus Windows zu verschicken. Bei google habe ich eine Menge Zeug gefunden, das ich nicht allzu schnell überblicken konnte. Es scheint spezielle Treiber (NDIS-Treiber) zu erfordern. Keine Ahnung, ob die mit Windows kommen (in meiner Installation ist keiner) oder ob die Anwendung sie mitbringen muß. So etwas will nicht selbst schreiben. Ein gangbarer Weg scheint zu sein, eben die Treiber zu benutzen, die mit Ethereal kommen (eine Bibliothek namens Winpcap). Das muß sich dann halt jeder installieren, der Libnodave mit ISO nutzen will.
Senden geht schon mal. Empfangen noch nicht probiert.
Ein anderes Problemchen sind Pakete, die mit der S7-Kommunikation nix zu tun haben: Es könnten Quittungen auf der ISO-Ebene sein oder eine Art "keep alive", damit die Verbindung aufrecht erhalten wird, wenn ansonsten Pause ist.
Ich schick dir morgen oder übermorgen eine Testversion.
 
klasse, wie du das so schnell überblicken konntest.
ich habe gerade die installierten Treiber durchsucht.
Für meine Netzwerkkarte ist ein Treiber namens:
  • Ekahau NDIS Usermode I/O Protokol
installiert. Weiß allerdings nicht, ob sie von Ethereal kommt, glaube aber, dass der von Step 7 stammt.
muss kurz die andere Partition hochfahren, da habe ich kein Ethereal drauf.
Melde mich gleich
 
Zuviel Werbung?
-> Hier kostenlos registrieren
da bin ich wieder.
Also die NDIS Treiber sind auf der anderen Partition nicht insstalliert, das erklärt auch, warum ich da du mein PC/PG nicht auf das ISO Protokoll einstellen kann.
Wenn ich das jetzt richtig verstanden habe liegt es an den NDIS Treiber, weil
1. ISO Ind.Eth. Treiber installiert (Netzwerkverbindungen von WIN)
Damit kann ich unter Step7 die installierten PC/PG Schnittstellen die Option "ISO Industrial Ethernet -> meine Netzwerkkarte" sehen.

2. NDIS Treiber nicht installiert, kann ich unter "benutzte Schnittstellenparametrierung" die "ISO Ind.Ethernet -> m. Netzwerkarte" nicht wählen.
Unter Beschreibung der Schnittstelle steht deutlich:
SIEMENS Industrial Ethernet ISO-Protokoll auf Ihrer NDIS- Netzbaugruppe (CP)

Damit ist alles klar, dass der Treiber entweden von Windows oder von Siemens kommt. Versuche die NDIS Treiber ausfindig zu machen und auf der anderne Partition installieren.

Roman
 
hallo Zottel,
hast du mir etwas geschickt ?
hab noch eine Frage zu der Funktion "daveReadBits"
wie kann ich die am einfachstem in c- auswerten. Die gibt doch den Zeiger zurück, oder? Wie kann ich mehrere Bits auswerten?

Grüße
Roman
 
Roman_kr schrieb:
hallo Zottel,
hast du mir etwas geschickt ?
Nein, noch nicht. Habe zwischendurch erst ein paar andere Dinge gemacht. Dein ISO hängt im Momet daran, daß ich den Empfang von Paketen noch nicht angefangen habe.
hab noch eine Frage zu der Funktion "daveReadBits"
wie kann ich die am einfachstem in c- auswerten.
Siet man das nict in testMPI oder den aderen Testprogrammen?
Die gibt doch den Zeiger zurück, oder?
Nein, wie fast alle Funktionen gibt sie einen Fehlercode zurück.
Das Ergebnis, ob das Bit gesetzt ist, bekommst du z.B. wenn du:
- mit daveGetU8(dc) das erste Byte aus dem internen Puffer holst
- prüfst, ob es 0 oder nicht 0 ist.
Wie kann ich mehrere Bits auswerten?
Das ist nicht so einfach, wie du vieleicht denkst: daveReadBits hat einen Parameter len, count oder so. Da möchte man glauben, daß man eine Länge angibt und mehrere aufeinenderfolgende Bits liest. Das geht aber auf keiner CPU, die ich getestet habe. Der Parameter ist trotzdem da weil:
Falls CPU, die ich nicht getestet habe oder eine zukünftige Firmware für existierende CPUs des Lesen einer Folge von Bits unterstützen würde, wäre es der natürliche Platz dafür.

Generell ist Bits lesen recht ineffizient.

Wenn du partout mehrere Bits lesen mußt und nicht gleich die Bytes lesen willst, in denen sie enthalten sind, kannst du auch mehrere Variablen (Bits und Bytes gemischt oder nur Bits) mit einem einzigen Aufruf lesen, indem du den Mechanismus zum Lesen mehrerer Variablen mit einem einzigen request nutzt:
davePrepareReadRequest()
daveAddBitVarToReadRequest() // für Bit-Variablen
daveAddVarToReadRequest() // jedes Byte-Variablen
daveExecReadRequest()

mit
daveAddVar...
kannst du bis zu 20 Variablen hinzufügen (bei einer 315-2DP, aber ich glaube, es ist allgemein so. Bei einer 212 ist es wohl weniger).
erst der Aufruf von daveExecReadRequest() schickt das ganze zur SPS und wartet auf die Antwort. Das Auswerten der Antwort schaust du dir am besten in testISO_TCP.c an. Es wird gemact, wenn du das Programm mit der Option -m aufrufst. Intern wird das flag doMultiple gesetzt und du kannst nachschauen, was das Programm an der Stelle:
if (doMultiple) {
}
tut.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hallo,
die Sache mit den Bitsauswerten habe ich schon in Griff bekommen.
Hab wohl aus der TestIso_Tcp.c nur die Zeilen rauskopiert, damit sie in meine Anwendung passen. Leider nicht weiter unten geschaut :oops:
Sorry.
Im Moment versuche ich, die Verbindung in eine Klasse zu packen.
Nun habe ich ein Problem. Als Konsolenanwendung läßt sich deine dll problemlos linken. Versuche ich als Win32 oder MFC Anwendung, also klasische Windows Anwendung zu linken, meldet mein Kompiler (MS VC++ 6)
für jede verwendete Libnodave Funktion:
Nichtaufgelöstes externes Symbol ....
obwohl ich den Linker mitgeteilt habe, Libnodave.lib zu integrieren.
Gelten für "Fensteranwendungen" andere Regeln.

Hat schon jemand den Libnodave Paket in reiner Windows- Anwendung benutzt ? Vielleicht ein Codestück?

Hoffe, dass mich jemand unter Arme greifen kann, habe Heute den ganzen Tag probiert, ohne Erfolg.

Grüße

Roman
 
Ich bin kein Fachmann für Windows-Programme. Daher ist das hier nur eine Vermutung: Die Testprogramme sind reines C. Schreibst du nun ein Programm in C++, so muß der Compiler wissen, daß nodave.h C und nicht C++ ist. Das sollten eingentlich die Zeilen:

ifdef __cplusplus
extern "C" {
endif

am Anfang von nodave.h leisten.

Du kannst probieren, in deinem Programm zu schreiben:

extern "C" {
#include "nodave.h"
}

Vor dem #include MUSST du definieren:
#define BCCWIN // bei Windows
#define LITTLE_ENDIAN // auf einem Intel-PC

Mehr fällt mir nicht ein.
 
probiere ich gleich.
Leider habe ich mein "Programmierleben" mit c++ unter Windows angefangen, ausser den Pascal (Pflichtfach an der Uni)
Wäre vielleicht einfacher erst mit c anzufangen, aber es kosten Zeeeeeeit :roll:
Deswegen kann nicht alle Fluten von Deklarationen der Form #define...usw. nachvollziehen.
Alle Bücher, die ich besitze geben zwar kurze Anleitung darüber, aber es reicht nicht.
hast du ein Buchtip?

Roman
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Roman_kr schrieb:
probiere ich gleich.
...hast du ein Buchtip?
Roman
Nein, habe ich nicht.
#define A
bewirkt, daß die
Abfrage
#ifdef A
positiv ausfällt, sonst negativ

zwischen
#ifdef A
und
#endif
steht Code, den der Compiler nur zusehen bekommt, wenn ein #define A da war. Sonst schmeißt der Präprozessor ihn weg.

die andere Art ist
#define abc 123
das bewirkt, daß der Präprozessor "abc" durch "123" ersetzt.

in nodave.h sind ein paar Dinge nur für Linux, andere nur für Windows.

deshalb stehen sie zwischen

#ifdef LINUX
Linux-spezifische Dinge
#endif

#ifdef BCCWIN
Windows-spezifische Dinge
#endif

ein paar andere Dinge sind für eine big-endian-Maschine (Motorola-Prozessoren, Apple) anders als für eine little-endian-Maschine (i386). Sie stehen daher zwischen

#ifdef LITTLE_ENDIAN
Umsortieren von Bytes, die S7 ist eine big-endian-Maschine.
#endif
 
Hurra, hat's geklappt :lol:
Mit deinen Tipps ging alles ohne Probleme. Wenn man die Define- Blöcke etwas analisiert, ist eigentlich einfach.
Jetzt kann ich das Ganze auf Windows umschreiben.
Kleines "Fenster" Programmschen, mit dem ich die Verbindung mit MPI und TCP testen kann, habe ich schon fertig.

Sollte jemand daran Interesse haben, die Testprogramme unter Windows zu probieren, dann bitte melden. Kann sie hochladen. Dauert halt noch ein Paar Tage.
Ich melde mich wieder

Nochmal Danke an Zottel!!
Roman
 
Die Testprogramme würden ich schon interessieren, vorrausgesetzt du gibst sie im Quelltext her und sie sind so einfach, daß man sie auf jedem Windows-System (keine besonderen Bibliotheken) und unter wine (damit ich sie bei Änderungen an Libnodave leicht pflegen kann). Dann könnte ich sie zu Libnodave als Beispiele hinzufügen, so daß nicht noch jemand fragen muß, ob man auch C++ und GUI-Anwendungen erstellen kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Testprogramme würden mich schon interessieren, vorrausgesetzt du gibst sie im Quelltext her und sie sind so einfach, daß man sie auf jedem Windows-System (keine besonderen Bibliotheken) und unter wine (damit ich sie bei Änderungen an Libnodave leicht pflegen kann). Dann könnte ich sie zu Libnodave als Beispiele hinzufügen, so daß nicht noch jemand fragen muß, ob man auch C++ und GUI-Anwendungen erstellen kann.
 
selbstverständlich werde ich den Quellcode mitgeben.
Damit keiner mehr die Probleme hat (so wie ich), deine Bibliothek unter Windows zu nutzen.
Ich habe daran gedacht, die DOS- Beispielprogramme in Windows 1:1 zu übersetzen, halt mit bischen Schaltflächen anstatt mit Aufrufoptionen.
Ausserdem mit der Möglichkeit, MPI und TCP im einem Programm zu testen.
Was den Codekomlexität angeht, du weiß doch, wie groß die Programme unter MFC sind.

Roman
 
Zurück
Oben