-
Notifications
You must be signed in to change notification settings - Fork 163
/
FAQ.de.txt
189 lines (172 loc) · 12.7 KB
/
FAQ.de.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
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 ?
A: 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 ?
A: 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 Verfuegung.
Q: Ich versuche, meinen Quellcode zu kompilieren, der nodave.h einbindet. Warum erhalte ich:
"#error Fill in what you need for your OS or API" ?
A: Libnodave mu unter verschiedenen Betriebssystemen verschiedene Funktionen nutzen,
um Daten byteweise von seriellen Schnittstellen oder TCP/IP streams zu lesen.
Diese Funktionen sind betriebssystemspezifisch. Du mut spezifizieren fr welches BS du
kompilierst. Definiere BCCWIN fuer Windows und LINUX fuer Linux oder andere Unix-artige
BS. Ich benutze -DBCCWIN oder -DLINUX beim Aufruf der Compiler aus einem Makefile. Wenn du
eine IDE (integrierte Entwicklungsumgebung) nutzt, entnimm der Dokumentation der IDE wie das
dort geht. Wenn du es nicht herausfinden kannst, kannst du dir auch helfen indem du die
#defines in deinen Quellcode schreibst (was bedeutet, dass dein Quellcode nicht mehr
ohne Aenderungen auf ein anderes System portiert werden kann). Beispiel:
...
#define BCCWIN // if you work on windows
#include nodave.h // or nodavesimple.h, but NEVER both
#include setport.h // if your code works with serial connections
#include openSocket.h // if your code works with TCP/IP
...
Q: Ich versuche, libnodave aus dem Quellcode zu kompilieren. Es gibt Probleme.
A: - Du brauchst Libnodave nicht selbst zu kompilieren. Du wrdest das mit anderen DLLs (Windows)
oderr .sos (gemeinsam genutzte Bibliotheken unter Linux) auch nicht machen. Normalerweise
linkt man solche Bibliotheken dynamisch zum eigenen Code.
- Nichtsdestotrotz steht dir der Quellcode zur Verfuegunge und du moechtes ihn oder nur die
benoetigten Teile rekompilieren usw..
- Du solltest wissen, dass die S7 die Motorola- (big endian, hchstwertiges byte zuerst)
Byteanordnung (endianness) verwendet, waehrend Intel-Prozessoren Intel-Byteanordnung
(little endian, niederwertigstes Byte zuerst). Auf Intel- und aehnlichen Maschinen
muss Libnodave Mehbyte-Werte umsortieren. Dies geschieht mittels der Funktionen daveGetS2(),
daveGetU2(), daveGetFloat() usw.. Der Code zur Konvertierung wird nur mitkompiliert
wenn du DAVE_LITTLE_ENDIAN definierst. Ansonsten wird "big endian" vorausgesetzt.
- Beachte, dass ich die publizierten Versionen von Libnodave mit gcc (fuer Linux) und MSVC++
(fuer windows) kompiliere. Dazu verwende ich das Skript buildall um Linux und Windows
Release-Versionen und Testprogramme auf einem Linux-Rechner zu erzeugen. Buildall benutzt
seinerseits das make von Linux mit MAKEFILE.VC.WINE um den MSVC++-Compiler fuer die
Windows-Versionen aufzurufen. Es gibt auch ein MAKEFILE.VC das auf einem Windows-System
mittels nmake dasselbe leisten sollte, aber es koennte nicht auf dem neuesten Stand sein :-(
Wenn du Zweifel hast, welche Compileroptionen oder Quelldateien noetig sind, schau in
MAKEFILE.VC.WINE nach!
Q: Ich moechte Libnodave fuer ein anderes Betriebssystem kompilieren. Welche Anpassungen
muss ich vornehmen?
A: - Ich nehme mal an, dass dein Betriebssystem ein 32-Bit-System ist und der zugehoerige
Compiler int als 32-Bit-Zahl behandelt. Wenn nicht, wird es schwierig!
- Du brauchst funktionsgleichen Ersatz fuer setport.c oder setportw.c und openSocket.c oder
openSocketw.c
- nodave.h: Du musst ein struct _daveOSserialType definieren, dass folgende Elemente beinhaltet:
rfd: Ein Datentyp, der eine serielle Schnittstelle oder ein TCP socket bei einem Lesezugriff
indentifiziert.
wfd: Ein Datentyp, der eine serielle Schnittstelle oder ein TCP socket bei einem Schreibzugriff
indentifiziert.
- nodave.c: Du musst die Funktionen stdread() und stdwrite() implementieren, die Bytes
von/an eine serielle Schnittstelle in/aus einem Puffer lesen/schreiben.
Q: Gibt es eine Funktion um die Struktur eines Datenbausteins zu lesen? Variablen und ihre
Datentypen ?
A: Nein. Die Strukturinformation steht nur in Step7 und nur vor der Compilierung verfuegbar.
Sie wird nicht in die SPS selbst uebertragen. Es ist dasselbe, wenn du ein neues Projekt
anlegst und den Programmcode aus der SPS laedtst: Von den Datenbausteinen bleiben nur
Byte-Arrays.
Q: Ich habe Probleme, auf Eingaenge zu schreiben. Koennen Sie mir hefen?
A: Zunaechst gibt es zwei Typen von "Eingaengen": 1. Periphere Adressen. Das ist das, was Sie
mit daveP ansprechen, oder, in einen SPS-Programm, mittels L PEW <adresse>. Zugriffe auf
diese Adressen sind echte Schreib- oder Lesezugriffe auf die Hardware und es gibt keine
Moeglichkeit, die Hardware von Eingaengen zu schreiben.
2. Prozessabbild der Ein- und Ausgaenge. Das ist was Programmierer von Siemens-SPS
normalerweise als Ein- und Ausgaenge ansprechen, wie bei:
L EW <Adresse>
or
U E 2.5
Zugriffe auf diese Adressen sprechen NICHT die Hardware sondern einen speziellen Speicherbereich
an. Der Zustand der Eingaenge wird in jedem Zyklus in diesen Speicherbereich kopiert, bevor
das Anwenderprogramm ausgefhrt wird. Wenn Sie mittels daveInputs dorthin schreiben, werden die
Werte vor dem naechsten Zyklus ueberschrieben.
Ob Ihr SPS-Programm oder Ihre Libnodave-Anwendung die geschriebenen Werte "sehen" wird, ist
ein zeitlicher Wettlauf.
Q: Ist es moeglich, mehrere (bis zu 3) Bits gleichzeitig in die SPS zu schreiben?
Ich moechte "Read-modify-write"-Techniken vermeiden und das Schreiben so "atomar" wie moeglich
halten.
A: daveWriteBits() stellt eine "atomare" Schreibfunktion bereit, aber nur fr ein einzelnes Bit.
Der Parameter "length" bei daveWriteBits() muss 1 sein, andere Werte liefern Fehler bei den
CPUs die ich kenne. Warum also ist der Parameter vorhanden? Es gibt ein entsprechendes Feld
in der Nachricht, das in anderen Faellen die Zahl der Bits angibt.
Q: Kann das ("atomares" Schreiben auf 3 Bits) mit daveWriteBits() erreicht werden oder muss
ich mehrere Variablen mit einer PDU schreiben?
A: Es kann NICHT mit daveWriteBits() erreicht werden, jedenfalls mit den CPUs die ich kenne. Ob
das I know. Whether Schreiben mehrerer Variablen mit einer PDU atomar ist, weiss ich nicht.
Wenn Sie das SPS-Programm verndern koennen, denke ich das Beste waere, die 3 Bits in ein Byte
zu packen, dessen andere Bits nicht gebraucht werden.