mehrer Datenwerte im DB speichern & schieben

costa

Level-1
Beiträge
30
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
meine ausgelesene Gesamtmenge möchte ich jeden Tag um 24:00 Uhr abspeichern. Vieleicht mit einem Schieberegister!
Die Gesamtmenge setzt sich aus 3 real Zahlen zusammen (Hunderter, Tausender, Mill.) die ich alle in einem DB haben möchte. Das aktuelle Datum sollte auch noch hinzu kommen. Am besten alle hintereinander.

Nun habe ich leider feststellen müssen, das der FC 91 (Siemens- Word Schift Register) immer nur einen wert um eine adresse vorschieben kann.
Auserdem bekomme ich es nicht hin alle Werte in einem DB abzuspeichern. Versuche ich z.B den zeiten Wert in einem anderren adressbereich des DB´s zu speichern wird dort nicht mehr verschoben.
Veileicht hat jemand eine idea.
 
meine ausgelesene Gesamtmenge möchte ich jeden Tag um 24:00 Uhr abspeichern. Vieleicht mit einem Schieberegister!
Die Gesamtmenge setzt sich aus 3 real Zahlen zusammen (Hunderter, Tausender, Mill.) die ich alle in einem DB haben möchte. Das aktuelle Datum sollte auch noch hinzu kommen. Am besten alle hintereinander.

Dann gehe ich davon aus, dass du n mal die oben aufgezeichnete Struktur in einem Datenbaustein abspeichern willst, wobei mir aber nicht klar ist, warum du das REAL-Format wählst, aber das wird schließlich deine Sache sein.

Für die Problemlösung gibt es zwei prinzipielle Möglichkeiten:
a) du schiebst die Werte tatsächlich durch den Datenbaustein hindurch, oder
b) du verwendest den Mechanismus des Ringspeichers, dabei werden die Daten nach der Ablage im Datenbaustein nicht mehr bewegt.

Ich persönlich bevorzuge die zweite Art, da dies einem Grundsatz entspricht, die Daten nur zu bewegen, wenn es sich nicht vermeiden lässt.

1. Wenn man eine Struktur mit Elementen hat, die auf unterschiedlichen Datenformaten basieren, legt man zweckmäßig ein UDT-Definition der gewünschten Struktur an.
2. Es wird ein Datenbaustein eingerichtet, dessen erstes Element einen Index vom Typ INT aufnehmen soll.
3. Hiernach werden n mal die Struktur gemäß Punkt 1 (AWL-Lösung) oder besser gleich ein Array mit n Elementen der Struktur gemäß Punkt 1 (SCL-Lösung)eingetragen.
4. Der Index muss zum gegebenen Zeitpunkt mit n oder n-1 initialisiert werden. Warum, das hängt ganz von persönlichen Vorlieben ab. Die nachfolgende Beschreibung stellt darauf ab, dass der Index gemäß Punkt 2 von 1 bis n läuft.

Wenn man weiter in AWL programmieren will, sollte man die Anwendung der Adressregister AR1 oder AR2 beherrschen, es geht auch ohne, ist aber weniger elegant. Der Wert des Indexregisters wird immer mit dem zuletzt geschriebenen Datensatz assoziiert. Soll um 24:00 Uhr ein neuer Datensatz gespeichert werden, so muss zunächst der Index um 1 inkrementiert werden. Ist dabei der Wert größer als n, so wird der Wert des Index auf 1 gesetzt. Über den Index wird dann die Adresse (Pointer) des Speicherortes bestimmt, der den neuen Datensatz aufnehmen soll, diese wird dann in das Adressregister AR1 eingetragen. Jetzt kann man bequem mit simplen Lade und Transferbefehlen die Daten übernehmen:

