# Datenbereich konsistent lesen



## Larry Laffer (11 August 2008)

Ich bin da gerade drüber gestolpert ...
Interessieren tut es mich für ProTool - ich denke aber, dass es in Flex da ggf. Parallelen gibt.

Ich möchte gern einen größeren Datenblock mit aneinanderhängenden Daten unterschiedlichen Formats "in einem Rutsch" zur Visu übertragen. Dieses Verfahren wird bei Profilkurven von der Visu praktiziert. Gibt es eine Möglichkeit, das auch als eine Art "Send to Visu" anzustossen ?
Ich könnte mir vorstellen, dass da etwas über die Bereichszeiger geht, nur habe ich irgendwie bisher keine Detail-Liste dazu gefunden.

Vielleicht weiß ja jemand Rat ...

Gruß
LL


----------



## johnij (11 August 2008)

*??????????*




Larry Laffer schrieb:


> Ich bin da gerade drüber gestolpert ...
> Interessieren tut es mich für ProTool - ich denke aber, dass es in Flex da ggf. Parallelen gibt.
> 
> Ich möchte gern einen größeren Datenblock mit aneinanderhängenden Daten unterschiedlichen Formats "in einem Rutsch" zur Visu übertragen. Dieses Verfahren wird bei Profilkurven von der Visu praktiziert. Gibt es eine Möglichkeit, das auch als eine Art "Send to Visu" anzustossen ?
> ...


 
Hallo LL ,
ich frag mich (bitte nicht böse gemeint), ob es noch Firmen gibt , die bei neuen Projekten Pro Tool einsetzen

Wozu möchtest du die Massendaten (als zusammenhängender Block) auf einmal in die Visu übertragen??

Das geht  leider mit dem Bereichzeiger nicht.

johnij


----------



## Larry Laffer (11 August 2008)

johnij schrieb:


> Hallo LL ,
> ich frag mich (bitte nicht böse gemeint), ob es noch Firmen gibt , die bei neuen Projekten Pro Tool einsetzen
> 
> Wozu möchtest du die Massendaten (als zusammenhängender Block) auf einmal in die Visu übertragen??
> ...


 
Hallo Johnij,
ich bin dir nicht böse ... 
Zur Info: in unserer Firma ist noch überwiegend ProTool im Einsatz. Das liegt aber in der Hauptsache an mir. Leider habe ich nicht die Zeit, ein Projekt mit Flex zu erstellen. In der Zeit, die ich benötige un in Flex 4 EA-Felder auf den Bildschirm zu bringen (inkl. Aufrufzeit von Flex) habe ich in ProTool 4 komplette Bildschirmseiten mit ca. 200 Variablen erzeugt, gestaltet und korrekt zugewiesen. Es geht mit PT halt alles um den Faktor 10 schneller und ist (nach meiner Meinung) auch übersichtlicher. Hinzu kommt, dass mir bislang auch noch keine Fähigkeit bei PT gefehlt hat.

Zum Problem:
Ich archiviere Produktionsdaten in schneller Folge. Hierbei habe ich festegestellt, dass ich ab und zu bei Variablen einen "alten Stand" abspeichere. Das wollte ich auf diese Weise verhindern.

Gruß
LL


----------



## johnij (11 August 2008)

Larry Laffer schrieb:


> Hallo Johnij,
> ich bin dir nicht böse ...
> Zur Info: in unserer Firma ist noch überwiegend ProTool im Einsatz. Das liegt aber in der Hauptsache an mir. Leider habe ich nicht die Zeit, ein Projekt mit Flex zu erstellen. In der Zeit, die ich benötige un in Flex 4 EA-Felder auf den Bildschirm zu bringen (inkl. Aufrufzeit von Flex) habe ich in ProTool 4 komplette Bildschirmseiten mit ca. 200 Variablen erzeugt, gestaltet und korrekt zugewiesen. Es geht mit PT halt alles um den Faktor 10 schneller und ist (nach meiner Meinung) auch übersichtlicher. Hinzu kommt, dass mir bislang auch noch keine Fähigkeit bei PT gefehlt hat.
> 
> ...


 
@LL
In der Zukunft bist du gezwungen mit WCF zu arbeiten.

Das mit dem Archivieren: in WCF geht es nur mit schon deklarierten Variablen --->Hacken beim Archivieren setzen.

