Datenbereich konsistent lesen

Larry Laffer

Super-Moderator , User des Jahres 2008-2009
Teammitglied
Beiträge
14.426
Reaktionspunkte
3.282
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
??????????

:D
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

Hallo LL :D,
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
:D

Hallo LL :D,
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

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

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

Eine andere Lösung gibt es leider nicht

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

Gruß
LL
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
Zuletzt bearbeitet:
... 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 ...
 
@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 :cool:.

@LL

Leider ist mir dazu auch nichts bekannt :confused:.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
:confused: ... 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 ...
 
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?
 
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 ...

...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 ...
 
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
 
@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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zuletzt bearbeitet:
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.
 
@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.
 
Zurück
Oben