L Hunderter
T DBR [AR1, P#0.0]
L Tausender
T DBR [AR1, P#4.0]
usw.usf.

Wenn man mit SCL programmieren will, ergeben sich elegantere Möglichkeiten. Aber aufpassen beim Wert des Indexes für die Indizierung eines Arrayelementes, die laufen dann von 0 bis n-1!!! In meinem Beispiel läuft der Index "neu" von 1 bis n.

neu := neu + 1; // neu ist der Index auf den nächsten Datensatz
IF (neu > n) THEN neu := 1; END_IF;

Für das Speichern in das 0-te Element hat also "neu" den Wert 1!

Mengendaten.Satz[neu - 1].Hunderter := Hunderter;
Mengendaten.Satz[neu - 1].Tausender := Tausender;

That's all! Zum Lesen der Daten kann man ähnlich verfahren.

Die Klammerung in der IF-Abfrage ist nicht vorgeschrieben, sie macht aber ein Programm lesbarer, in der Hochsprache C ist dagegen die Klammer strikt vorgeschrieben, was auch einen Sinn ergibt. Für mich ist es jedenfalls unverständlich, warum man in einer modernen Zeit das SCL in Anlehnung an Pascal entwickelt hat, C würde ein besseres Konzept ergeben und insgesamt weniger Tipparbeit bedeuten. Na ja, wer auch immer das verbrochen hat! Interessant ist es jedenfalls sehr oft, was der SCL-Compiler an MC7-Code zusammenbastelt, mit ein paar Tricks kann man sich den Code in AWL anschauen und sehr oft ergreift mich das Grausen - aber das steht auf einem anderen Blatt.

Zum Abschluß: das war nur der Anriß von möglichen Lösungswegen und wie immer, es führen viele Wege nach R.... ;-)

Gruß Barnee
 
@Volker

Hatte ich nicht gescheckt, das Costa das Thema schon an anderer Stelle angewärmt hatte. Liegt wohl an der Grippe, die mich i.A. plagt.

Aber mal trotzdem eine Frage an dich, was macht ein System besser, wenn es nutzlos Daten durch die Gegend schiebt? Wenn ich das richtig vestanden habe, kopiert man die Quelldaten zuerst einmal in einen Zwischen-DB, dann schiebt der FC98 alle bisher gespeicherten Blöcke ein weiteres mal durch die Gegend? Und wenn der FC98 den zuletzt eingefügen Block verschoben hat, erst dann kopiert er die Quelldaten aus dem Zwischen-DB in den Ziel-DB?

Darüber sollte man mal nachdenken, was das teuer kostet! Die Daten werden doch durch das Schieben nicht besser oder schlechter! Also warum läßt man sie nicht an dem Platz, wo sie das erste Mal hätten eingeparkt werden könnten? Jetzt versteh ich auch das Wort von der Bitbumserei ;-) Verzeih mir den Scherz.

Aber mich würden die Beweggründe interessieren, warum die Daten tatsächlich verschoben werden sollten anstatt nur einen Zeiger zu verbiegen.

Gruß Barnee
 
@barnee
ist doch nicht deine schuld wenn costa das thema ein weiters mal hereinstellt. die waatsche bekommt dann costa. ;-)
----------------------------------------------------------------

das ganze kann man aus mehreren richtungen angehen.

nehmen wir mal ein einfaches beispiel.
ich habe eine anlage mit 10 becken hintereinander. +beladestation.(z.b. datenlänge pro becken = 10 Byte)


die beladestaion enthält nun ein neues gestell mit teilen (quelldatenblock).
im ziel-db liegen alle datenblöcke der 10 becken.
jedes becken hat eine absolute adresse im ziel-db.
becken1 von 0-9
becken2 von 10-19
usw.

sobald die gestelle in das nachste becken verschoben werden, müssen auch die daten geschoben werden.
und zwar von hinten nach vorne, da ja datenfach1 noch daten enthält die noch nach becken2 müssen.

