HS/FS HS Abarbeitung Ausgänge Logikbausteine/Telegramm senden

[swenga]

Hallo zusammen,

bei der Übergabe von Textwerten mittels UDP-Telegrammen vom HS habe ich scheinbar ein Reihenfolge-Problem. Screenshots im Anhang.

Die Idee ist, ein 14Byte IKO mit einem String zu befüllen und dann via zweier Befehle den String in das Ausgangs-IKO zu schreiben und das Versenden zu triggern. Scheinbar überholt ein Vorgang den anderen, in der Realität kriege ich ein Telegramm vom HS, allerdings mit dem letzten Inhalt statt dem aktuellen. Selbiges passiert mir öfter auch mit Sprachmeldungen für den HST2Speech. Wie macht Ihr denn das?

Das Senden zeitverzoegert aufrufen ist bloed, da durchaus mal zwei Meldungen recht zeitgleich auftreten koennten, die sich dann in die Quere kommen.

Danke schonmal,

mfg

[Tokamak]

Lege SMSReadyToSend auf den Eingang des Textauslösers.
Zusätzlich solltest du zur Sicherheit die beiden Befehle (Zuweisung Telegramm, senden) in eine Sequenz stecken. Nur so kannst du sicher sein, dass die Befehle nacheinander abgearbeitet werden.

[swenga]

Hallo Tokamak,

klappt soweit, vielen Dank. Ich werde das Thema mit den Textmeldungen mal noch weiter beobachten.

mfg

[swenga]

Hallo zusammen,

mal ein Nachklapp dazu: In den Logik-Ausgangsboxen habe ich es jetzt vermieden, hintereinander Daten zu kopieren (Setze KO auf Wert von anderem KO) und dann das Telegramm-Versenden zu aktivieren. Das funktioniert soweit.

Innerhalb von Sequenzen jedoch gibt es auch "Überholvorgänge". Meine Sprachmeldungen backe ich ueber ein IKO <Sprachmeldung> ab. Jetzt gibts es verschiedene Sequenzen, die im Prinzip folgendes machen:
Zeitpunkt 0 Sekunden : Setze <Sprachmeldung> auf "BlaBla"
Zeitpunkt 0 Sekunden : IP/EIB Telegramm senden

IPTelegramm senden sieht so aus:
Text: SPRICH
Wert als Klartext: <Sprachmeldung>

Über die Sequenz sollten die Befehle hintereinander abgearbeitet werden, doch leider kommt es immer wieder vor, dass statt der aktuellen die vorher gueltige Sprachmeldung abgespielt wird. Der WAF sinkt natuerlich wenn statt der Meldung bei offenem Fenster und Regen die Meldung für "du hast das Einfahrtstor vergessen zuzufahren" kommt

Problem dabei ist dass dieses Verhalten (IKO-Wert wird gesetzt und sofort wieder ausgelesen beim Triggern des IP-Telegrammes, Eingangswert <> Ausgangswert) nicht jedesmal auftritt sondern tendenziell eher nach Betriebszeit des HS von mehr als einer Woche. Die Set-Wert Queues wie alle anderen auch sind leer.

Lösungsansätze:
1) Statt mehrere Sequenzen einfach mehrere IP-Telegramme mit statischen Inhalten anlegen. Unelegant und erzeugt mehr Einträge, wenn Telegramme an mehrere PC gesendet werden
2) In der Sequenz den Trigger "ausloesen Telegramm" auf 1 Sekunde statt 0 Sekunden zu legen. Dann ist die Atomität im Eimer, da eine um 0.5 Sekunden später gestartete Textmeldung die erste ausblocken würde.

Wie weiter, fragt sich,

Swen

[Tokamak]

Innerhalb von Sequenzen jedoch gibt es auch "Überholvorgänge".

Das entspricht mE nicht dem Konzept von Sequenzen. Welchen Sinn soll es dann haben, innerhalb einer Sequenz mit der Verschiebung nach oben oder unten die Reigenfolge zu beeinflussen, wenn es im Falle eines Falles nicht greift.

In meinen Augen ist das ein Fehler. Zumindest die Befehle, die man in einer Sequenz auswählen kann, sollten exakt in der Reihenfolge abgearbeitet werden, die dort angegeben ist. Dabei sollte jeder Befehl in seiner Ausführung atomar, d.h. nicht unterbrechbar sein.

@all diejenigen, die guten Zugang zu Dacom hat: Könntet ihr nachfragen, was hier schief läuft?

@swenga: Du könntest in deiner Logik direkt das zu sendende KO GSM_Data_TX anstelle SMSReadyToSend befüllen und dann durch dieses mittels Textauslöser das Senden triggern. D.h. du würdest dann gar nicht mehr mit SMSReadyToSend arbeiten.

[swenga]

@swenga: Du könntest in deiner Logik direkt das zu sendende KO GSM_Data_TX anstelle SMSReadyToSend befüllen und dann durch dieses mittels Textauslöser das Senden triggern. D.h. du würdest dann gar nicht mehr mit SMSReadyToSend arbeiten.

Schon erledigt. Das funktioniert jetzt auch. Das Problem habe ich derzeit nur bei den Sprachmeldungen zum TextToSpeech.

Ich glaube sogar, dass die Events in der Sequenz nacheinander abgearbeitet werden, jedoch weiss ich nicht wie der Zugriff auf IKO's geschieht. Nach dem atomaren Prinzip muesste eine Variable, wenn sie gesetzt wurde, unmittelbar danach genau diesen Wert haben. Wenn aber HS-intern da mit Puffern oder Queues gearbeitet wird, kann es sein, dass ein sofortiger Abruf nach dem Setzen noch den alten Wert liefert.

mfg

[arosy]

Bei zweimal der identischen Zeit in der Sequenz wäre ich nie sicher welche zuerst durch kommt.
Warum den zweiten Teil nicht auf einen Bruchteil später?

[swenga]

Warum den zweiten Teil nicht auf einen Bruchteil später?

Siehe oben, Lösungsansatz 2 mit seinem Nachteil.

mfg

[Tokamak]

Bei zweimal der identischen Zeit in der Sequenz wäre ich nie sicher welche zuerst durch kommt.

Eine Sequenz ist lt. Wikipedia eine "Aufeinanderfolge". Daher sollte auch bei gleicher Zeit das eine immer nach dem anderen kommen.