Ich weiss es, es ist zeitaufwendiger. Eine andere Lösung gibt es leider nicht

Viele Grüße  
johnij


----------



## Larry Laffer (11 August 2008)

johnij schrieb:


> Das mit dem Archivieren: in WCF geht es nur mit schon deklarierten Variablen --->Hacken beim Archivieren setzen.


 
Diese Form des Archivierens meinte ich nicht. Die Daten sollen schon in formatierte und wieder aufgreifbare Listen (in unserem Fall Excel) geschrieben werden.



johnij schrieb:


> Eine andere Lösung gibt es leider nicht


 
Glaube ich erstmal nicht - es gibt immer eine Lösung ...

Gruß
LL


----------



## johnij (11 August 2008)

Larry Laffer schrieb:


> Diese Form des Archivierens meinte ich nicht. Die Daten sollen schon in formatierte und wieder aufgreifbare Listen (in unserem Fall Excel) geschrieben werden.
> 
> Gruß
> LL


 
In WCF gibt es nur:
1-Medlungen-Archivieren (hat mit deinem Fall Nix zu tun)
2-Variablen-Archivieren.

Wenn ich Dich jetzt richtig verstanden habe:

Sps(Log data)-->Visu (WCF)-->Excel_Anwendungsprogramm

In etwa?

http://support.automation.siemens.c...extranet=standard&viewreg=WW&load=treecontent

johnij


----------



## Larry Laffer (11 August 2008)

... genau !
Ich schreibe per Script die Variablen-Inhalte in eine Excel-Tabelle. Ein anderes Script schreibt Kurvendaten mit Eckwerten in eine CSV-Datei. An letzterer Stelle gibt es mitunter Verschiebungen und zwar bei den Einzel-Daten ...


----------



## Ralle (11 August 2008)

johnij schrieb:


> @LL
> In der Zukunft bist du gezwungen mit WCF zu arbeiten.



johnij, du vergißt, es könnt durchaus auch passieren, daß Siemens gezwungen ist, ohne Kunden zu arbeiten!!!!!!!!!!! Wir sind spätestens seit WinCCFlex für Alternativen viel offener, dank Siemens .

@LL

Leider ist mir dazu auch nichts bekannt .


----------



## Larry Laffer (11 August 2008)

@Ralle:
Danke trotzdem für den Beitrag ... du sprachst mir aus dem Herzen ...

Gruß
LL


----------



## Larry Laffer (11 August 2008)

@Johnij:
Jetzt nur mal so interessehalber ... kann Flex denn das, was ich haben will ...?


----------



## vierlagig (11 August 2008)

mal um die ecke gedacht: mit dem "send to visu" von der cpu das "read from plc" im protool anstoßen?


----------



## Larry Laffer (11 August 2008)

... wo hast du das denn gefunden ..? Wenn es das gibt, dann geht das natürlich genauso gut. Es geht mir ja nur darum, dass ein Datenblock als Einheit gelesen (aktualisiert) wird ...


----------



## vierlagig (11 August 2008)

hab ich nicht gefunden, mir nur aus deiner aussage "von der visu aus gibts das ja auch" zusammengereimt ... wie stößt man das von der visu aus an?


----------



## Larry Laffer (11 August 2008)

Die Visu macht etwas ähnliches bei ARRAY's und STRING's im Allgemeinen und Kurven im Besonderen.
Ich habe auch schon darüber nachgedacht, aus meinem Mischmasch ein Array zu machen - das Problem ist dabei nur, dass es relativ viele REAL-Var's beinhaltet, daneben aber auch einen String, ein Date, einige INT's und einige Bool's.
Jetzt könnte ich ja hergehen und aus Allem ein ARRAY of BYTE (z.B.) machen ... aber wie mache ich aus den Bytes hinterher via Script wieder einen Real in PT ? Hier wäre jetzt einen Art AT-Befehl genau das, was ich bräuchte. Dann hätte ich die Lösung schon selbst ...

...


----------



## vierlagig (11 August 2008)

das lässt mich nicht los ... die kurvenübertragung macht das, was du willst, oder? funktioniert nur nicht mit zusammengewürfelten daten ... aber wie die z.b. INT-werte in dem DB aussehen ist dem protool ja egal ... weiter schreibst du, du möchtest die daten in excel haben, da ich weiß, dass du kurven in excel bekommst, solltest du auch diese werte in excel bekommen und dann aufdröseln, was IMHO in VB recht gut funktionieren sollte, vielleicht sogar besser als im protool-skript ... ist das soweit das, was du dir vorstellst?