es werden die daten von becken9 in becken10 kopiert. (becken10 ist ja nun raus und in der entnahme)
becken8 wird nach becken9 kopiert, usw.
am ende ist nun fach1 bereit für die aufnahme der neuen daten. der quelldatenblock wird nach zielblock1 kopiert

ab hier dann wieder von vorn. ;-)
-----------------------------------------------------------------

das kann man natürlich auch ganz anders aufziehen.

unser service kommt auf jeden fall besser damit zurecht,
wenn man sich das auch noch 'plastisch' vorstellen kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Volker

Ja, du hast mir nun erklärt, was du z.B. machen würdest. Ich hab auch verstanden, dass du eure Serviceleute nicht überfordern möchtest. Alles bei mir angekommen. Aber echte Beweggründe habe ich da noch nicht erkennen können.

Ich gehe mal davon aus, das bei der von geschilderten Anwendung (Galvanik?? hab ich recht??) nur eine Handvoll Daten anfällt und diese auch noch auf einem HMI nach dem Motto "nice to have it" dargestellt werden, joa, dann ließe sich mit mir darüber verhandeln, dieses vielleicht mit einem Schieberegister zu machen.

Ich unterstelle mal die Galvanik (10 Becken in Folge!!!) einheitliche Taktrate, bei konstanter Verweildauer (denn sonst könnte man ein Schieberegister nicht anwenden), keine Bindung der Daten an Sollvorgaben in den einzelnen Becken (oder vielleicht doch? aber selbst dann) und am Ende der Kette werden die Daten beerdigt. Ok, jeder Beerdigungsunternehmer hat seine Vorstellung, die Leute unter die Erde zu bringen. Nachfolgend meine abstrakte Sicht eines Beispiels.

Es stehen verschiedene Vorprodukte zur Verfügung, deren Eigenschaften mit den 8 Klassen E1...E8 beschrieben werden können. Die Identifikation des Vorproduktes erfolgt mit 3 Identnummern K1...K3. Die Produktionsvorschrift wird über die Kennung PV ermittelt. Der Datensatz einer Produktionsvorschrift besteht aus etwa 45 Kenndaten. In der Produktionsanlage kann sich maximal 1 Produkt befinden, jedoch in der Übergangsphase sind es 2 Produkte. Der Behandlungsteil der Produktionsanlage teilt sich in 20 Abschnitte auf. Für jeden Abschnitt existiert ein Datensatz an Sollwerten, wobei je nach Produktionsvorschrift die Anzahl der Sollwerte variieren kann, deshalb wird der Speicher zum Ablegen der Sollwerte zur Laufzeit dynamisch allociert, pro Abschnitt sind durchschnittlich etwa 20 Sollwerte zu hinterlegen. Der Einlaufbereich der Produktionsanlage dient zur Ablage von 6 Vorprodukten und im Auslaufbereich können sich maximal 3 Fertigprodukte befinden. Für den Einlaufbereich besteht eine Optimierungsvorschrift, so dass die Vorprodukte in optimaler Reihenfolge gereiht werden. Der Produktdurchlauf erfolgt kontinuierlich, d.h. wenn die Behandlung eines Produktes beendet ist, erfolgt unverzüglich die Bearbeitung des folgenden Produktes, dadurch ergeben sich 20 Übergangsphasen, wenn der Produktwechsel in den Abschnitten der Produktionsanlage durchgeführt wird.

Tolle Aufgabe, nicht wahr? Rechnen wir mal überschlägig zusammen: Je Produkt kommen etwa 460 Datenpunkte zusammen. Es können sich maximal 9 Produkte in der Anlage befinden, das macht rund etwa 4140 Datenpunkte. Und die schieben wir jetzt lustig durch die Gegend? Doch was tun wir z.B. wenn sich in den Abschnitten 7 bis 20 das Produkt A befindet gefolgt von dem Produkt B in den Abschnitten 1 bis 7? Ja das ist es, in jedem Abschnitt ist der Produktwechsel zu berücksichtigen, in dem das Produkt A sich noch in einem Abschnitt befindet, während das Produkt B schon in den selbigen Abschnitt eintritt. Das was bei den Galvanikkörben sich selektiv auf immer nur 1 Produkt bezieht, kann bei dieser Aufgabe nicht angewendet werden.

