Datenbereich konsistent lesen

Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
Zum Vergrößern anklicken....
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. :rolleyes:


Gruß Axel
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... 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
 
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.
Zum Vergrößern anklicken....
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
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Larry Laffer schrieb:
Ich hoffe, ich konnte dir weiterhelfen ...
Zum Vergrößern anklicken....
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
 
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
Zum Vergrößern anklicken....

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
 
Zuletzt bearbeitet:
afk schrieb:
Was den von Dir beschriebenen Fall angeht ...
Zum Vergrößern anklicken....

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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
JesperMP schrieb:
Mit Flexible glaube ich das es geht ein "normalen" S7 verbindung, und gleichzeitig ein OPC verbindung zu projektieren.
Zum Vergrößern anklicken....

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
 
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.
 

Anhänge

  • WinCCFlex_SR_data.GIF
    WinCCFlex_SR_data.GIF
    26 KB · Aufrufe: 23
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
Zurück
Oben