# Neues libnodave Version (woher?)



## BorisDieKlinge80 (28 Januar 2009)

Hallo Leute,

wo bekomme ich die neuste libnodave Version???

Ich will libnodave mit c# verwenden, gibts gute beispiele?

Und noch was, wer hat mal die Datenübertragungs geschwindigkeit gestest zwischen PC und PLC (Siemens S7) über TCP/IP? Wie schnell sind so ungefähr die übertragungs zeiten?

EDIT: Gibt nes schöne Dokumentaion der libnodave library? Google spuckt nix aus


----------



## Rainer Hönle (28 Januar 2009)

Die Datenübertragungszeiten bzw. der Datendurchsatz hängt weniger von der Bibliothek sondern eher vonder verwendeten SPS, dem Firmwarstand, der Zykluszeit, der sonstigen Kommunikationslast etc. ab. Was kommt genau für Hardware über welchen Kommunikationsweg zum Einsatz?
Zwecks lib: mal bei sourceforge schauen.


----------



## Zottel (28 Januar 2009)

BorisDieKlinge80 schrieb:


> wo bekomme ich die neuste libnodave Version???


http://libnodave.sf.net
Die neueste Version ist immer noch 0.8.4.4



BorisDieKlinge80 schrieb:


> Ich will libnodave mit c# verwenden


kein Problem


BorisDieKlinge80 schrieb:


> , gibts gute beispiele?


Das will ich nicht beurteilen


BorisDieKlinge80 schrieb:


> Und noch was, wer hat mal die Datenübertragungs geschwindigkeit gestest zwischen PC und PLC (Siemens S7) über TCP/IP? Wie schnell sind so ungefähr die übertragungs zeiten?


Das Programm wartet haupsächlich auf die CPU. Die erreichbaren Zeiten und Geschwindigkeiten hängen sehr stark von der CPU (Typ? Firmware? Ausgabestand?) ab.
testISO_TCP -b [IP-Adresse] zeigt dir, was "drin" ist.


----------



## BorisDieKlinge80 (28 Januar 2009)

Ja verwende monentan ne Siemens S7 400, aber auch mal ne VIPA 317


----------



## Rainer Hönle (28 Januar 2009)

Bei der S7-400 mit CP 443-1 ist ein Nutzdatendurchsatz von über 50 KByte/s realisierbar, sofern die Daten einigermaßen am Stück vorliegen. Mit der Vipa habe ich keine Erfahrungen.


----------



## Key (28 Januar 2009)

Doch schon soviel? Also 315er mit CP343-1 schafft gerade 4KB/s max. liegt aber am Rückwandbuss. Die NetLinks sollte da um einiges schneller sein.

Herr Hönle kann sicher dazu was sagen, würde mich auch mal interessieren, was da möglich ist.


----------



## BorisDieKlinge80 (28 Januar 2009)

Gibts eigentlich ne Doku zu LibnoDave, google spuckt nix aus

Wie ist das eig. mit libnodave wird bei datenänderung auf der PLC ein event geworfen? oder muss ich per polling ständig änderungen mit nem lokalen buffer vergleichen..... ??


----------



## Key (28 Januar 2009)

Jap, pollen zumindest ist mir nix anderes bekannt.


----------



## BorisDieKlinge80 (28 Januar 2009)

Blöde Frage: hab es geschaft ne verbindung zu ner S7 aufzubauen mit libnodave, aber VIP "socked error" die IP stimmt , kann sie auch anpingen.. liegt vll. am Port? Verwenden VIPA nen anderen Port wie siemens (port 102) ?

@Rainer: verwende ISO TCP


----------



## Key (28 Januar 2009)

Glaub ja und glaub mal was gelesen zu haben das man die auf Vipa Siete konfigurieren muss und die dann verwenden soll. Evtl. irgendwas mit 666 oder so aber weiß das auch nicht merh genau.

Zur not kannst du ja mit nem entsprechenden Tool mal die ports scannen dann sieht welche offen sind.


----------



## BorisDieKlinge80 (28 Januar 2009)

jetzt gehts (zahlendreher^^)   Ich hab immer noch keine dok.. wil DB2 -> 22 Real werte aulesen... verwendung ISO_TCP:


```
fds.rfd = libnodave.openSocket(102,"................");
           // fds.rfd=libnodave.openSocket(102,args[0]);
            fds.wfd=fds.rfd;
            if (fds.rfd>0) { 

                di =new libnodave.daveInterface(fds, "IF1", 0, libnodave.daveProtoISOTCP, libnodave.daveSpeed187k);
                di.setTimeout(1000000);
        //        res=di.initAdapter();    // does nothing in ISO_TCP. But call it to keep your programs indpendent of protocols
        //        if(res==0) {


                dc = new libnodave.daveConnection(di,0 , rack, slot);
                if (0==dc.connectPLC()) {
                    res=dc.readBytes(libnodave.daveFlags,2, 0, 88, null);
                    if (res==0) {
                        a=dc.getS32();    
                        b=dc.getS32();
                        c=dc.getS32();
                        d=dc.getFloat();
                        Console.WriteLine("FD0: " + a);
                        Console.WriteLine("FD4: " + b);
                        Console.WriteLine("FD8: " + c);
                        Console.WriteLine("FD12: " + d);
                    } else 
                        Console.WriteLine("error "+res+" "+libnodave.daveStrerror(res));
                }
                dc.disconnectPLC();
```

aber dc.connectPLC gibt NULL zurück.. muss ich bei

* di =new libnodave.daveInterface(fds, "IF1", 0, libnodave.daveProtoISOTCP, libnodave.daveSpeed187k);
                di.setTimeout(1000000);*

noch was ändern???

ICH BRAUCH DOKU


----------



## Key (28 Januar 2009)

du hast doch die dll eingebunden. also haste intellisense.

