Unterschiedliches Verhalten Bool Switch in Tile Visu zu Webfront

Hallo,

ich habe Unterschiede vom Wf zur Tile Visu festgestellt.
Anmerkung: Das Verhalten war auch schon in der V 7.2.

Ich Schalte einen Switch aus der Visu auf eine Modbusinstanz, ich habe in der Modbusinstanz getrennte Lese und Schreibadressen.
Im Webront wartet der Switch schön bis die Leseadresse true liefert, wird dann grün.
In der Tile Visu, wird der Schalter sofort gelb (also aktiv) dann sofort wieder neutral, bis dann letztendlich die Leseadresse true liefert, dann wird der Switch wieder gelb leuchtend.

Das ganze kann ich verhindern, indem ich den Abfragezyklus (Modbus) der SPS auf 100ms verkürze, dass belastet aber mein Netzwerk stark.

Also irgendwas ist also anders, weil im Webfront funktioniert es ja.

Ich hoffe ich habe es gut genug beschrieben.

grafik

grafik

Im Prinzip bestätigt die Visu deine Schaltung direkt, indem sie den Schalter direkt beim Klicken aktualisiert. Sollte dann, wieder erwarten, nach kurzer Zeit die echte Änderung nicht kommen, dann geht der Schalter wieder auf den vorherigen Wert zurück. Und das passiert bei dir halt. Der Schalter wechselt bei Klick, es folgt aber (erst einmal) keine Rückmeldung mit dem neuen Wert, daher wechselt er zurück auf inaktiv. Und dann kommt die Meldung doch und der Schalter geht zurück auf aktiv.

Ja das verstehe ich, aber es haben doch viele Systeme winiger Rückmeldingszeit als 500ms, dann würde das ja in solch einen Fall immer kurz ausgehen.
Ist das so gewollt?
Das bestätigen eines Schaltvorgangs sollte doch entweder emuliert oder erst bei Änderung vom Status der Leseadresse, oder sehe ich das falsch…

1 „Gefällt mir“

@Dr.Niels
Kann man das nicht so machen wie im Webfront?

Von mir aus mit Spezialschalter.

Die Betätigungsanzeige (warte auf Rückmeldung) ist auch ganz nett, muss sich aber ansonsten DEUTLICH von einer echten Rückmeldung (An/Aus) unterscheiden. z.B. in dem der Schalter zu einem Ladekringel umgeformt wird.

PS: Gibt es eigentlich für die neue Visu auch noch einen EIN/AUS bei dem ich wiederholt ein (oder auch aus) senden kann, ohne dass ich Umschalten muss.

Initial hatten wir die Implementation ohne das kurze Emulieren und das sieht total mistig aus. Dann nimmt man einen Schieberegler und schiebt ihn von 20% auf 60% und lässt ihn los. Dann springt er einmal zurück auf 20% um kurz danach wieder auf 60% hochzuspringen. Daher hatten wir eine Überbrückungszeit eingebaut, damit das im Normalfall halt nicht passiert.

Klar, du kannst wie in der alten Visu gewohnt ja eine Aufzählung benutzen, da kann man dann auch immer wieder auf An klicken ohne zwischendurch auszuschalten.

Initial hatten wir die Implementation ohne das kurze Emulieren und das sieht total mistig aus. Dann nimmt man einen Schieberegler und schiebt ihn von 20% auf 60% und lässt ihn los. Dann springt er einmal zurück auf 20% um kurz danach wieder auf 60% hochzuspringen. Daher hatten wir eine Überbrückungszeit eingebaut, damit das im Normalfall halt nicht passiert.

@Dr.Niels
Stimmt das mit den Slidern ist jetzt behoben, und unter 7.0 war das mit den AN AUS bei Boolean Variablen nämlich noch nicht.
Meinst du ob es möglich ist, eine Unterscheidung zwischen Variablentypen einzubauen?
Also das die Verzögerungszeit bei den Slidern sprich (Float und Integer) aktiv ist und bei Boolean Variablen wenn die Rückleseadresse verwendet wird wird die Zeit nicht aktiv?
Somit könnte man wenn man keine Rückleseadresse hat auf (emulieren) stellen und mit mit Rückleseadresse wird auf die Antwort gewaretet, erst dann Statuswechsel in der Visu…

Das ist mir bei Variablen die ich über MQTT steuere auch schon aufgefallen.
Habe mir nichts dabei gedacht, aber die Zeit ist im alten Webfront definitiv höher.

1 „Gefällt mir“

Die Visualisierung weiß überhaupt nichts über die Konfiguration der Variablen, kann also nichts abhängig von Rücksendeadressen oder Emulationseinstellungen anders machen. Aktuell sehe ich auch nicht wirklich Ansätze um das eleganter zu lösen als bei zu langen Wartezeiten doch einmal auf den alten Wert zurückzuspringen.

Von was für Wartezeiten reden wir denn bei euch? Wir haben damals 500 ms eher „aus dem Bauch heraus“ gewählt, da könnte man natürlich noch finetunen.

Ja aktuell sind es bei mir auf Modbus 2 Sekunden.
Haupt Sps list alle 2 Sekunden die Variablen von den Untergeordneten SPSn.

Kann es sein, dass das Webfront zwei Wartezeiten hatte?
Nach Ablauf der ersten (sehr kurzen) Zeit wurde, wenn die Aktion noch nicht abgearbeitet war, ein Ladekringel angezeigt und dann lief eine zweite Zeit.

Eventuell wäre so eine ähnliche Lösung hier auch denkbar? Wenn also nicht innerhalb weniger ms ein neuer Wert kommt, wird die Anzeige auf den neuen Wert gesetzt und das Element abgedunkelt/inaktiv/Ladekringel, bis es nach Zeit x auf den alten Wert zurück springt.

Der Slider im Webfront war ja auch flüssig zu bedienen, eventuell diese Technik überführen?
Michael

1 „Gefällt mir“

@Dr.Niels
Ich wäre Euch sehr dankbar wenn Ihr diese Änderung nochmal überdenkt.
Ich habe eigentlich überall mindestens 1 sek Abfragezeit, der zu lesenden Modbusvars.
Das ist eigentlich für eine Visu schnell genung,
Trotzdem habe ich das Verhalten bei allen Licht Schaltstellen in der Visu, gerade getestet.
Ich dachte das Verhalten wäre nur über meine verteilten SPSn mit 2 sek Abfragezeit, aber es ist überall vorhanden.
Switch wird gelb, geht dann aus und wird wieder gelb, ist nicht schön.
grafik

Natürlich könnte ich alles auf 200ms runterstellen, aber muss das sein, dass belastet doch nur das Netzwerk.

grafik

Ich würde die Wartezeit sonst einfach mal auf 5 Sekunden erhöhen, dann sollten die Effekte bei euch ja wegfallen. Die 5 Sekunden werden ja auch vorzeitig beendet, wenn die Schaltoperation mit einem Fehler quittiert wird oder ein Wert geschickt wird, es geht also wirklich nur um Variablen, die geschaltet werden und daraufhin nichts machen.

1 „Gefällt mir“

Super, dass sollte passen…