mit dem array of byte ist es ja das selbe, wenn ich dir da glauben schenke, habe im handbuch nur nicht die stelle gefunden, deswegen hab ich mich auf die kurven bezogen ... bytes würden sich leichter zu einem real zusammen pappen lassen, aber du müßtest auch INT werte zusammenfriemeln ...

aber irgendwie sieht mir das sehr nach einer bastellösung aus und wenn es ums basteln geht, kommt libnodave ins spiel ... die widerspruchsfreiheit müßteste damit auch gewährleisten können und du kannst direkt aus excel heraus operieren ...


----------



## Larry Laffer (11 August 2008)

vierlagig schrieb:


> das lässt mich nicht los ...



Hallo 4L,
das finde ich nett ...
Ich habe auch noch ein wenig darüber nachgedacht. 

Die Lösung, die Aktion mittels Libnodave oder AGLink an Excel zu übertragen erscheint mir an dieser Stelle übertrieben.

Die andere Variante, die dir nicht so gut gefällt (ARRAY of INT oder DINT) rückt für mich immer mehr in den Fokus. Problematisch sind im Augenblick nur die REAL's. Hier sei aber gesagt, dass diese nur aus Bequemlichkeit existieren. Da ich mich sowieso bei allen Messwerten nur für max. 2 Nachkommastellen interessiere könnte ich genausogut alles mit 100 multiplizieren und in der Visu wieder zurückrechnen. Hier würden sogar INT's gehen, da keiner meiner Messwerte über 250 kommt. Der Date-Wert läßt sich so auch übertragen, wobei hier in der Visu letztlich das Klartext-Datum interessant ist, das ich mir in der SPS auch bilden kann. Die BOOL-Werte liegen sowieso hintereinander und passen somit prima in 2 INT's Ausmaskieren kann VB-Script ja.

Somit ... wenn nicht noch jemand mit der Super-Idee um die Ecke kommt, dann wird es wohl morgen so von mir umgesetzt.

In diesem Sinne ...

Liebe Grüße 
LL


----------



## Maxl (11 August 2008)

johnij schrieb:


> @LL
> In der Zukunft bist du gezwungen mit WCF zu arbeiten.
> 
> Viele Grüße
> johnij


die typische Siemens-Denkweise................ geht das nicht in den Kopf von den Leuten bei Siemens, dass der Kunde nicht immer das will wozu er von Siemens gezwungen wird?




			
				Larry Laffer schrieb:
			
		

> Die andere Variante, die dir nicht so gut gefällt (ARRAY of INT oder DINT) rückt für mich immer mehr in den Fokus. Problematisch sind im Augenblick nur die REAL's. Hier sei aber gesagt, dass diese nur aus Bequemlichkeit existieren. Da ich mich sowieso bei allen Messwerten nur für max. 2 Nachkommastellen interessiere könnte ich genausogut alles mit 100 multiplizieren und in der Visu wieder zurückrechnen. Hier würden sogar INT's gehen, da keiner meiner Messwerte über 250 kommt. Der Date-Wert läßt sich so auch übertragen, wobei hier in der Visu letztlich das Klartext-Datum interessant ist, das ich mir in der SPS auch bilden kann. Die BOOL-Werte liegen sowieso hintereinander und passen somit prima in 2 INT's Ausmaskieren kann VB-Script ja.


also mir erscheint das als sinnvollste Lösung


Das Problem mit der "Konsistenz" ist übrigens bei WinCCflex genau das gleiche - hatten (soweit mir bekannt ist) vor letztes Jahr bei einer Anlage genau das gleiche Problem - mittels Triggerbit wurde PLC-Variablen in eine Datenbank übertragen - teilweise waren es aber noch "alte" Stände.
Abhilfe schafft hier ein "Doppelter Handshake" (PLC kopiert Daten in Schnittstelle - setzt anschließend 1. Triggerbit - 1. Triggerbit wird von Visu quittiert - PLC setzt dadurch 2. Triggerbit - mit 2. Triggerbit werden Daten weggeschrieben - die Triggerbits und die eigentlichen Prozessdaten werden haben gleiche Aktualisierungszeit - durch diese bewusst Verzögerung kann angenommen werden, dass die Daten in WinCCflex aktuall sind - ist aber eine Zeitfrage)

