Step 7 SCL - Timerproblem innerhalb einer While-Schleife

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Volker,

ich habe den Baustein noch etwas angepasst (z.B. im Ziel - DB die Adressen nicht hochzählen lassen) und es funktioniert hervorragend, wenn ich den M100.0 dauerhaft auf "true" belasse. Um jedoch das Füllen der Tabelle bei 20 Einträgen zu stoppen, hatte ich folgendes eingefügt:

U DB500.DBX4.3 (Start Button in der Visu)
FP M100.2
S M100.0


Hier beginnt Dein Code
U M100.0
U T2
...

Am Schluss, wo der Schleifenzähler nach 20 Durchläufen wieder 1 gesetzt wird, hatte ich nachfolgend den M100.0 wieder rückgesetzt (R M100.0).


L 1
T DB10.DBW 8
R M100.0

Seltsamerweise beginnt nun die Übertragung in die Tabelle bei jedem Klick auf den Start Button in der Visu nicht immer mit dem ersten Datensatz aus dem DB, sondern willkührlich mal beim ersten, dann wieder beim dritten, dann beim 5ten, dann wieder mal richtig, etc. Dieses Verhalten verstehe ich nicht, denn wenn ich in der Variablentabelle den M100.0 auf true setze, dann ist alles OK, erledige ich das auf die oben beschriebene Art, dann gibt es die Aussetzer.


Was könnte das sein?
BG Ralf
 
Benutzt du den M100.0 noch irgendwo anders im Programm?
Wenn er über die Variablentabelle dauerhaft gesetzt ist könnte das Problem daher kommen, dass er vor dem Programm nicht gesetzt ist, oder danach.

Versuch mal den Abschnitt
Code:
[COLOR=#ff0000]
U    DB500.DBX4.3 (Start Button in der Visu)
FP M100.2
S     M100.0[/COLOR]
vor dem Aufruf des Bausteins einzubauen. So ist er gesetzt wenn er in den Baustein geht.

Nach dem Baustein setzt du das hier in einem neuen Netzwerk ein
Code:
L DB10.DBW 8
L 1
==I
R M100.0

So ist der Merker gesetzt bevor der Baustein aufgerufen wird.
Zum testen könntest du dann das Netzwerk danach auskommentieren und den Merker über mehrere Zyklen aktiv lassen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zombie:

Benutzt du den M100.0 noch irgendwo anders im Programm?

Nein, ich prüfe das immer akribisch über die Referenzdaten, dass nie irgendeine Doppelbelegung auftritt.

Deine Idee ist eine gute Kontrolle, dass auch wirklich die gewünschten Zustände anliegen, bevor es in den Baustein selbst geht, hat aber leider auch nichts gebracht. Der Grund ist, wie ich jetzt durch Testen herausfand, ein Zeitproblem beim Datenaustausch mit der Visu auf dem PC, obwohl der OPC eine Zykluszeit von 100ms und der interne Visu-OPC-Koppelbaustein (auf dem PC) inzwischen sogar auf 10ms steht.

Den im Baustein vorhandenen Timer im NW1 hatte ich gestern drastisch reduziert, damit sich die Tabelle flott füllt. Ergebnis: Aussetzer ohne Ende.
Nun bin ich wieder bei 1 Sekunde und es treten keine Aussetzer mehr auf.

20 Sekunden für eine Tabelle füllen, dass sieht echt nach Hightech 2020 aus ;) ... oder eher nach einer Meditations-Visu für ein buddhistisches Kloster. :)

BG Ralf
 
Moin Ralf!

Habe diesen Thread jetzt mehrmals gelesen und weiss immer noch nicht sicher, was Du umsetzen willst.
Klar geworden ist mir, dass für eine Visualisierung per Start-Button das Umschaufeln von 20 formal gleichen DatenGruppen angefordert/gestartet werden soll.
Klar ist auch, dass Du Pausen einstreuen willst, weil sich sonst irgendetwas verschluckt - sei's die Visualisierung oder sei's der Transport der Daten dorthin - egal.
Was mir nicht klar geworden ist, weil ich verschiedene Versionen aus den diversen Texten und der Grafik herauslese, ist:
Wann sollen die Pausen eingefügt werden?
1. nach jedem Umschaufeln 1 DatenGruppe oder
2. nach dem Umschaufeln von 20 DatenGruppen oder
3. nach dem Umschaufeln von n aus 20 DatenGruppen?
Ferner: was passiert nachdem alle 20 DatenGruppen umgeschaufelt wurden? Nichts, bis wieder per Start-Button neu gestartet wird?

Die Diskussion, ob besser eine For- oder While-Schleife verwendet wird, finde ich müßig. Ebenso dürfte das erfolgreiche Starten und Abfragen eines Timers nicht wirklich zum unüberwindlichen Hindernis werden.

Wenn 2. Deinen Vorstellungen entspricht, dann verstehe ich nicht, warum ein Starten bzw. Abfragen des Timers überhaupt in die Schleife integriert werden soll. Schleife 20mal durchlaufen lassen und nach Verlassen der Schleife den Timer starten.

Wenn 1. Deinen Vorstellungen entspricht, dann "Deine" Schleife in die Tonne treten und durch ein Konstrukt ersetzen, das letztlich auch eine Abarbeitung in einer Schleife darstellt, aber unter Ausnutzung der zyklischen Abarbeitung des Programms. Dazu benötigst Du nur eine INT-Variable als Schleifenzähler, die Du selbst von Mal zu Mal um 1 inkrementierst. Das Berechnen der "Datensatzadressen aus dem Schleifenzähler entsprechend mehrerer Formeln" hast Du ja schon erfolgreich realisiert und angewendet. Ob Dein Schleifenzähler nun von 0 bis 19 oder von 1 bis 20 zählt - Du wirst es schon schaffen, nach Erreichen des HöchstStandes zum Start des nächsten Durchlaufs den entsprechenden AnfangsWert zu berechnen.
Also:
Wenn Timer läuft, Rest des Bausteins überspringen
Wenn SchleifenZähler grösser als 19 (bzw. 20?) und kein Start-Button, dann Rest des Bausteins überspringen
Wenn SchleifenZähler grösser als 19 (bzw. 20?) und Start-Button, dann SchleifenZähler auf.0 (bzw. 1?) setzen
1 DatenGruppe entsprechend Schleifenzähler und DatensatzadressBerechnung umschaufeln
Schleifenzähler inkrementieren
Timer starten

Wenn 3. Deinen Vorstellungen entspricht, dann überlegen, ob obige Lösung nicht genauso gut verwendet werden kann - immerhin wolltest Du die Pausen von z.Z. 1s ohnehin noch verkürzen.

Gruss, Heinileini
 
Moin Heinileini,

auch Dir Danke für Deinen Beitrag. Lese ihn leider erst jetzt.

Es trifft Variante 1: nach jedem Umschaufeln 1 DatenGruppe zu.

Ich habe das Problem durch Nutzung eines Taktmerker-Bits gelöst und mit einem Handshake aus der PC-Visualisierung.
Kommt das Handshake nicht, dann springe ich an das Ende des Bausteins
.

Beste Grüße,
Ralf
 
Zurück
Oben