Neues libnodave Version (woher?)

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

Code:

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:

Code:

            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:

Code:

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.

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

Neues libnodave Version (woher?)

Level-1

Level-1

Level-1

Level-1

Level-3

Level-1

Level-1

Level-3

Level-1

Level-1

Level-1

Level-1

Level-3

Level-3

Level-3

Level-1

Level-1

Level-1

Level-1

Level-1

Similar threads

Wir schützen deine Privatsphäre