mfg Maxl


----------



## Ralle (11 August 2008)

Das Problem besteht im übrigen auch bei libnodave, hatte ich mal festgestellt. Das hängt auch davon ab, wo in dem Variablenpulk die Quitt-Var steht und wo beim Start der Aktualisierung der aktuelle "Datenzeiger" (ich nenn das mal so) gerade ist. Das ganze ist ja zwischen SPS-Zyklus und HMI (oder PC) nicht synchron.

Ich hab mal eine interessante Variante gesehen (glaube bei den BIS von Balluff wird das verwendet). Dort wurde ein Bit am Anfang des Datenbereiches und eines am Ende getoggelt, die Bits waren immer gleich. Also beide False oder beide True. Wenn man Daten emfängt, prüft man beide Bits. Sind die gleich, ist der komplette Datensatz übertragen, egal wo gestartet wurde und wo damit dann geendet. Erst wenn beide Bit gleich sind, liest man die Daten aus, dannach quittieren und weiter.

Oder man fügt zwischen Trigger und Lesen einen sicheren Zeitverzug ein, wobei mit dann die Variante von Maxl besser gefällt.


----------



## Maxl (11 August 2008)

Ralle schrieb:


> Ich hab mal eine interessante Variante gesehen (glaube bei den BIS von Balluff wird das verwendet). Dort wurde ein Bit am Anfang des Datenbereiches und eines am Ende getoggelt, die Bits waren immer gleich. Also beide False oder beide True. Wenn man Daten emfängt, prüft man beide Bits. Sind die gleich, ist der komplette Datensatz übertragen, egal wo gestartet wurde und wo damit dann geendet. Erst wenn beide Bit gleich sind, liest man die Daten aus, dannach quittieren und weiter.


Ich denke das ist nur möglich, wenn der Datenblock zusammenhängend ist - in dem Fall ist die Variante mit dem ARRAY OF INT besser. Außerdem weiß man bei Systemen wie Protool oder Flex ja nicht, in welcher Reihenfolge die Tags ausgelesen werden.


> Oder man fügt zwischen Trigger und Lesen einen sicheren Zeitverzug ein, wobei mit dann die Variante von Maxl besser gefällt.


es bleibt die Frage, ob das die "schnelle Prozessdatenerfassung" erlaubt.


----------



## Ralle (11 August 2008)

@maxl

Korrekt, ich war einfach mal davon ausgegangen, man legt das hintereinander in einen DB, vonr ein Bit, hinten ein Bit. Dann hat man wenigstens die Chance, aber ob es funktioniert, muß man auch da testen.


----------



## Larry Laffer (12 August 2008)

Hallo ihr Lieben,
das mit dem Bit (oder Wort) am Anfang und am Ende hat einen funktionellen Nachteil. Die Visu reagiert ja nur auf Wertänderungen. Hier ist es problematisch, den Aufruf des Scriptes an 2 Variablen festzumachen. Davon abgesehen ist es tatsächlich so, dass bei meinen Variablen, die auch jetzt schon dicht beieinander liegen, eine der "mittleren" Variablen nicht passt. Zu meinem großen Glück dient eine davon dann sogar noch zum identifizieren des Datansatzes (Prüfstation erzeugt Datensatz und Teilenummer - Laser ein paar Stationen weiter schreibt die Nummer auf das Teil).

Da wäre dann die Sache mit dem Vorschlag von Maxl schon etwas eleganter. Leider habe ich die Zeit für den doppelten Datenaustausch nicht. Es wird ca. alle 4 Sek. ein Teil gefertigt - mein Basistakt für die kommunikation mit der SPS ist 1 Sek. - ich habe jede Menge Tags, die mittlerweile alle wegen ihrer Abtastrate schon handverlesen sind.

Beim Durchlesen der Beschreibung (und in erster Linie durch Beobachten) bin ich dann auf die Array's und Kurven gekommen. Hier liegt mein Fokus allerdings schon auf der Kurve, da ich hier ein Triggerbit und eine dahinter liegende Funktion habe. Meine Kurvendaten werden (obwohl ich eine y=f(x)-Kurve habe) interessanterweise nie durchmischt.