Wie wird eine solche Aufgabe gelöst? Ganz einfach! Erst einmal wird KEIN Gedanke daran verschwendet, wie man die Lösung durch Verwendung von Schieberegistern herbeiführen könnte! Nachdem das vom Tisch ist, wird systematisch ein Speicherbereich angelegt, der 10 PD-Sätze der Daten speichern kann, die für die Vorprodukte immer angewendet werden müssen. In diese PD-Daten eingearbeitet sind auch die Speicherstellen für Pointer, die auf dynamisch angelegte Datensätze verweisen. Die PD-Sätze sind mit einander verkettet, d.h. von einem aktuellen PD-Satz kann man auch auf den vorhergehenden bzw. auf den nachfolgenden PD-Satz zugreifen. Dann wird ein Ringpuffer angelegt, der 10 Pointer aufnehmen kann, jeder Pointer zeigt auf einen PD-Satz. Zum Abschluß wird eine zentrale Index-Variable angelegt, die exakt den Pointer indiziert, der auf den PD-Satz des Produktes verweist, das als letztes in den Behandlungsteil der Produktionsanlage eingetreten ist. Jetzt brauchen wir nur noch einem Behandlungsabschnitt mitzuteilen, ob er sich im kontinuierlichen Modus oder in einer Umstellungsphase befindet, das ist aber keine große Kunst. Über die zentrale Index-Variable kann jede Methode des betreffenden Behandlungsabschnitt sich die Daten des aktuellen und des nachfolgenden Produktes holen und in der Abwägung dieser Daten einen Umstellungsprozess ausführen. Mit dieser Methode werden NIE Daten durch die Gegend verschoben, es würde keinen Sinn ergeben, die Daten zu verschieben, weil dies leicht zu Inkonsistenzen führen kann. Spätestens dann, wenn man die Produktionsanlage erweitern will, wird man die Vorteile eines statischen Speichermodells erkennen. Ach ja, und wenn das Produkt den Behandlungsteil zur Gänze verlassen hat, dann wir einfach die zentrale Index-Variable inkrementiert und schwups das war's.

Zu abstrakt? Oder unrealistisch? Das Verfahren wird z.B. angewendet in kontinuierlichen Verzinkungsanlagen zur Herstellung von Automobilblechen.

Gruß Barnee
 
nein nicht zu abstrakt. :wink: ich habe ähnliches dann auch so wie du gelöst. ich schreibe ein programm so das es den anforderungen bestmöglich entspricht.

ich behaupte ja auch gar nicht, dass das mit dem schieberegister das non plus ultra ist. und auch nur anwendbar wenn alles hintereinander liegt.
das mit der beize hab ich schon mal angewendet. s5 115u. waren 26 becken. die datenmenge hielt sich aber in grenzen. waren nur 10 dw's.
das ganze wurde aber auf einem mp370 visualisiert. mit zeigern geht das dann nicht so ohne weiteres.
 
@Volker

Na, ist schon klar. Das ist so wie mit den Kanonenkugeln und den Spatzen oder so ähnlich :wink: Zu S5-Zeiten waren meine kleinsten Maschinen allenfalls eine 135U sonst meistens ne 155U. Heute ist es meistens eine 400er, selten eine 300er. Schade ist nur, das die HMIs meistens so störisch sind und nur auf festverdrahtete Datenpunkte abfahren, bei einem statischen Speichemodell muß man dann halt nach dem "Datenschieben" für die HMI-Anzeigen einen Kopiervorgang einfügen. Wenn aber nur eine handvoll Daten vorliegen, dann muß man abwägen, welche Lösung man wählt.

Gruß Barnee
 
Zurück
Oben