statt Flags musst du daveDB nehmen aber steht ja alles da im Methodenkopf


----------



## BorisDieKlinge80 (28 Januar 2009)

> statt Flags musst du daveDB


 sorry aber ich weis nich was du meinst, ja ich sehe schon was für parameter die methoden erwarten, aber das hilft mir hier nichts...

und wenn du die "flags" bei "readBytes" meinst, da kommt er ja nich mal hin


----------



## Key (28 Januar 2009)

BorisDieKlinge80 schrieb:


> jetzt gehts (zahlendreher^^)  Ich hab immer noch keine dok.. wil DB2 -> 22 Real werte aulesen... verwendung ISO_TCP:
> 
> 
> ```
> ...


 
So sollte es gehen

Edit: Aso gitb es NULL oder 0 zurück. 0 wäre in dem Fall korrekt.


----------



## Zottel (28 Januar 2009)

res=dc.readBytes(libnodave.daveDB,2, 0, 88, null);



> oder muss ich per polling ständig änderungen mit nem lokalen buffer vergleichen..... ??


Ja. Must du. Und wenn ein OPC-Server das anders handhabt, bedeutet es, daß der ständig pollt.

Hat jemand Interesse an eine Passiv-Version (PC startet Server auf Port 102, SPS verbindet sich damit)? Damit könnte die SPS Daten bei Änderung senden. Allerdings müssen dann auf der SPS-Seite Verbindungsaufbau und Fehlerbehandlung abgewickelt werden.


----------



## Key (28 Januar 2009)

Ist das ein Angebot es zu entwickeln oder hast du sowas schon da?

@Boris: evtl. 

```
[SIZE=2][COLOR=#0000ff][SIZE=2][COLOR=#0000ff]private [/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2][COLOR=#2b91af][SIZE=2][COLOR=#2b91af]libnodave[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2].[/SIZE][SIZE=2][COLOR=#2b91af][SIZE=2][COLOR=#2b91af]daveConnection[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] dc;[/SIZE]
```
vergessen?


----------



## Rainer Hönle (28 Januar 2009)

Zottel schrieb:


> res=dc.readBytes(libnodave.daveDB,2, 0, 88, null);
> 
> 
> Ja. Must du. Und wenn ein OPC-Server das anders handhabt, bedeutet es, daß der ständig pollt.
> ...


Dieser Zusammenhang stimmt leider nicht. Der Unterschied zwischen aktiv und passiv ist nur, wer den Verbindungsaufbau initiiert. Der restliche Zugriff ist in beiden Fällen gleich. Wenn der PC Daten haben will, dann muss er sie normalerweise anfragen. Somit bringt eine Umstellung auf einen passive Verbindungsaufbau nichts außer Ärger, denn die SPS muss wissen, zu wem sie die Verbindung aufbauen soll. Andere TCP/IP-Adresse bedeutet somit andere Konfiguration. Und was dies bedeutet ist ja klar.


----------



## Zottel (28 Januar 2009)

Key schrieb:


> Ist das ein Angebot es zu entwickeln oder hast du sowas schon da?


Fertig habe ich es nicht. Es sollte aber nicht allzu schwer zu realisieren sein.


----------



## Zottel (28 Januar 2009)

> Dieser Zusammenhang stimmt leider nicht. Der Unterschied zwischen aktiv und passiv ist nur, wer den Verbindungsaufbau initiiert. Der restliche Zugriff ist in beiden Fällen gleich. Wenn der PC Daten haben will, dann muss er sie normalerweise anfragen.


Zweifel! Die SPS (mit CPx43 oder Ethernet onboard) sollte doch mittels der Bausteine GET und PUT Daten (auf ihre Initiative) zu einem PC schicken können?
Dabei wäre es vielleicht. noch schöner, wenn der PC diese Verbindung aufbaut, dann hätte man den Ärger mit der Konfiguration nicht...


----------



## Rainer Hönle (28 Januar 2009)

Dies liegt aber nicht am aktiven oder passiven Verbindungasaufbau. Grundsätzlich sind bei projektierten Verbindungen ein paar zusätzliche Dinge wie BSEND, BRCV, USEND, URCV etc. realsierbar. Aber diese funktionieren, egal wer die Verbindung aufbaut.
Wir können gerne am Forumstreffen uns ausführlich darüber unterhalten. Kommst du dieses mal wieder?


----------



## argv_user (28 Januar 2009)

Zottel schrieb:


> Zweifel! Die SPS (mit CPx43 oder Ethernet onboard) sollte doch mittels der Bausteine GET und PUT Daten (auf ihre Initiative) zu einem PC schicken können?
> Dabei wäre es vielleicht. noch schöner, wenn der PC diese Verbindung aufbaut, dann hätte man den Ärger mit der Konfiguration nicht...



Im Prinzip musst Du dann aber einen Interpreter für die Kommandos der SPS bauen. Ich glaube sowas gibt es daher auch nicht fertig zu kaufen (lasse mich aber gerne belehren).


----------



## Zottel (28 Januar 2009)

Rainer Hönle schrieb:


> Dies liegt aber nicht am aktiven oder passiven Verbindungasaufbau. Grundsätzlich sind bei projektierten Verbindungen ein paar zusätzliche Dinge wie BSEND, BRCV, USEND, URCV etc. realsierbar. Aber diese funktionieren, egal wer die Verbindung aufbaut.


Es ist nur "natürlicher", daß derjenige, der mit dem Senden beginnt, auch die Verbindung herstellt. 
Sonst ist es ein wenig so, als ob man jemanden anriefe, um dann schweigend zu warten, ob er denn wohl was sagt und andersherum wartet der andere vergeblich auf den Anruf, obwohl er was zu sagen hätte...
Aber wegen der Umständlichkeit, die HW-Konfig zu ändern, könnte es ein brauchbarer Weg sein.



> Wir können gerne am Forumstreffen uns ausführlich darüber unterhalten. Kommst du dieses mal wieder?


Prinzipiell immer gerne. Aber jetzt kann ich es noch nicht bestimmt sagen.


----------



## Zottel (28 Januar 2009)

argv_user schrieb:


> Im Prinzip musst Du dann aber einen Interpreter für die Kommandos der SPS bauen.


Der "Witz" ist, daß in Libnodave vorhandene Routinen wahrscheinlich schon große Teile eines solchen "Interpreters" abdecken.


----------



## argv_user (28 Januar 2009)

Zottel schrieb:


> Der "Witz" ist, daß in Libnodave vorhandene Routinen wahrscheinlich schon große Teile eines solchen "Interpreters" abdecken.



Ich glaube trotzdem nicht dass es so einfach ist.
Gegenüber der SPS muss die Software eine SPS simulieren. Wird noch
gehen, wenn man DB, Merker, EA etc. in entsprechenden Arrays verwaltet.

Die Kernfrage ist aber der Sinn der Aktion.
Nur weil die OO-Fuzzies (bitte nicht hauen) das so wollen?
Was glaubst Du warum es sowas nicht schon längst zu kaufen gibt?


----------



## BorisDieKlinge80 (29 Januar 2009)

Hallo:    

```
byte[] m_Dat = new byte[88];
     res=dc.readBytes(libnodave.daveDB,2, 0, 88, m_Dat);
```

   res=5

hier:


```
byte[] m_Dat = new byte[88];
                    res=dc.readBytes(libnodave.daveFlags,2, 0, 88, m_Dat);
```

res=0

was bedeute dieser parameter (ich verwende ne VIPA)


----------



## BorisDieKlinge80 (29 Januar 2009)

Hmm , gibts ne möglichkeit den SPS Speicher der DBS direct row auszulesen?  und ich später durch adressen bestimme wo sich die DB befinden? vll. geht so das lesen schneller????


----------



## Key (29 Januar 2009)

#define daveAdressOutOfRange 5

//means the data address is beyond the CPUs address range

Ist der DB wirklich so lang? Anscheinend nicht.


----------



## BorisDieKlinge80 (29 Januar 2009)

Der DB war nich mal vorhanden.. hat der Kollege vergessen runterzuspielen.. SPS kenn ich mich net aus 

Wenn ich jetzt readBytes verwende, bleibt er hängen?? woran liegt das?

EDIT: Gibt vll. irgendwo ne alternative zu libnodave? was verwendet bspw. softing?


----------



## Key (29 Januar 2009)

In der Form denke ich nicht. Kommerziell von Siemens ProDave z.B.


----------



## BorisDieKlinge80 (29 Januar 2009)

ProDave müsste ja bei siemes simatic liszensen dabei sein oder? Auf der Simatic CD Da??


----------



## Rainer Hönle (29 Januar 2009)

BorisDieKlinge80 schrieb:


> ProDave müsste ja bei siemes simatic liszensen dabei sein oder? Auf der Simatic CD Da??



Prodave ist ein eigenes Produkt das separat zu lizensieren ist und befindet sich nicht auf der CD. 
[Werbung]Aber bei Alternativen lohnt sich mit Sicherheit ein Blick auf ACCON-AGLink. Dort sind alle notwendigen Funktionen drin: Ist der Baustein da, wie lang ist er, ... Und AGLink liefert eine Fehlermeldung und hängt sich nicht auf. Bei Fragen dazu stehe ich gerne zur Verfügung ;-).[/Werbung]


----------



## Key (29 Januar 2009)

Ich denke mal das mit dem Aufhängen ist eher eine Ausnahme und nicht die Regel bei libnodave. Wer es wirklich komfortabler möchte muss natürlich für solche Libs zahlen. Wobei ich mal denke das libnodave sogar schon besser als ProDave ist was die Möglichekiten anbelangt. Man muss nur mit klarkommen.

@Herr Hönle: Wann ist mal wieder eine intressante Inforveranstaltung bei Ihnen im Haus? Auf der Website habe ich nichts aktuelles gefunden.


----------



## BorisDieKlinge80 (29 Januar 2009)

Hallo Herr Höhlne,

ich schau mir grad die Demo Version von AGLink an Und hab mal das VB6 Beispiel Projekt dazu geöffnet.. hab das manual nich groß gelesen... 

Das VB Projekt lässt sich starten, allerding finde ich da keine möglichkeit die IP Adresse der SPS anzugeben, nur dev, rack, slot nr etc.

Oder brauch man da etwa ein tool, um die Libraray zu konfigureiren?


----------



## Rainer Hönle (29 Januar 2009)

Key schrieb:


> @Herr Hönle: Wann ist mal wieder eine intressante Inforveranstaltung bei Ihnen im Haus? Auf der Website habe ich nichts aktuelles gefunden.


Wir sind gerade am Planen. Infos werden demnächste veröffentlicht.


----------



## Rainer Hönle (29 Januar 2009)

BorisDieKlinge80 schrieb:


> Hallo Herr Höhlne,
> 
> ich schau mir grad die Demo Version von AGLink an Und hab mal das VB6 Beispiel Projekt dazu geöffnet.. hab das manual nich groß gelesen...
> 
> ...



Die Konfiguration findet am Besten mit AGLink40_Config statt. Dort kann dann auch gleich der Zugriff getestet werden, ob alles richtig parametriert ist. Und natürlcih AGLink40 (und nicht 3.x) verwenden ;-).


----------



## BorisDieKlinge80 (29 Januar 2009)

Hmm der AGLink Konfigurator hat ja ne ziemliche ähnlichkeit mit dem softig OPC Server^^ 

hmm.. das ist blöd mit der konfiguation... gibts keine möglichkeit die aglibraray über den code zu parameteiren wie in libnodave?? wäre edel sollte beides gehen.. hehe


----------



## Rainer Hönle (29 Januar 2009)

BorisDieKlinge80 schrieb:


> Hmm der AGLink Konfigurator hat ja ne ziemliche ähnlichkeit mit dem softig OPC Server^^
> 
> hmm.. das ist blöd mit der konfiguation... gibts keine möglichkeit die aglibraray über den code zu parameteiren wie in libnodave?? wäre edel sollte beides gehen.. hehe


Der Konfigurator des OPC-Servers ist natürlich eine Spezialversion von AGLink40_Config (wen wundert das).
Selbstverständlich besteht die Möglichkeit, alles über Code einzustellen. AGLink40_Config verwendet auch nur die Funktionen aus AGLink. Allerdings rate ich von dieser Variante ab. Grund: Über die externe Konfiguration kann jederzeit auch auf eine komplett anderer Schnittstelle (TCP/IP statt NetLink-PRO, CP5611 statt PC-Adapter, ...) umgestellt werden ohne dass am eigenen Programm etwas geändert werden muss. Die API von ACCON-AGLink ist unabhängig vom Kommunikationsweg. Es ist sogar (mit entsprechenden systembedingten Einschränkungen) der Wechsel zwischen S5, S7-200, S7-300, S7400 möglich. Außerdem wird AGLink40_Config von uns weitergepflegt und unterstützt immer die neuesten Möglichkeiten von AGLink (wenn es um erweiterte Parameter geht) und muss nicht im eigenen Programm noch einmal nachgebildet werden.


----------



## BorisDieKlinge80 (29 Januar 2009)

Ja ich experimentiere grab bischen rum... ich brauche schnelle Antwort zeiten.. ich will via Polling in nem extra Thread ja ständig änderungen auf der PLC abfragen (Denke der AGLink hat kein OnChange Event). 

Wenn ich aber jede einzelen DB einelsen muss kostet mich das Zeit. nun dachte ich mir (Da ich die speicherbreiche der DB und größe auf der SPS ja kenne) einfach immer komplett den ganzen speicher in nem kurzen intervall einlesen, mit dem interen buffer vergleichen.. und auf der PC ebene dies da in DB Klassen mappen.

Kann ich mit dem AGLink sowas umsetzen?


----------



## Rainer Hönle (29 Januar 2009)

Soll der ganze Speicherbereich immer auf Änderung geprüft werden? Ich würde in der SPS ein Changed-Flag mit Quitterflag einbauen und nur ein einziges Bit lesen und bei Änderung dann den gesamten Block. Hängt natürlich davon ab, wie oft die Änderungen stattfinden. 
Aber grundsätzlich geht da Ganze auch wie beschrieben.


----------



## BorisDieKlinge80 (29 Januar 2009)

Ja wie sieht das denn aus? Ich will nich jeden vorhanden DB nacheinander einlesen und mit nem temp. gepuferten verlgeichen (kostet zu viel zeit). Gibt es auf der SPS kein Speicher berecih wo nur die DB's liegen und ich die auslesen kann? Hat AGLink funktionen die direkt auf dem psyikalischen speicehr zugreifen wo alles DB's liegen?? Wäre interessant zu wissen.. würde halt gerne mit 50.100ms pollen und zwar allle DBs


----------



## argv_user (29 Januar 2009)

BorisDieKlinge80 schrieb:


> Ja wie sieht das denn aus? Ich will nich jeden vorhanden DB nacheinander einlesen und mit nem temp. gepuferten verlgeichen (kostet zu viel zeit). Gibt es auf der SPS kein Speicher berecih wo nur die DB's liegen und ich die auslesen kann? Hat AGLink funktionen die direkt auf dem psyikalischen speicehr zugreifen wo alles DB's liegen?? Wäre interessant zu wissen.. würde halt gerne mit 50.100ms pollen und zwar allle DBs



Wenn Du nicht alle DB auslesen willst, so klappt das nur wenn das SPS-Programm mitmacht. Rainer Hönle hat es oben bereits beschrieben.


----------



## BorisDieKlinge80 (29 Januar 2009)

hmm schade muss also für jeden Db ne read operation amchen.. umsomehr es sind um so länger gehts pollen. Wie agieren da denn OPC Server, da kann man ja 100ms update intervall angeben.. aber die werden intern auch net schlenner sein wie wenn man es mit AGLink, Prodave, libnodave .. oder weil die auch intern solche library verwenden!?


----------



## argv_user (29 Januar 2009)

BorisDieKlinge80 schrieb:


> hmm schade muss also für jeden Db ne read operation amchen.. umsomehr es sind um so länger gehts pollen. Wie agieren da denn OPC Server, da kann man ja 100ms update intervall angeben.. aber die werden intern auch net schlenner sein wie wenn man es mit AGLink, Prodave, libnodave .. oder weil die auch intern solche library verwenden!?



Selbst OPC-Server können nicht hexen! Auch da müssen die Daten über
die Leitung wandern. Das geht auch nicht schneller als mit der puren
library.
Nur können die OPC-Clients die Daten "schneller" (d.h. eigentlich öfter)
vom Server abfragen. Das ändert aber nichts an der Übertragungsrate zwischen PC und SPS. Du kannst 100 Mal den Server abfragen und er wird Dir immer die gleichen Daten aus seinem Puffer liefern, solange das neue Datenpaket der SPS noch nicht da ist...


----------



## BorisDieKlinge80 (29 Januar 2009)

Ja das dachte ich mir ... mit welcher Library arbeitet denn WinCC? mit ProDave odeR?


----------



## Rainer Hönle (29 Januar 2009)

WinCC und WinCC flexible setzen auf derselben Treiberschnittstelle auf wie prodave.
Nur noch einmal zum Ausgangspunkt: Wenn die Randbedingungen auf Grund der Hardware (Übertragungsrate) nicht erfüllt werden können, dann muss eine andere Lösung (also in Software) her.
Was sind denn letztednlich dei genauen Anforderungen? Welche Datenmengen müssen übertragen werden? Welche Änderungsintervalle haben diese Daten? Was ist gefordert und was ist nice to have?


----------



## BorisDieKlinge80 (29 Januar 2009)

Hmm naja die datenübertragungs geschwindigekit und tag reaktionszeit sollte bei max 150ms liegen... habe immer mit OPC gearbeitet was aber für schnelle übertragungen bspw (Roboter steuerungs panle, wo die control daten in echtzeit übermittel werden sollten).

Biser wird auch WinCC eingesetzt, was meinung derer auch reicht um ein roboter in echtzeit zu steuern etc. d.h. wenn ich auf ProDave aufsetze müsst eich gleiche werte wie WinCC bekommen. 

Das Problem ist auch, umso mehr kleiner DB's statte weniger Großer, umso langsamer ist die update polling verfahren.


----------



## Key (29 Januar 2009)

Naja eventuell kannst du da das Prepare Statement von Libnodave nutzen.

"You may add up to 20 different items...
...fits into a single response PDU"

mit

```
PDU p;
daveResultSet rs;
 
davePrepareWriteRequest(dc, &p);
 
daveAddVarToWriteRequest(&p, daveFlags,0,0,4,buffer);
daveAddVarToWriteRequest(&p, daveDB,6,20,2,buffer);
daveAddVarToWriteRequest(&p, daveFlags,0,12,2,buffer);
 
res = daveExecWriteRequest(dc, &p, &rs);
```
 
Allerdings habe ich die Funktion in der .NET Version noch nicht gefunden. Eventuell kann ja Zottel was dazu sagen.

Aber so könntest du schon 20 abfragen in einem Request abhandeln und das ist doch schon ordentlich.


----------



## Rainer Hönle (29 Januar 2009)

BorisDieKlinge80 schrieb:


> Das Problem ist auch, umso mehr kleiner DB's statte weniger Großer, umso langsamer ist die update polling verfahren.


Nicht zwingend. Im AGLink gibt es hier spezielle Funktionen, die die Anfragen etsprechend optimiert zusammenbauen.


----------



## Question_mark (29 Januar 2009)

*Prodave/OPC*

Hallo,



			
				Rainer Hönle schrieb:
			
		

> WinCC und WinCC flexible setzen auf derselben Treiberschnittstelle auf wie prodave.



Das muss ich jetzt noch etwas vervollständigen, weil sonst ist das etwas mißverständlich :

Die Treiberschnittstelle auf der untersten Ebene ist bei WinCC und Prodave mit hoher Wahrscheinlichkeit die gleiche. Aber über Prodave greift man über eine DLL-Schnittstelle zu, während bei WinCC Siemens einen OPC-Server und OPC-Client drübergesetzt hat.



			
				Boris schrieb:
			
		

> d.h. wenn ich auf ProDave aufsetze müsst eich gleiche werte wie WinCC bekommen.



Im Prinzip ja, aber der Zugriff auf die Schnittstelle muss dann halt in deinem Anwenderprogramm bei Prodave anders programmiert werden als beim OPC-Server. 

Gruß

Question_mark


----------



## Question_mark (29 Januar 2009)

*Rangieren ???*

Hallo,



			
				Boris schrieb:
			
		

> Ja wie sieht das denn aus? Ich will nich jeden vorhanden DB nacheinander einlesen und mit nem temp. gepuferten verlgeichen (kostet zu viel zeit).



Ein OPC-Server erledigt diese Aufgaben in einem separaten Thread und feuert einen Event bei Änderung der Daten. In der Zwischenzeit kann dein Programm schlafen ...

Wenn Du keine Eventsteuerung haben willst, sind Prodave und AGLink40 von Deltalogic gute Alternativen. AGLink40 ist aber in meinen Augen besser als Prodave, einfache Handhabung und wesentlich mehr Funktionen.

Grundsätzlich (also egal welchen Kommunikationsweg man benutzt) sollte man die Daten zur Optimierung der Kommunikationsgeschwindigkeit in der SPS in aufeinanderfolgende Datenbereiche rangieren. Die Anzahl der Telegramme wird dadurch reduziert. Zehn Telegramme mit je 50 DW erzeugen eben mehr Busbelastung als ein Telegramm mit 500 DW.
Und jetzt komme mir bitte keiner mit dem Argument, das diese Rangiererei den SPS-Zyklus wesentlich belastet. Dann habt Ihr bei der Auswahl der SPS-CPU schon den ersten Fehler gemacht ..

Gruß

Question_mark


----------



## BorisDieKlinge80 (30 Januar 2009)

@Höhlnle: Kannst du mir in kurzen worten vll. bischen code /function zeigen wie ich nen optimiersten (Wie prepare data in libnodave) auf menere DBS machen?

@Question_mark: Wie muss das umgestetz werden, wie ist der Speicher (wo DB liegen) auf ner SPS aufgebaut.. wie ereicht man das DB's da hintereinanderliegen.. oder besser noch, wie kann ich unabhängig von DB's den rohen speicher lesen und den dann intern bei mir in DB auseinanderpfrimieln???

Und ja ich werde ne nextra thread für die datenabfrage zur SPS verwenden.. da darf nix hängen. Durch die umgehen unvon OPC, spar ich mir die zeit des OPC daten austausch also statt PLC<-> OPC Ser <-> OPC Cli <-> App. auf PLC <-> App.


----------



## BorisDieKlinge80 (30 Januar 2009)

EDIT: ich hab mal in C/C++ bischem it libnodave rumgespielt, und nen DB mit 40000Bytes ausgelesen:


```
timeGetSystemTime(&tStart,sizeof(tStart));


            int res= daveReadBytes(dc,daveDB,3,0,40000,vBuf);
                    

            timeGetSystemTime(&tEnd,sizeof(tEnd));

            int diff= tEnd.u.ms - tStart.u.ms;
```


17ms für 40KBytes, ist das möglich??? res gibt 0 zurück.


----------



## Rainer Hönle (30 Januar 2009)

Question_mark schrieb:


> Die Treiberschnittstelle auf der untersten Ebene ist bei WinCC und Prodave mit hoher Wahrscheinlichkeit die gleiche. Aber über Prodave greift man über eine DLL-Schnittstelle zu, während bei WinCC Siemens einen OPC-Server und OPC-Client drübergesetzt hat.


Mit Treiberschnittstelle meine ich die Ebene darunter. Sowohl bei prodave und WinCC (flexible) wird der Zugangspunkt der Appilkation angegeben (direkt oder ggf. indirekt). Dadurch wird der eigentliche Treiber festgelegt.


----------



## Rainer Hönle (30 Januar 2009)

BorisDieKlinge80 schrieb:


> 17ms für 40KBytes, ist das möglich??? res gibt 0 zurück.


Nein, dies geht nicht. Da ist irgendwo ein Fehler drin.


----------



## Zottel (30 Januar 2009)

BorisDieKlinge80 schrieb:


> EDIT: ich hab mal in C/C++ bischem it libnodave rumgespielt, und nen DB mit 40000Bytes ausgelesen:
> 
> 
> ```
> ...


Die Länge bei daveReadBytes kann sinvollerweise nicht größer sein als die in einer PDU übertragbare Datenmenge (PDUlength - 18 ?).
Darüberhinaus ist sie durch die Länge der verwendeten Puffer auf 2048 beschränkt.
Das wird (noch) nicht überprüft. Für readBytes ist es nicht schwer, aber beim Lesen mehrerer Variablen müßte eine solche Rechnung die Länge der einzelnen Antwortblöcke einschließlich Adressinformation und Füllerbytes vorausberechnen.
Insbesondere bei den Füllerbytes bin ich mir nicht sicher, ob sich jede S7 gleich verhält.
Daher zieht readBytes einfach die Anfrage durch und wenn die CPU nicht meckert, gibt es auch 0 zurück.
Ich werde mal schauen, was bei deiner Anfrage passiert.


----------



## marcengbarth (30 Januar 2009)

Wenn es schnell gehen soll mit der Kommunikation, kannst du auch eine TCP-Verbindung zwischen SPS und PC projektieren und mit SEND/RECIEVE  arbeiten.

Dann sparst du dir die Zeit zum Anfragen bei der SPS. Im SPS-Programm kannst du dir die Daten dann zum PC senden lassen. Daten in die SPS schreiben kannst du mit LibNoDave direkt.


----------



## argv_user (30 Januar 2009)

marcengbarth schrieb:


> Wenn es schnell gehen soll mit der Kommunikation, kannst du auch eine TCP-Verbindung zwischen SPS und PC projektieren und mit SEND/RECIEVE  arbeiten.
> 
> Dann sparst du dir die Zeit zum Anfragen bei der SPS. Im SPS-Programm kannst du dir die Daten dann zum PC senden lassen. Daten in die SPS schreiben kannst du mit LibNoDave direkt.



Ich bin jetzt nicht so der Kenner von LibNoDave.
SEND/RECEIVE von der SPS zu verarbeiten kann das LibNoDave?


----------



## BorisDieKlinge80 (30 Januar 2009)

mit SEND/RECIEVE arbeitet ja man dann theoretisch noch ne ebene tiefer als libnodave etc. Dann müsste man aber wissen wie die SPS ihre DBS im speicher anlegt, adressierung etc. un auf pc Ebenen auseinerander nehmen... Oder wie meint ihr das?


----------



## argv_user (30 Januar 2009)

BorisDieKlinge80 schrieb:


> mit SEND/RECIEVE arbeitet ja man dann theoretisch noch ne ebene tiefer als libnodave etc. Dann müsste man aber wissen wie die SPS ihre DBS im speicher anlegt, adressierung etc. un auf pc Ebenen auseinerander nehmen... Oder wie meint ihr das?



Bei SEND/RECEIVE (nicht RECIEVE) werden nur Datenblöcke übertragen.
Die höheren Protokolle (FETCH/WRITE) fügen noch Adressangaben hinzu.


----------



## Question_mark (30 Januar 2009)

*Dir fehlen SPS-Grundkenntnisse*

Hallo,



			
				Boris schrieb:
			
		

> @Question_mark: Wie muss das umgestetz werden, wie ist der Speicher (wo DB liegen) auf ner SPS aufgebaut.. wie ereicht man das DB's da hintereinanderliegen.. oder besser noch, wie kann ich unabhängig von DB's den rohen speicher lesen und den dann intern bei mir in DB auseinanderpfrimieln???



Mannomann Boris, warum denkst Du nur so kompliziert ??? Es ist doch dür Dich scheissegal, auf welchen absoluten Speicheradressen in der SPS die Daten oder Merkerbereiche liegen. Man kann diese Bereiche über einen absoluten oder symbolischen Namen ansprechen, es ist doch drissegal an welcher absoluten Adresse diese Daten im Speicher liegen. Und das macht den Umgang mit den Daten so einfach (sofern die Struktur bekannt ist)...
Ein typischer Fehler der Programmierer in Hochsprachen, die EDV versucht sich an der SPS ...
Lieber basteln und Kosten verbraten bis zum Ende. Bei mir rollen sich gerade die Fussnägel hoch ...

Gruß

Question_mark


----------



## Question_mark (30 Januar 2009)

*Dann warte ich mal auf konstruktive Vorschläge ...*

Hallo,



			
				Boris schrieb:
			
		

> spar ich mir die zeit des OPC daten austausch also statt PLC<-> OPC Ser <-> OPC Cli <-> App. auf PLC <-> App.



*ROFL*   Hast Du eventuell noch einen DX286 mit DOS 5.0 als OS ?
Selbst das popelige ASUS Netbook 1000 lacht sich darüber schlapp ...

Gruß

Question_mark


----------



## BorisDieKlinge80 (2 Februar 2009)

@Questen_Mark: Es ist mir schon klar das ich über divere funktionen ohne gefrimel datenbausteine auslesen kann und abhängig der struktur die werte rausziehen kann. Aber das ist hlat etwas zu langsam. Aber vll. muss ich einsehen das es nich anders/Besser/schneller geht

Aber ich will beim pollen möglichst kleine datenübertragungeraten haben. Nehmen wir an ich hab 500 DBs mit jeweils 200byte... da muss ich bei jedem poll. zyklus jeden DB abfragen und auf änderungen vergleichen.. was ja enorm zeit kostet. könnte ich jetzt den speicher der SPS direct auf einen schlag bzw. aufgeteilt in PDU blöcken direkt vom speicher lesen würde es schneller gehen. (Hat nix mit der PC Hardware leistung zu tun)

Weil TCP/IP ist ja eig. enorm schnell (500DB's * 200Byte) = 100KB! bei 10Mbit/s LAN = 1,25MB pro sekunde, würde ich theorietisch mit overhead etc. ein polling zyklus von 100ms schaffen, d.h. ich können alle 500DB alle 100ms auf änderungen pürfen.

Das war mein gedanke.. vll. ist der flaschen halt auch die SPS (TCP/IP) speicher schnittestelle...

Also gibts es keine möglichkeit schneller daetn auszulesen.. bischen byte frimilerei ist kein ding


----------



## Rainer Hönle (2 Februar 2009)

Bei der SPS-Kommunikation darf nicht nur die reine und theoretische Datenübertragungsrate betrachtet werden. Abgesehen von dem Protokolloverhead (Adressierung, TCP/IP, ..) handelt es sich bei dem SPS-Zugriff um ein Frage-Antwort-Spiel. Der PC frägt etwas an und die SPS antwortet wenn Sie Lust und Zeit hat (ihre Hauptaufgabe ist ja schlie0lich zu steuern und nicht lästigen PCs zu antworten). Auf Grund dieser Tatsache ergibt sich ein Nutzdatendurchsatz z.B. bei einer 416-2 mit 443-1 von etwas über 60 KByte/s. Und da liegen doch wohl Welten zwischen der Theorie und Praxis. Aus diesem Grund habe ich ja bereits geschrieben, dass eventuell ein anderer Ansatz gefunden werden sollte. Die SPS teilt die Änderungen eine DBs in jeweils einem Bit mit und der PC prüft die Bits und liest bei Bedarf die geänderten DBs.
Aber um das Ganz zu beruteilen muss erst einmal geprüft werden, wie oft sich die Werte ändern, was wirklich erforderlich ist und was gewünscht ist. Dann ein entsprechendes Konzept erstellt und implementiert werden.


----------



## BorisDieKlinge80 (2 Februar 2009)

Danke Rainer,

genau das wollte ich wissen... jetzt is mir auch klarer wie es mit der kommunikation aussieht. D.h. ein wirklich schnellere lösung zu kommunikatin mit der sps ist nich unbeding machbar. weil die SPS grenzen aufzeigt. Relavante daten die schnell übermittel werden sollten sind control daten , steuerbits etc.

Aber dann muss ich wohl ein dynamisches konfigurierbare polling archtektur entwickeln, welche best. datenblöcke öfters als andere datenblöcke abfragt.

Bin grad bischen miet .NET und AGLink40 beschäftigt... wie ich sehe arbeitet "ReadDataBytes" syncron.. gibts dazu asyncrone funktionen, oder muss ich das selber impelemntieren?

Und umsohöhr der Adressbereich liegt, d.h. wenn ich daten aus nem hinteren teil eines DB lese brauch die funktion länger, was soll das denn??



> AGL4.ReadDataBytes(2097152, 0, 2000, {0, 0}, 1) => 0 Time 281,25
> AGL4.ReadDataBytes(2097152, 2000, 4000, {0, 0}, 1) => 0 Time 531,25
> AGL4.ReadDataBytes(2097152, 4000, 6000, {0, 0}, 1) => 0 Time 812,5
> AGL4.ReadDataBytes(2097152, 6000, 8000, {0, 0}, 1) => 0 Time 1109,375
> ...


----------



## Rainer Hönle (2 Februar 2009)

Dabei wird nicht von bis sondern von Anzahl angegeben. Dies erklärt die ansteigende Dauer. Steht alles im Handbuch.


----------



## BorisDieKlinge80 (2 Februar 2009)

ohh shit , hast ja recht.. hab ich übersehne danke


----------



## BorisDieKlinge80 (2 Februar 2009)

woran lieg dasm das ich max 212 byte schreiben, und 222 Byte blöcke lesen kann mit libnodave?


----------



## Zottel (2 Februar 2009)

BorisDieKlinge80 schrieb:


> woran lieg dasm das ich max 212 byte schreiben, und 222 Byte blöcke lesen kann mit libnodave?


Das liegt daran, daß du mit einer PDU-Länge von 240 Byte arbeitest und dort nicht mehr Nutzdaten hineingehen. Das steht auch irgendwo in der Dokumentation zu libnodave.
Da du dich ja schon lange Zeit mit diesen Themen beschäftigst: Starte ein Testprogramm wie testISO_TCP.exe mit der Option -d. (Von der Kommandozeile, DOS-Box). Dann zeigt es dir, was es macht! Du kannst sehen, welche PDU-Länge ausgehandelt wird. Es zeigt dir auch den Aufbau der PDU an.
Die ultimative Möglichkeit für SCHNELLE Datenübertragung, die von der SPS angestoßen wird, wäre folgende: 
Ein Gateway gibt sich gegenüber der SPS als Profibus-Slave aus, erhält einmal pro Zyklus seine "Ausgangsdaten" (max 240 Byte oder so) und sendet dann ein (UDP, TCP oder was auch immer) Ethernet-Paket.


----------



## BorisDieKlinge80 (2 Februar 2009)

Guten Morgen zollel,

kannst du mir das:



> Die ultimative Möglichkeit für SCHNELLE Datenübertragung, die von der SPS angestoßen wird, wäre folgende:
> Ein Gateway gibt sich gegenüber der SPS als Profibus-Slave aus, erhält einmal pro Zyklus seine "Ausgangsdaten" (max 240 Byte oder so) und sendet dann ein (UDP, TCP oder was auch immer) Ethernet-Paket.



genauer erklären?

die sps gibt mir in jedem zyklus daten max 240 byte. Aber welche daten? wenn ich viel dbs haben mit insgedamt 500kb geht das nich oder?


----------



## Rainer Hönle (2 Februar 2009)

BorisDieKlinge80 schrieb:


> die sps gibt mir in jedem zyklus daten max 240 byte. Aber welche daten? wenn ich viel dbs haben mit insgedamt 500kb geht das nich oder?


Hier gilt entweder viel Daten und die langsam oder wenig Daten und die dafür schnell. Bei der vorgeschlagenen Variante ist allerdings eine Profibus-DP-Masterkarte für den PC erforderlich um die 240 Bytes Nutzdaten lesen zu können.


----------



## BorisDieKlinge80 (2 Februar 2009)

Wie handelt das der Softing OPC Server? der muss ja ständig die geänderten daten von der SPS lesen, machtder auch polling? bei vielen daten ist das doch gravierend.. oder gibt die AGLink event bei änderungen?


----------



## Rainer Hönle (2 Februar 2009)

Der DELTALOGIC und der Softing OPC-Server pollen die SPS und prüfen auf Änderung. AGLink kommuniziert nur und stellt die gewünschten Daten zur Verfügung. Wenn es darum geht, dass die SPS die Änderungen mitteilen soll, dann sind ganz andere Mechanismen erforderlich.
Ach ja, der Siemens OPC-Server pollt auch nur.


----------



## BorisDieKlinge80 (2 Februar 2009)

Ok, nehmen wir an eine read funktion (AGLink) operation 1KB dauert 100ms! Nun habe ich 20 DB jweis 30KB, dann muss ich ja 600 mal die funktion aufrufen, damit ich alles daten der sPS gelesen habe.. dauer 60000ms = 1 minute?? ein kompletter polling vorgang dauer also 1 minute , kann das überhuapt sein?


----------



## marcengbarth (2 Februar 2009)

Versuch doch mal mit LibNoDave einen von deinen DBs komplett zu lesen.

Nimm dazu die Funktion daveReadManyBytes und schau mal wie lange das dauert.


----------



## BorisDieKlinge80 (2 Februar 2009)

Hmm ok mach ich 

d.h. mit readBytes kann ich max. byte in pud größe auslesen, und readmanybytes wird interen blockweise lesen bis alles daten da sind?
sorry das ich nerve, aber für libnodave gibts ja keine doku, bzw. hab kein gefunden.

1KB dauert 78ms 40KB dauert 2800ms. habe ich meinentwegen 30DB mit 40KB dauerst halt 84sekunden.


----------



## marcengbarth (2 Februar 2009)

Im LibNoDave-Ordner gibts /doc/ da steht doch was drin.

Aber ich denke für deinen Zweck brauchst du eine andere Kommunikationsart. Um Zeit zu sparen würde ich, wie schon mal erwähnt, die Kommunikation über eine projektierte ISO-ON-TCP- oder reine TCP-Verbindung abhandeln. Bei Bausteinänderung / Datenänderung lass' die SPS mit AG_SEND (300er) / AG_LSEND (400er) die Daten senden. Deine Software muss die Daten dann nur über eine Socketverbindung annehmen.


----------



## BorisDieKlinge80 (2 Februar 2009)

Ok, d.h. die SPS muss mir die datenänderung selber über ein packet schicken. Das muss aber auf der SPS auch programmiert werden oder, ein puffer da anlegen wo geänderte variablen drin sind und in nem best. zyklus hoch schicken? Muss das ganze dann vom SPS Programmiere via AWL implementiert werden?


----------



## marcengbarth (2 Februar 2009)

Ja, das muss dann vom SPS-Mensch gemacht werden.


----------



## BorisDieKlinge80 (2 Februar 2009)

danke jungs.. die forum hat mir schon enorm geholfen werd mich jetzt mal dran machen und schaun wie ich das mache


----------



## Zottel (2 Februar 2009)

BorisDieKlinge80 schrieb:


> Guten Morgen zollel,
> 
> kannst du mir das:
> 
> ...


Die, die du von der SPS aus sendest. Es muß also in der SPS programmiert werden.



BorisDieKlinge80 schrieb:


> wenn ich viel dbs haben mit insgedamt 500kb geht das nich oder?


Doch, entweder die 500kB in 2000 Häppchen übermitteln oder (Aufwand in der SPS) nur die Änderungen gegenüber dem letzten Zyklus übermitteln (Viel Arbeit für die SPS).
Die theoretische Grenze ist erreicht, wenn die Änderungen größer als der Durchsatz auf dem Profibus sind.



			
				Rainer Hönle schrieb:
			
		

> Bei der vorgeschlagenen Variante ist allerdings eine Profibus-DP-Masterkarte für den PC erforderlich um die 240 Bytes Nutzdaten lesen zu können.


Ich schrieb: Gateway. Dabei dachte ich an einen kleine Platine mit Profibus und Ethernet Anschluß. Ähnlich einem DP-DP-Koppler, aber eine Seite DP und die andere Ethernet...


----------