Ich danke euch in jedem Fall für die Beteiligung.
Es ist für mich schon merkwürdig, dass es immer ich bin, der über solche Elementar-Probleme stösst. Ärgern kann ich mich darüber, dass es seitens der Hersteller (Siemens) nie Versuche gibt, so etwas zu beheben. Witzig finde ich, dass die angebliche Weiterentwicklung von ProTool (WinCCFlexibel) dieses Problem immer noch hat. Was ist denn dann in Flex weiterentwickelt worden (außer dass man dort einen Text hochkant stellen kann) ?

Liebe Grüße
LL


----------



## volker (12 August 2008)

ich hab den thread jetzt nur überflogen.

hast du schon mal an eine rezeptur gedacht?
die liefert dir einen rückgabewert wenn alle daten gelesen wurden.


----------



## Larry Laffer (12 August 2008)

Hallo Volker,
daran habe ich auch schon gedacht ... 
Der Haken dabei ist, dass diese sich zunächst auf der Festplatte ablegen will. Da meine Anwendung sowieso schon im Grenzbereich läuft, habe ich das wieder verworfen. Aus der Beschreibung geht auch nicht sicher hervor, ob mit "Synchronisierung der Daten" dasselbe gemeint ist, wie ich es mal mit "Konsistenz" beschrieben habe ...

Gruß
LL


----------



## afk (12 August 2008)

Larry Laffer schrieb:


> Ärgern kann ich mich darüber, dass es seitens der Hersteller (Siemens) nie Versuche gibt, so etwas zu beheben. Witzig finde ich, dass die angebliche Weiterentwicklung von ProTool (WinCCFlexibel) dieses Problem immer noch hat.


Ohne Siemens in Schutz nehmen zu wollen: Das liegt IMHO an Unzulänglichkeiten im darunterliegenden Kommunikationsprotokoll. Die Blockgröße der Datenübertragung wird bei der S7-Kommunikation ja durch die CPU auf ziemlich kleine Häppchen beschränkt, zu allem Übel dauert die Übertragung von einem Block auch noch relativ lange (je nach Übertragungsweg und Hardware, aber AFAIK mindestens > 5 ms), und als I-Tüpfelchen läuft die Kommunikation offensichtlich noch völlig asynchron zum SPS-Zyklus. Der Vorteil der S7-Kommunikation ist die Tatsache, daß die CPU das schon von alleine kann, also im SPS-Programm dafür nichts implementiert werden muß. Man kann einen PC einfach mit einer beliebigen S7-CPU verbinden und anfangen zu kommunizieren.

Um unter solchen Voraussetzungen Daten konsistent zu übertragen, muß auf jeden Fall auf beiden Seiten (SPS und PC) noch etwas dazugestrickt werden, in diesem Thread wurden dazu ja schon ein paar Lösungswege aufgezeigt. Dabei geht allerdings der erwähnte Vorteil der S7-Kommunikation verloren, da man bei diesem Kommunikationsprotokoll an derartige Mechanismen anscheinend nicht gedacht hat. 


Gruß Axel


----------



## Larry Laffer (12 August 2008)

Hallo Axel,
es hat auch keine Sinn Siemens in Schutz nehmen zu wollen. Ich hatte in einem vergangenem Leben einmal mit Intouch etwas in der Art gemacht. Dort war es kein Problem über den IO-Server mittels unterschiedlicher Zugriffe diese Konsistenz zu erreichen.

