# Libnodave Version 0.8



## Zottel (14 Oktober 2005)

Soeben habe ich Libnodave 0.8 veröffentlicht.

- Libnodave kann jetzt auf Win32-Systemen, auf denen Siemens-Software und Treiber installiert sind, diese für den Transport verwenden. Dadurch werden CPs (5511, 5512 sind getestet) sowie USB-MPI-Adapter nutzbar.
- Für Linux ist ein Kernel-Modul für den USB-MPI-Adapter enthalten (Kernel 2.6.13). Für andere Kenel mag eine zweite Lösung funktionieren, die den Adaptern aus dem User-Space mittels libUSB anspricht.
- Zur Datenübertragung zwischen COM-Port und MPI-Adapter wird nun ausser R3964R auch das Protokoll unterstützt, das Step7 mit neueren Adaptern verwendet.
Diese Dinge sind noch im Alpha-Stadium, daher vielleicht weniger stabil als der Rest der Bibliothek :-(

- Es sollten mehr MPI-Adapter verwendbar sein, darunter einer (der?) von Helmholz.
- "lange" Datenblöcke können nun in einem Stück an die Funktionen daveReadManyBytes und daveWriteManyBytes übergeben werden, die sie automatisch auf mehrere PDUs aufteilt.
- Die Anbindung an Pascal/Delphi sollte wieder auf dem neuesten Stand sein.


----------



## Maxl (15 Oktober 2005)

Ist Libnodave eigentlich kompatibel zu Prodave?


----------



## Zottel (15 Oktober 2005)

Maxl schrieb:
			
		

> Ist Libnodave eigentlich kompatibel zu Prodave?


Nein, aber das ist kein Nachteil: Ich halte das API von Libnodave für einfacher und logischer aufgebaut. Wer will, kann sich eine W95_s7.dll (oder so ähnlich) selbst erstellen und die Funktionen von Prodave mit solchen von Libnodave nachbilden. Dabei würdest du feststellen, daß viele Funktionen von Prodave auf dieselbe Funktion in Libnodave abgebildet werde; lediglich Aufrufparameter ändern sich.


----------



## seeba (15 Oktober 2005)

Danke! 

Habe 0.7.2 schon in SCADA.NET eingebunden... Funktioniert die 0.8 noch genauso oder muss irgendetwas beachtet werden?

Gruß Sebastian


----------



## Zottel (15 Oktober 2005)

seeba schrieb:
			
		

> Danke!
> 
> Habe 0.7.2 schon in SCADA.NET eingebunden... Funktioniert die 0.8 noch genauso oder muss irgendetwas beachtet werden?
> 
> Gruß Sebastian


Warum 0.7.2 und nicht 0.7.4?
Du arbeitest mit VB Dot.Net, ja?
Ich denke, es sollte keine Inkopatibilitäten, nur mehr Möglichkeiten geben.
Probieren geht über Studieren!


----------



## seeba (15 Oktober 2005)

Zottel schrieb:
			
		

> seeba schrieb:
> 
> 
> 
> ...



Ich meinte doch 0.7.4! Ist zu spät für mich! Okay, ich werde es morgen mal probieren. C# und VB.NET, ja!


----------



## Ralle (17 Oktober 2005)

Hi Zottel,

die testS7online.exe unter WinXP funktioniert super.
Gehe ich recht in der Annahme, daß die Delphi-Demo noch nicht damit läuft, oder muß man im Verbindungseditor irgenwelche Angaben machen?


----------



## Mazur_OP (17 Oktober 2005)

*Windows DLL*

Hallo,

Ich benütze VB.Net für einfache Visualisierungsaufgaben mit einer S7.
Kann ich dazu Libnodave benutzen? Und wie muss ich vorgehen das ich die Dll erstellen kann.
Bis jetzt habe ich Prodave oder die dll von IBH (IBH-Netlink) genutzt.

mfg

OP


----------



## Ralle (17 Oktober 2005)

Lade dir Libnodave-0.8 vom Server. Darin ist u.a. ein Unterverzeichnis Dot.Net mit allem was du benötigst.


----------



## Zottel (17 Oktober 2005)

Ralle schrieb:
			
		

> Gehe ich recht in der Annahme, daß die Delphi-Demo noch nicht damit läuft, oder muß man im Verbindungseditor irgenwelche Angaben machen?


Weiß ich leider nicht, da die Delphi-Komponente nicht von mir ist. Ich muß nachfragen Du kannst ja mal im Verbindungseditor rumprobieren.


----------



## Zottel (17 Oktober 2005)

*Re: Windows DLL*



			
				Mazur_OP schrieb:
			
		

> Und wie muss ich vorgehen das ich die Dll erstellen kann.


Für Dot.net sind zwei dlls nötig und liegen auch fertig bei:
libnodave.dll beinhaltet die Funktionalität
libnodave.net.dll greift auf libnodave.dll zu und packt die Funktionen in Dot.net-konformer Weise in Objekte.


----------



## Maxl (17 Oktober 2005)

Zottel schrieb:
			
		

> Maxl schrieb:
> 
> 
> 
> ...



Klingt interessant! Werde mich mal damit auseinandersetzen....


----------



## Zottel (17 Oktober 2005)

Ralle schrieb:
			
		

> Hi Zottel,
> 
> die testS7online.exe unter WinXP funktioniert super.
> Gehe ich recht in der Annahme, daß die Delphi-Demo noch nicht damit läuft, oder muß man im Verbindungseditor irgenwelche Angaben machen?


Habe gerade selber gespielt:
1. im Verbindungseditor gibst du den Namen des Zugriffspunktes anstelle des COM-Ports an, z.B. S7online.
2. Ich habe hier eine CPU am Profibus mit CP5511. Sie hat Adresse 5. Der  Verbindungseditor erlaubt mir aber nicht mehr, eine remote-MPI-Adresse einzustellen, nachdem ic S7online.dll als Protokoll gewählt habe. So gings aber:
- Protokoll auf "MPI" gestellt.
- MPI Remote auf 5 gestellt
- Protokoll auf S7online gestellt.


----------



## Ralle (18 Oktober 2005)

@Zottel
Funktioniert bei mir leider nicht, es kommen diverse Fehlermeldungen und offensichtlich bei "Start" einmalig zufällige Werte an. Aber das werde ich mal mit Delphi selbst debuggen. Außerdem läßt sich die Demo nun auf keine Weise mehr beenden. Windows meldet das das Programm "SchmidWatch" beendet werden soll. Werde mir die Demo wohl doch mal genauer vin innen ansehen.


----------



## Ralle (18 Oktober 2005)

Bei eine s7Online-Verbindung mit CP5511 über die Delphi-Demo:
Das erste Connect schlägt fehl (OpenS7Online kommt mit 0 zurück), das zweite Connect funktioniert (OpenS7Online kommt mit 1 zurück) und liefert Daten. Das Disconnect bringt eine externe Exception bei ClosePort (C0000008). Danach gelingt kein neuerliches Connect, Fehlernummer -128.

20 Min später:
Nun geht auch ein 2. und 3. Connect (nix geändert), aber die Exception bei ClosePort bleibt. ???


----------



## Zottel (18 Oktober 2005)

Ralle schrieb:
			
		

> Bei eine s7Online-Verbindung mit CP5511 über die Delphi-Demo:
> Das erste Connect schlägt fehl (OpenS7Online kommt mit 0 zurück), das zweite Connect funktioniert (OpenS7Online kommt mit 1 zurück) und liefert Daten. Das Disconnect bringt eine externe Exception bei ClosePort (C0000008). Danach gelingt kein neuerliches Connect, Fehlernummer -128.
> 
> 20 Min später:
> Nun geht auch ein 2. und 3. Connect (nix geändert), aber die Exception bei ClosePort bleibt. ???


Zunächst ist bei s7onlune 0 ein gültiger Wert für das handle. Wenn die Komponente das noch nicht weiß, ist es ihr Fehler. Beim zweiten mal ist 0 dann noch belegt und die s7onlinnx.dll gibt 1 zurück.
Zweitens sind das keine file handles oder sockets, daher kann man sie auch nich mit colePort schließen, sondern nur mit daveSCP_close.


----------



## Ralle (18 Oktober 2005)

Zottel schrieb:


> Zweitens sind das keine file handles oder sockets, daher kann man sie auch nich mit colePort schließen, sondern nur mit daveSCP_close



Die DLL exportiert kein daveSCP_close, hab ich was übersehen?

Das eigenartige ist, mal geht es komplett (Connect, Disconnect, mehrmals hintereinander), mal geht es teilweise, mal gar nicht. Dazwischen nehme ich keine Änderungen vor, evtl läuft mal ein anderes Programm dazwischen unter Windows.


----------



## Zottel (18 Oktober 2005)

Ralle schrieb:
			
		

> Zottel schrieb:
> 
> 
> > Zweitens sind das keine file handles oder sockets, daher kann man sie auch nich mit closePort schließen, sondern nur mit daveSCP_close
> ...


Nein, ich habe es eben falsch geschrieben:
Das SCP_close erfolgt intern, wenn disconnectAdapter aufgerufen wird. Danach ist das handle ungültig. closePort darf man auch nicht damit aufrufen. 


> Das eigenartige ist, mal geht es komplett (Connect, Disconnect, mehrmals hintereinander), mal geht es teilweise, mal gar nicht. Dazwischen nehme ich keine Änderungen vor, evtl läuft mal ein anderes Programm dazwischen unter Windows.


Sorry, ich kann nicht viel zu der Delphi-Komponente sagen. Wer Delphi hat und kennt, kann wohl selbst Hand anlegen, z.B. das 0 eben ein gültiger Wert für das Handle ist.
Weitehin solltest du Sachen, die die Komponente betreffen, vielleicht besser in der mailing list auf der Sourceforge-Projektseite posten, da liest auch der Author der Komponente mit.

Ansonsten interessiert mich erstmal ob es ein Fehler von libnodave ist.
Das findest du raus, wenn du es mit den fertigen Testprogrammen, in diesem Fall testS7Online, versuchst.


----------



## Ralle (18 Oktober 2005)

Danke Zottel, ich werd mal nach der mailing list auf der Projekt-Seite umsehen. 

daveDisconnectAdapter ist drin in der Disconnect-Routine:


```
daveDisconnectAdapter(DaveIntf);
      daveFree(DaveIntf);
      closePort(DaveFDS.rfd);
```

Das werd ich mal in der mailing list anfragen.
Was mich noch stört, bei großen Datenmengen reagiert die Anwendung nicht mehr flüssig, obwohl das Read in einem extra Thread erfolgt, aber das ist wohl auch eher was für die mailing list.


----------



## Ralle (18 Oktober 2005)

@Zottel

Meinst du die libnodave-Projektseite, oder gibt es eine extra Seite?

Edit:
Alles Klar, hab mich erstmal zur libnodave-Seite dazugesellt  :wink: .


----------



## seeba (19 Oktober 2005)

Hallo Zottel,
wie les ich denn am gescheidsten Wörter und Doppelwörter bzw. wie kann man die am einfachsten aus zwei/vier Bytes errechnen?

Danke und Gruß Sebastian

Edit: *Habe es schon... geht ja ganz einfach. So in etwa müsste das sein: (byte1)*2^8 + (byte0)*2^0 = word*


----------



## Zottel (19 Oktober 2005)

seeba schrieb:
			
		

> Hallo Zottel,
> wie les ich denn am gescheidsten Wörter und Doppelwörter bzw. wie kann man die am einfachsten aus zwei/vier Bytes errechnen?
> 
> Danke und Gruß Sebastian
> ...


Wozu stellst du solche Rechnungen an? Die sind alle schon drin:
daveGetU16, daveGetS16, daveGetU32, daveGetS32, daveGetFloat.
Gibt's da irgendwo ein fundamentales Mißverständnis?


----------



## seeba (19 Oktober 2005)

Zottel schrieb:
			
		

> seeba schrieb:
> 
> 
> 
> ...



Ja, denn wo übergeb ich den Funktionen die Bytes bzw. was sie umrechnen sollen?


----------



## Zottel (19 Oktober 2005)

seeba schrieb:
			
		

> Ja, denn wo übergeb ich den Funktionen die Bytes bzw. was sie umrechnen sollen?


Gar nicht. 
Nehmen wir an du hast einen DB der so aus sieht:
a WORD ein Wort
b BYTE ein Byte
c REAL ein real, fängt extra auf DBB3 an, damits schwerer aussieht
d WORD ein Wort
e DWORD ein Doppel-Wort
f Integer ein Wort mit Vorzeichen
g WORD ein Wort

Du liest den ganzen Kram ein:
daveReadBytes(dc, daveDB, DBnummer, 0, 17, NULL);
jetzt stehen 17 Bytes im internen Puffer der daveConnection.
a=daveGetU16(dc);
b=daveGetU8(dc);
c=daveGetFloat(dc);
d=daveGetU16(dc);
e=daveGetU32(dc);
f=daveGetS16(dc);
g=daveGetU16(dc);

Es gibt die ganzen Dinger auch noch als daveGetFrom... Da kannst du einen eigenen Puffer und eine Position angeben.


----------



## ronnie.b (19 Oktober 2005)

*RE*

Tach Zottel!
Muss ich für die Libnodave.dll Step7 installieren damit es mit s7online funktioniert??
Oder geht das auch wenn ich nur z.B. den Treiber für den Adapter installiere??(Wird da die s7onlinx.dll mit installiert?)

Gruß Ronnie


----------



## seeba (19 Oktober 2005)

*Re: RE*



			
				ronnie.b schrieb:
			
		

> Tach Zottel!
> Muss ich für die Libnodave.dll Step7 installieren damit es mit s7online funktioniert??
> Oder geht das auch wenn ich nur z.B. den Treiber für den Adapter installiere??(Wird da die s7onlinx.dll mit installiert?)
> 
> Gruß Ronnie



Wenn du die S7online Funktion nutzen willst, reicht es wenn du z.B. SIMATIC NET installierst. Das brauchst du dann auch nicht authorisieren!


----------



## Ralle (20 Oktober 2005)

Irgendwas ist faul.

Kann es sein, daß daveReadBytes irgenwas ruiniert?

Wenn man mehrmals disconnectet und wieder connectet (ist mit der Delphi-Demo mit großen Blöcken gut nachvollziebar) bleibt das Ganze irgendwann beim Connect oder Disconnect stehen, oder bringt eine Schutzrechtsverletzung (Häufig Zugriffsverletzung bei Adresse 10008AAA in Modul Libnodave.dll, wenn das Problem beim connect auftritt). Wenn man keine Daten mit daveReadBytes liest, dann kann man beliebig oft connect und disconnect ausführen. Ich kann leider nicht sagen, ob das nur bei der s7Onlinx.dll so ist, da ich im Moment keinen anderen Adapter als den CP5511 zur Verfügung hab. Kann es evtl. sein, das daveFree irgenwelche Leichen zurückläßt, die mit dem Buffer zu tun haben?

Beim Disconnect passiert folgendes:


```
FLastError := daveDisconnectPLC(DaveConn);
      daveFree(DaveConn);
      FLastError := daveDisconnectAdapter(DaveIntf);
      daveFree(DaveIntf);
```


----------



## Zottel (20 Oktober 2005)

Ralle schrieb:
			
		

> Irgendwas ist faul.
> 
> Kann es sein, daß daveReadBytes irgenwas ruiniert?
> 
> Wenn man mehrmals disconnectet und wieder connectet (ist mit der Delphi-Demo mit großen Blöcken gut nachvollziebar) bleibt das Ganze irgendwann beim Connect oder Disconnect stehen, oder bringt eine Schutzrechtsverletzung (Häufig Zugriffsverletzung bei Adresse 10008AAA in Modul Libnodave.dll, wenn das Problem beim connect auftritt). Wenn man keine Daten mit daveReadBytes liest, dann kann man beliebig oft connect und disconnect ausführen. Ich kann leider nicht sagen, ob das nur bei der s7Onlinx.dll so ist, da ich im Moment keinen anderen Adapter als den CP5511 zur Verfügung hab. Kann es evtl. sein, das daveFree irgenwelche Leichen zurückläßt, die mit dem Buffer zu tun haben?



Kann ich nicht sagen, aber eher unwahrscheinlich. Ich habe geschrieben, daß s7online als Protkoll ALPHA ist. 
Solange nicht eindeutig überprüft wird, ob ein von der s7onlinx.dll an daveGetResponseS7online zurückgegebener Puffer wirklich Daten von der SPS enthält, kann alles mögliche passieren, dessen Details mich ehrlich gesagt nicht interessieren.

Meine Anwendungen verbinden sich eigentlich nur einmal mit der CPU. Wenn du das auch so machst, kannst du s7online als Protkoll verwenden, wenn du aber einen Grund hast, warum du disconnect() und connect() mehrfach aufrufen mußt, warte bitte auf die nächste Version.


----------



## Ralle (20 Oktober 2005)

Ja, Daten kommen an. Es ist eine Anwendung, in der man die Kommunikation starten und stoppen kann. Wenn der Nutzer das mehrmals hintereinader tut (warum auch immer), sollte die Applikation nicht einfrieren bzw. abstürzen. Ich habe den Eindruck gewonnen, daß es an der DLL liegt, da ich das Problem sowohl bei der Demo, als auch bei meiner Umsetzung "zu Fuß" habe. Das der Code Alpha ist ist ja klar, irgendwas passiert wohl beim Disconnect, leider habe ich keinen C-Compiler und bin in C auch nicht so ganz sattelfest, da trau ich mir nicht zu in der DLL rumzudebuggen und das Problem zu finden.


----------



## Zottel (20 Oktober 2005)

Ralle schrieb:
			
		

> Ja, Daten kommen an. Es ist eine Anwendung, in der man die Kommunikation starten und stoppen kann.


Wozu? bzw. wenn du nicht kommunizierst, laß doch die Verbindung offen.


> ... irgendwas passiert wohl beim Disconnect, leider habe ich


disconnectPLC tut gar nichts.
disconnectAdapter schließt das handle der Verbindung zur s7onlinx.dll.
Das ist eigentlich was sonst closePort macht.
Daher kannst du nach disconnectAdapter gar nichts mehr tun, ohne mit openS7online ein neues handle zu holen. Das ist unschön und anders als bei allen anderen Protokollen, aber ich habe noch keine gute Lösung dafür.

Da disconnectPLC nichts tut, wird connectPLC möglicherweise die CPU-inetenen Verbindungen nacheinander belegen, bis nichts mehr geht. Kannst du dir parallel in Step7 angucken.


----------



## Ralle (20 Oktober 2005)

Mußte nochmal anfangen mit schreiben, beim Testen hat es mit das XP zerhauen   .

Also, wenn Step7 online ist, bricht beim Connect über libnodave und s7onlinx.dll die Verbindung von Step7 ab, libnodave meldet wechselnd -124 und -128. Wenn ich zuerst die Verbindung mit libnodave aufbaue, kann ich anschließend mit Step7 online gehen, darf aber libnodave nicht stoppen, da es dann nicht nocheinmal zu einer Verbindung bewegt werden kann (-124, -128). Klar kann ich die Verbindung offen lassen, aber sie muß auch ordentlich abgebaut werden können. Wenn jemand ausversehen das Kabel abzieht und dann wieder ansteckt nehme ich normalerweise (prodave) die Verbindung wieder auf und weiter geht es. 
Ich werde mal weitertesten, was passiert, wenn ich grundsätzlich einmal die Verbindung aufbaue und dann stehen lasse.

Test: Ja, nachdem man die Verbindung gestört hat muß man dann das Programm schließen, hmm.


----------



## Zottel (20 Oktober 2005)

Ralle schrieb:
			
		

> Mußte nochmal anfangen mit schreiben, beim Testen hat es mit das XP zerhauen   .


Und ich dachte schon, Windows wäre inzwischen soweit, daß eine Amok laufende Anwendung nicht mehr das System zerschießt.


> Also, wenn Step7 online ist, bricht beim Connect über libnodave und s7onlinx.dll die Verbindung von Step7 ab...


Sehe ich mir heute abend an.


> Test: Ja, nachdem man die Verbindung gestört hat muß man dann das Programm schließen, hmm.


Abgesehn davon, das Libnodave wahrscheinlich noch nicht  jeden Fehler korrekt erkennt:
Wenn daveReadBytes einen Fehler meldet, der mit der Verbindung zu tun hat (und nicht damit, daß es einen DB nicht gibt oder er nicht genug Daten enthält), solltest du in folgender Reihenfolge die Verbindung abbauen und eine ganz neue aufbauen können:

```
daveDisconnectPLC(dc) // auch wenn's noch nichts tut
daveFree(dc)  
// wenn es jetzt oder als Folge dieses Aufrufs von daveFree einen Zugriffsfehler gibt, dann
// müßte es so sein, daß ein Zeiger auf den Pufferspeicher in daveConnection an s7onlinx.dll
// übergeben wurde und s7onlinx.dll ihn noch für gültig hält.
daveDisconnectAdapter
daveFree(di) ;
fds.rfd=openS7online("name"),
fds.wfd=fds.rfd;
di=daveNewInterface(fds...);
daveInitAdapter(di);
dc=daveNewConnection(di)
daveConnectPLC(dc);
```
Wenn das nicht geht wegen dem vermuteten Problem, daß die s7Onlinx noch im Besitz eines Puffers ist, könnte es so gehen:

```
daveDisconnectPLC(dc) // auch wenn's noch nichts tut
daveDisconnectAdapter
daveFree(dc)  
daveFree(di) ;
fds.rfd=openS7online("name"),
fds.wfd=fds.rfd;
di=daveNewInterface(fds...);
daveInitAdapter(di);
dc=daveNewConnection(di)
daveConnectPLC(dc);
```
Geht auch das nicht, laß einfach daveFree() weg und guck was passiert. Ich weiß, das macht Löcher in den Speicher, aber es sind jedesmal nur 2-3 kByte, das kann ein heutiger PC längere Zeit verkraften. Und wenn du die Anwendung beendest, holt sich Windows den Speicher schon wieder.
[/code]


----------



## Ralle (20 Oktober 2005)

Danke Zottel, das werde ich mal testen.
Im Moment mache ich es nach deinem 1. Tip, wenn die Verbindung einmal aufgebaut ist, lasse ich sie stehen. Wenn DaveReadBytes einen Fehler bringt (Kabel ab) , bau ich die Verbindung komplett ab und später wieder auf. Nach einem Fehler kann ich eigenartiger Weise die Verbindung immer (15 mal probiert) aufbauen, ohne daß die Anwendung abschmiert. So geht es immerhin ersteinmal, vielleicht findest du mit den Hinweisen auch noch etwas.
Erstmal super, daß es überhaut geht, daß kann man nicht von vielen Alphas (ich meine den s7Onlinx.dll Zugriff) sagen  :lol: .


----------



## Ralle (21 Oktober 2005)

@Zottel

Die Funktion ReadBytes bringt mir bei daveProtoS7Online immer die Daten der ersten angelegten DaveConn (mit daveNewConnection) zurück, egal ob ich eine zweite erzeugt habe und von dieser auch die Daten lesen will.
Die beiden Rückgabewerte von daveNewConnection sind jeweils unterschiedlich und es gab keine Fehlermeldung.


----------



## seeba (21 Oktober 2005)

@ Zottel: mal kurz zu Bits... wie kann ich da nun 1 oder 0 auslesen? Array und dann aussuchen?


----------



## Zottel (21 Oktober 2005)

seeba schrieb:
			
		

> @ Zottel: mal kurz zu Bits... wie kann ich da nun 1 oder 0 auslesen? Array und dann aussuchen?


Aus dem Ergebnis von daveReadBytes:
b=daveGetU8(dc) //holt ein Byte
if (b & 128) bit7=1; else bit7=0;

Aus dem Ergebnis von daveReadBits:
b=daveGetU8(dc) //holt ein Byte
if (b =0)  bitx=1; else bitx=0;
bitx ist halt das, dessen Adresse du gelesen hast. 
Und um es nochmal deutlich zu sagen: Die S7 liefert bei readBits ein Byte zurück. Wenn es nicht 0 ist, ist das Bit 1.
Beispiele sind testMPI.c, vielleicht auch in testMPI.cs.


----------



## seeba (21 Oktober 2005)

```
Imports System
Imports System.Threading

Class test
	Shared fds As libnodave.daveOSserialType
	Shared di As libnodave.daveInterface
	Shared dc As libnodave.daveConnection
	Shared rack As Integer = 0
	Shared slot As Integer = 2

	Public Shared Function Main(ByVal args As String()) As Integer
		Dim i As Integer
		Dim a As Integer = 0
		Dim j As Integer
		Dim res As Integer
		Dim b As Integer = 0
		Dim c As Integer = 0
		Dim d As Single = 0
		fds.rfd = libnodave.openSocket(102, "192.168.0.241")
		fds.wfd = fds.rfd
		If fds.rfd > 0 Then
			di = New libnodave.daveInterface(fds, "IF1", 0, libnodave.daveProtoISOTCP, libnodave.daveSpeed187k)
			di.setTimeout(1000000)
			dc = New libnodave.daveConnection(di, 0, rack, slot)
			Do
				If 0 = dc.connectPLC Then
					res = dc.readBytes(libnodave.daveDB, 50, 0, 10, Nothing)
					If res = 0 Then
						a = dc.getS32
						b = dc.getS32
						c = dc.getS32
						d = dc.getFloat
						Console.WriteLine("FD0: " + a.ToString)
						Console.WriteLine("FD4: " + b.ToString)
						Console.WriteLine("FD8: " + c.ToString)
						Console.WriteLine("FD12: " + d.ToString)
					Else
						Console.WriteLine("error " + res.ToString + " " + libnodave.daveStrerror(res))
					End If
				End If
				Thread.Sleep(100)
			Loop Until 1 < 0
			dc.disconnectPLC
			libnodave.closePort(fds.rfd)
		Else
			Console.WriteLine("Couldn't open TCP connaction to PLC")
			Return -1
		End If
		Return 0
	End Function
End Class
```

Jetzt versuch ich mal die Werte dauernd zu aktualisieren... Sprich Endlos-Schleife! Einmal geht's und das zweite Mal geht's nicht mehr!


----------



## Zottel (21 Oktober 2005)

```
If 0 = dc.connectPLC Then
   Do
    res = dc.readBytes(libnodave.daveDB, 50, 0, 10, Nothing)
...
    Thread.Sleep(100)
   Loop Until 1 < 0
   dc.disconnectPLC
```

Jedes connectPLC belegt eine Verbindung ind der CPU!
Liest keiner die Beispielprogramme?
Die benchmarks (testXXX -b lesen) auch wiederholt in Schleifen!


----------



## seeba (21 Oktober 2005)

Zottel schrieb:
			
		

> ```
> If 0 = dc.connectPLC Then
> Do
> res = dc.readBytes(libnodave.daveDB, 50, 0, 10, Nothing)
> ...



Zottel, das Problem ist einfach, dass jeder die Beispielprogramme liest, welche er versteht! Das ist bei mir VB.NET und etwas C#! Du solltest nicht erwarten, dass jeder alle Beispiele lesen will und kann!


----------



## Zottel (21 Oktober 2005)

seeba schrieb:
			
		

> Zottel, das Problem ist einfach, dass jeder die Beispielprogramme liest, welche er versteht! Das ist bei mir VB.NET und etwas C#! Du solltest nicht erwarten, dass jeder alle Beispiele lesen will und kann!


Nein, da hast du wohl recht, aber ich habe auch schon eine Menge Bibliotheken und Sachen von anderen Leuten benutzt und meiner Meinung nach war und ist das meiste davon zwar vielleicht von mehr Dokumentation begleitet, aber im Programmtext weitaus schlechter kommentiert.
Wenn ich mehr Dokumentation schreibe, bekomme ich das Problem, die Dokumentation auf dem Stand des Programmcodes zu halten. Doppelte Arbeit :-(

Trotzdem sind mit jedem release neue Readmes und FAQs dabei.

Das Programm testMPI.cs in Dot.Net/CS enthält die Benchmarks auch. Daß sie nun ausgerechnet im VB.net-Beispiel nicht drin sind, liegt daran daß der VB-Compiler von MONO (freier Dot.Net-Nachbau) noch ziemlich unfertig ist und mit längeren Programmen gar nicht klar kommt. Und ich will keine Programme verteilen, die ich selbst nicht ausprobieren kann.

Was mich ein bißchen nervt, ist daß kaum etwas zurückkomt, was die Entwicklung von Libnodave voranbringt (es gibt einige wenige rühmliche Ausnahmen).
Andererseits erhalte ich häufig Anfragen (ich meine jetzt nicht deine), wo ich denke, ich muß das ABC des Programmierens erklären. Jemand auf dem Level vieler Fragesteller käme sicher auch mit keinem kommerziellen Produkt zurecht. 
Dann geht mir durch den Kopf, daß so einer sowas wohl auch nicht kaufen würde, weil ihm das durchaus klar ist. Aber weil Libnodave nichts kostet, lädt es Hans und Franz zum Probieren runter und fragt dann, wie sein Compiler funktioniert oder so was.


----------



## seeba (21 Oktober 2005)

Zottel schrieb:
			
		

> seeba schrieb:
> 
> 
> 
> ...



Ich denke auf diesem Level befinde ich mich nicht mehr.  :lol: Aber du hast schon recht. Ich geb dir gerne ein Feedback, sobald ich alle Funktionen ausnutze. Deine C# Beispiele kannst du in #Develop einfach nach VB.NET konvertieren. Hab es gerade mal mit dem testMPI gemacht und es funktioniert ohne Nacharbeiten. Was mir noch fehlt (ich kann's leider echt nicht finden), wäre Start/Stop auslesen (nicht schalten). hast du dafür eine Funktion vorgesehen?

Gruß Sebastian


----------



## Zottel (21 Oktober 2005)

seeba schrieb:
			
		

> Deine C# Beispiele kannst du in #Develop


Ich habe kein #Develop. Ich möchte mit auch nicht 20 verschiedenene IDEs runterladen, um dann von Nutzern zu hören, das wieder 10 von Ihnen nicht mehr up to date sind.
Ich will auch nicht diese 20 IDEs lernen oder sie auch nur anschmeißen, bevor ich ein neues release rausgebe,nur um zu sehen, ob noch alles geht. Ich muß noch einen Standard-SPS-Inhalt haben und ein paar Skripte, die Anpassungen für PERL automatisieren, dann kann ich das Script buildall so ausbauen, daß es  alle verteilten Programme baut und TESTET.
Darum sind lauter einfache Batch-files dabei. Die sollten auch in 10 Jahren noch funktionieren bzw. sollte jeder die Anpassungen vornehmen können.


			
				seeba schrieb:
			
		

> ...einfach nach VB.NET konvertieren. Hab es gerade mal mit dem testMPI gemacht und es funktioniert ohne Nacharbeiten.


Wunderbar. Jetzt könnte ich sagen, gib mir das Ergebnis, ich veröffentliche es für andere VB.Net user. Aber dann kann ich es nicht selbst anpassen oder erweitern:-(. Aber ich werde es in ein nächstes README schreiben, daß das geht.


			
				seeba schrieb:
			
		

> Was mir noch fehlt (ich kann's leider echt nicht finden), wäre Start/Stop auslesen (nicht schalten). hast du dafür eine Funktion vorgesehen?


Ja, daveReadSZL für die 300/400. Liest die System-Zustandslisten. Welche was enthält, kannst du der Siemens-Doku entnehmen. Soweit ich's im Kopf habe, hat SZL 25 (hex19) den Zustand aller LEDs.
Bei der 200 steht es irgendwo in den Systemdaten.


----------



## seeba (23 Oktober 2005)

Das mit den Bits bring ich leider immernoch nicht zum laufen. Könntest du mir nochmal sagen, wo es ein Beispiel gibt? Oder ein kurzes schreiben, wie z.B. DB50 DBX0.0 - 0.7 gelesen werden können? Wäre dir sehr dankbar.

Gruß Sebastian


----------



## seeba (23 Oktober 2005)

Zottel, hat sich erledigt man sollte vllt. irgendwo vermerken, dass man bei readBits die Addresse so übergeben muss (was ich nicht wusste): *( Byte * 8 ) + Bit*

Gruß Sebastian


----------



## Zottel (23 Oktober 2005)

seeba schrieb:
			
		

> Zottel, hat sich erledigt man sollte vllt. irgendwo vermerken, dass man bei readBits die Addresse so übergeben muss (was ich nicht wusste): *( Byte * 8 ) + Bit*
> Gruß Sebastian


Ich denkes, es steht irgendwo. Wo weiß ich gerade nicht. Die Testprogramme enthalten auch Beispiele (ob in C# , müßte ich nachschauen).
Etwas anderes ist wichtiger:
daveReadBits liest immer nur ein einziges Bit. Dafür sendet es eine ganze PDU mit allem Overhead und Wartezeit. Es ist eine extrem schlechte Wahl für eine SCADA-Anwendung. daveWriteBits hätte ncoh eine gewisse Daseinsberechtigung, da es die einzige Möglichkeit bietet ein Bit zu verändern ohne andere Bits im gleichen Byte zu beeinflussen.
Eine gute SCADA-Anwendung müßte die Anzahl der PDUs minimieren, um möglichst hohe Datenraten zu erreichen. Dazu müßte sie die gesamte Variablen- (Tag-) Liste zunächst mal durchgehen. Nehmen wir mal an, wir haben:
MW0
MD200
Dann liest man am besten alle 204 Byte ab MW0 und sucht die gewünschten Ergebnisse aus dem Puffer.

MW0
MD20
DB1.DBW4
Man kombiniert am besten das Lesen der 24 Byte ab MW0 und das Lesen von DB1
in einem readRequest für mehrere Variablen.

MW0
MD200
DB1.DBW4
Ob das noch mit einem readRequest zu erledigen ist, weiß ich nicht. Probieren oder ausrechnen.


----------



## seeba (23 Oktober 2005)

Zottel schrieb:
			
		

> seeba schrieb:
> 
> 
> 
> ...



So hier mein Feedback: Ich habe MPI, ISO und S7online deiner lib integriert und es hat alles sehr gut geklappt. Insgesamt sehr logisch aufgebaut und mit wenigen Änderungen auf die jeweils anderen Protokolle anpassbar!   Die Idee mit dem Bündeln hatte ich auch schon durchdacht, allerdings werde ich mich damit erst beschäftigen, wenn ein gewisses Interesse daran besteht, denn es ist schon ein sehr großer Aufwand. Für Ethernet ist es so schnell genug und bei MPI halt etwas langsamer. Außer meine Kleinigkeiten (vllt. auch überlesen usw.) die ich noch von dir wissen wollte habe ich alles sehr schnell verstanden und aus dem Quellcode und den Kommentarzeilen lesen können. Vielen Dank!

Was natürlich noch sehr toll wäre: Wenn man alle "Items" zu einer Liste hinzufügen kann und diese dann in einem Paket ausgeführt wird ohne diese vielen PDUs.

Gruß Sebastian


----------



## Zottel (23 Oktober 2005)

seeba schrieb:
			
		

> Was natürlich noch sehr toll wäre: Wenn man alle "Items" zu einer Liste hinzufügen kann und diese dann in einem Paket ausgeführt wird ohne diese vielen PDUs.
> 
> Gruß Sebastian



in C#:

libnodave.PDU p=davePrepareReadrequest();
p.addVarToReadRequest(daveFlags,0,0,10);
...bis zu 20 Variablen, die Bgrenzung ist S7-spezifisch...
p.addVarToReadRequest(daveDB,1,20,4);
res=dc.daveExecReadRequest(p, resultSet);

erst die letzte Zeile löst die Kommunikation mit der CPU aus und holt bis zu 20 verschiedene Dinge in einem Rutsch.


----------