Aber auch für Siemens ist ja nicht wirklicxh ein Problem (siehe Array's oder Kurven). Welchen Unterschied macht es da, eine frei definierte Struktur zusammenhängend zu lesen ?

Egal ... über den jetzt von mir angewendeten Haken-Trick komme ich ja erstmal weiter ...

Gruß
LL


----------



## JesperMP (12 August 2008)

Hallo LL.

Du hast vermutlich ein Variabel das den Skript über wertänderung startet.
Und diese Variabel ist vielleicht das erste Wort in den DB wo alle die Daten liegen ?
Dann erhaltest Du das Problem, dass Du bereits gesehen hast.

Einge gaaanz einfache lösung ist diese Variabel am Ende des DB zu plazieren !
Wenn Protool RT merkt das den Wert geändert ist, und den Skript startet, sind alle die Daten aktuell.


----------



## Larry Laffer (12 August 2008)

Hallo Jesper,
... leider nicht ... wäre aber schön gewesen.
Um das Script anzustossen benutze ich ein Wort, dass bei jedem neuen Daten-Block um 1 erhöht wird. Dieses Wort steht hinter allen anderen, die zu dem Block gehören ...
Es wird aber (glaube ich) der DB nicht als Einheit gelesen, sondern dessen Inhalte werden als Einzel-Einheiten (zumindestens bei unterschiedlichen Typen - REAL, INT, DINT, BOOL) geladen - auch wenn sie unmittelbar aufeinander folgen ...

Gruß
LL


----------



## JesperMP (12 August 2008)

Bei mir ist es so das alle die "Nutzdaten" in ein Array-Tag gesammelt sind.
Dabei wird u.a. sichergestellt das alle daten auf einmal gelesen wird.
Das "wertänderungs"-tag ist nicht innerhalb diese Array-Tag, aber liegt als das erste nach den Array-Tag.
Aber mit Array-Tags ist es entweder-oder. Nur INTs, DINTs, REALs usw. Nicht gemisscht.


----------



## Larry Laffer (12 August 2008)

... jetzt habe ich es verstanden ...
Ja, so wie du es vorschlägst habe ich es auch vor (ungefähr). Da ich parallel auch eine Kurve mit aufzeichne, will ich es (das Daten-Array) dem ProTool als Kurve verkaufen ... Dann habe ich hoffentlich alles zusammen (Sammelbit der Kurven-Übertragung).

Gruß
LL


----------



## afk (12 August 2008)

Larry Laffer schrieb:


> Ich hatte in einem vergangenem Leben einmal mit Intouch etwas in der Art gemacht. Dort war es kein Problem über den IO-Server mittels unterschiedlicher Zugriffe diese Konsistenz zu erreichen.


Das interessiert mich jetzt aber schon. Welche unterschiedlichen Zugriffe waren da denn hilfreich, um die Konsistenz herzustellen ?

Wir haben hier im Laufe der Jahre schon einige Visu-Systeme im Einsatz gehabt, aber eines war allen gemeinsam: Ohne zusätzliche Unterstützung vom SPS-Programm (z.B. per Handshake) konnte man sich nie hundertprozentig drauf verlassen, daß ein größerer Datenblock der SPS jederzeit konsistent in der Datenbasis des PCs verfügbar ist.


Gruß Axel


----------



## Larry Laffer (12 August 2008)

Hallo Axel,

ich kann dir da jetzt (leider) nicht mit den korrekten Namen der Dinge aufwarten. Ich versuche es mal mit Synonymen :
Ich konnte mit InTouch (7.x) mittels des IO-Servers zur gleichen Steuerung mehrere Zugriffe anlegen (sogar mit unterschiedlichem Basistakt). Für jeden Zugriff (unter ProTool würde das vielleicht Steuerung heißen) gab es ein Systembit das sinngemäß hies "Transfer_Complete". Das hatte ich damals (vor ca. 7 Jahren) auch für eine ähnliche Aufgabenstellung gebraucht. Dieser "Transfer_Complete" war immer dann TRUE wenn alle Variablen des Zugriffs aktualisiert waren. Ich hatte das auch als Bedingung für das Speichern-Script hergenommen.

Wie das genau war müßte sich eigentlich über Wonderware herausbekommen lassen ...

Ich hoffe, ich konnte dir weiterhelfen ...

Gruß
LL


----------



## afk (13 August 2008)

Larry Laffer schrieb:


> Ich hoffe, ich konnte dir weiterhelfen ...


Einen akuten Problemfall hab ich ja nicht, bin nur neugierig ... 

Wir setzen ja Intouch auch gar nicht mehr ein, aber das Thema S7-Kommunikation interessiert mich, seit ich mich recht intensiv mit libnodave auseinandergesetzt habe, um meine Delphi-Komponente dafür zu entwickeln. Seit einigen Jahren setzen wir zur Kommunikation mit der SPS auch einen eigenen OPC-Server ein, den ich ebenfalls auf der Basis von libnodave entwickelt habe.

Was den von Dir beschriebenen Fall angeht, bin ich immer noch skeptisch. Wenn der IO-Server von Intouch mit der S7-Kommunikation arbeitet, dann kann er AFAIK nur melden, daß er alle Daten einmal komplett von der CPU gelesen hat. Ob die Daten konsistent sind, hängt aber IMHO zusätzlich davon ab, was die CPU mit den gelesenen Daten zur gleichen Zeit gemacht hat. Und da die S7-Kommunikation völlig asynchron zum CPU-Zyklus abläuft (jedenfalls soweit ich das beurteilen kann), liegt genau da der Hund begraben. 

Nehmen wir mal an, Du willst von einer 300er CPU einen zusammenhängenden Block von 400 Bytes lesen. Das muß dann in zwei Anfragen aufgeteilt werden, da die 300er nur gut 200 Bytes auf einmal liefern kann. Also werden die ersten 200 Bytes angefordert, und bei einer flotten Verbindung nach etwa 10 ms von der CPU geliefert. Währenddessen läuft das SPS-Programm ja weiter und manipuliert jetzt den gesamten Block von 400 Bytes (z.B. per Blockmove). Dann kommt vom PC die Anforderung für die nächsten 200 Bytes, dabei werden aber schon die neuen Daten gelesen. Sobald die von der SPS geliefert wurden, ist der PC der Meinung, er hat jetzt alle Daten vollständig gelesen, aber das was er hat stand so nie (am Stück) in der SPS. 

Umgekehrt kann es genausogut passieren, daß die SPS gerade angefangen hat, die Daten zu verändern, und dann vom PC währenddessen ein halb bearbeiteter Datenbereich gelesen wird, da das Lesen ja mitten im SPS-Zyklus erfolgen kann.

Mich interessiert nun, ob solche Fälle vermieden werden können, ohne im SPS-Programm irgendeinen Mechanismus zum Sicherstellen der Konsistenz implementieren zu müssen (Handshake oder ähnliches).


Gruß Axel


----------



## vierlagig (13 August 2008)

afk schrieb:


> Mich interessiert nun, ob solche Fälle vermieden werden können, ohne im SPS-Programm irgendeinen Mechanismus zum Sicherstellen der Konsistenz implementieren zu müssen (Handshake oder ähnliches).
> 
> 
> Gruß Axel



gute nacht axel, 

ich glaube nicht daran, dass es möglich ist konsistente datensätze ohne einwirkungen/überprüfungen der gegenstelle zu übertragen. das problem welches sich stellt ist, wie du in deinem beitrag richtig bemerkt hast, dass die CPU nicht aufhört zu arbeiten und die abgefragten datensätze zu beeinflußen. IMHO ist es nur möglich konsistent zu lesen und zu schreiben, wenn das ziel- bzw. quellsystem nicht darüber informiert ist, dass gerade jemand mit geringerer lese-/schreib-zeit zugreift und die daten bitte schön erst nach erfolgreicher übertragung zu verwenden sind. dazu bedarf es kommunikation àla "daten gelesen?" - "jopp - daten gelesen!" ... leider ist es so, aber für alles andere müßte eine zyklusgenaue kommunikation zustande gebracht werden...

gruß
4L


----------



## Larry Laffer (13 August 2008)

afk schrieb:


> Was den von Dir beschriebenen Fall angeht ...


 
Hallo Axel,
bezüglich der Kommunikation mit der SPS hast du sicher Recht. So tief (wie du) stecke ich da auch nicht drin. Der von dir beschriebene Fall ist sicherlich auch etwas, das sich so gar nicht relaisieren läßt. So gesehen ist "Konsistenz" da auch gar nicht zu Erreichen. 
Für mich war (und ist) interessant, dass ich weiß, wann alle interessanten Variablen ab Trigger-Zeitpunkt zur Visu aktualisiert worden sind. In meinem Programm entsteht an dieser Stelle schon funktionsbedingt eine Wartezeit in der die Variablen-Inhalte sich nicht mehr ändern (Ablauf starten - Messwerte aufnehmen - Messwerte zur Visu und parallel nächsten Ablauf vorbereiten). Um den Vorgang abzusichern habe ich (aktuell) auch noch einen Handshake (Visu setzt Bestätigung - ohne Bestätigung geht es nicht weiter) mit eingebaut.

Gruß
LL


----------



## JesperMP (13 August 2008)

Eine weitere möglicheit wäre Send/Receive anstatt polling zu verwenden.
Dies geht bei Flexible/Protool nur mit OPC.
Mit Flexible _glaube _ich das es geht ein "normalen" S7 verbindung, und gleichzeitig ein OPC verbindung zu projektieren. Dies geht nicht mit Protool. Und mit Flexible PC RT bekommt man Simatic Softnet IE Lean womit man ein OPC verbindung realisieren kann. Also, mit Flexible in verbindung mit Ethernet kostet es nicht mehr.


----------



## Larry Laffer (13 August 2008)

JesperMP schrieb:


> Mit Flexible _glaube _ich das es geht ein "normalen" S7 verbindung, und gleichzeitig ein OPC verbindung zu projektieren.


 
Hallo Jesper,
das ist im Augenblick keine Option - interessiert mich aber trotzdem.
Kann man (wie ?) eine zusätzliche OPC-Verbindung zu einer Runtime projektieren ? Lassen wir Flex und ProTool dabei jetzt mal außer Acht ...

Gruß
LL


----------



## JesperMP (13 August 2008)

Habe probiert ein PC Station mit IE General + WinCC Flex RT + OPC Server einzurichten.
Dann kan man die zwei verbindungsarten parallel projektieren.
Und man kann OPC Items über Send/Recieve projektieren. Siehe Anhang.

Leider "kostet" Send/Receive ein CP343-1. 
In die Zukunft werde ich ausschließlich die Onboard PN Schnittstelle verwenden.
Also werde ich das Trick verwenden, das Wertänderungs-Tag nach die Nutzdaten zu stecken.


----------



## Larry Laffer (14 August 2008)

Hallo Jesper,
dein Beispiel zeigt im Prinzip so etwas ähnliches, wie ich es schon vorher beschrieben habe. Du hast einen 2. Zugriffsweg "gebaut", den du eigenständig behandeln kannst. Sobald ich wieder "etwas Luft habe" werde ich mich damit mal auseinandersetzen. Mal sehen, was sich damit anstellen läßt.

Danke auf jeden Fall schon einmal ...

Gruß
LL


----------



## xhasx (17 August 2008)

Bin jetzt auch nur drübergeflogen...

Wie wär's mit nem Bildbaustein - klingt auf Anhieb komisch aber dem kannst du eine Struktur zuweisen und ja deine Werte übergeben. Der BB ist quasi die HMI --> SPS Schnittstellen. Hab mal sowas in Klein gemacht um Daten zu übertragen. Das einzige was du brauchst ist einen Refresh Takt für das Skript im BB.


----------



## Larry Laffer (18 August 2008)

xhasx schrieb:


> Bin jetzt auch nur drübergeflogen....


 
Schade ...
Bildbausteine gibt es in ProTool nicht und ich bezweifle (nach vorliegenden Erkenntnissen) auch, dass das (bei Anwendung von Flex) etwas bringen würde ...

Gruß
LL


----------



## xhasx (18 August 2008)

Sorry, hab das mit Protool nicht beachtet. Stimmt, da gab's keine BB's.
Aber bis auf den Umstand mit dem Refresh funktioniert das in Wcf einwandfrei!!!


----------



## schlarpi (10 September 2008)

xhasx schrieb:


> Bin jetzt auch nur drübergeflogen...
> 
> Wie wär's mit nem Bildbaustein - klingt auf Anhieb komisch aber dem kannst du eine Struktur zuweisen und ja deine Werte übergeben. Der BB ist quasi die HMI --> SPS Schnittstellen. Hab mal sowas in Klein gemacht um Daten zu übertragen. Das einzige was du brauchst ist einen Refresh Takt für das Skript im BB.


 

Auch ein intressanter Ansatz....

Selber habe ich es mit einer "TriggerVariable" gelöst, in deren Ereignis bei Wertänderung der Befehl AktualisiereVariable aufgerufen wird. Bei Array hat es bei mir nicht funktioniert. --> Jede Variable einzeln und am schluss der Skrpit für die Speicherung. 

Funktioniert irgendwie, bin aber nicht wirklich glücklich damit.

Beni


----------



## Larry Laffer (10 September 2008)

@Schlarpi:
Das mit der Triggervariablen (ähnlich wie bei dir) war mein Ansatz bisher. Das hat, wie ich schon geschrieben habe auch meißtens funktioniert, aber nicht zuverlässig. Ich mache es nun über eine Kurve und habe seit dem keine Probleme mehr mit nicht passenden Variablen-Inhalten ...

Gruß
LL


----------

