ElabNET Technik Forum

Ich vermute mal jetzt nur und schreibe meine Gedanken nieder.

Der eine denkt vom Innenleben der Logik mit ein und Ausgängen
Der andere denkt von außen die Verbindung machen.

Frage an die Beteiligten
Liege ich da richtig das hier ein Kommunikationsproblem seitens Erklärung ist, oder bin ich es der es nicht versteht.

Naja er braucht da einen Wert in der Logik um damit es was neu zu berechnen. Und das Ergebnis davon braucht er dann an irgendeiner anderen Stelle.

Dieser Eingangswert hat nun zwei Knöpfe an denen er verändert werden kann.

Seine Idee war dann vom Knopf eins in die Logik, in der Logik etwas rechnen und neben der neuen Information auch die Eingangsinformation an je einen Ausgang der Logik geben und diesen wiederum mit je dem Eingang der beiden Knöpfe als Anzeige Status geben. Den Ausgang vom zweiten Knopf eben so an den Eingang der Login geben..

Also ein Y zum Logikeingang und ein Y vom Logikausgang, bezüglich der einen Information die an den Widgets angezeigt und direkt bedient wird.

Dieser Signalweg, eine Logik als Durchlauferhitzer zu verwenden, ist schlechtes Design und im TWS vollständig unnötig.

Und zum Verständnis für alle. Vor jedem Eingang und hinter jedem Ausgang sitzt immer der Dispatcher, er ist aber vollständig transparent, da man an den Ein- und Ausgängen immer direkt stets die Quell-/Zielobjekte der Subsysteme sieht.

Wenn ein Widget eine Information sendet, dann sendet es das an den Dispatcher und so lange wie der funktioniert, ist es vollkommen egal ob das nun als Gegenstück an ein anderes Widegt am Statuseingang gereicht wird oder/und an einen Logikeingang. Beide bekommen das selbe.


Zu der Logik und den beiden Bedieninstanzen, warum sind es eigentlich zwei verschiedene Widhteprofile, wenn beide bedienten Werte nur jeweils am anderen Widget angezeigt werden und beide auf die selbe Logik als Eingang gehen?

Einfach eine zusätzliche Widgetinstanz hätte nicht funktioniert?

Dann hättest in Objekten gesehen eh nur ein Widget mit einem Ausgang, der Statuseingang bleibt leer,es ist eh immer das was bedient wird.
Und am Ausgang die Verbindung zum Logikeingang.

Meine Gedanken sind gut beschrieben!

Und ich verstehe dich so, daß ich also den "blauen Weg" nehmen sollte und das das bessere Design ist? Ich sehe da aber architektonisch keinen großen Unterschied zu "rot", es braucht so oder so zwei Verbindungen. (Abgesehen von den technischen Problem des Durchleitens durch die Logik).

Und ich habe nicht wirklich zwei Visu-Widgets, das schien mir nur am leichtesten verständlich zu beschreiben. Es geht vielmehr um einmal Visu, einmal Gerätedisplay (z.B. via Modbus), einmal irgendwas via MQTT...

Ja wenn es ganz "externe" weitere Bedieneinheiten sind, dann macht es noch mehr Sinn das direkt mit dem Dispatcher zu verbinden. Das ist die Drehscheibe, nicht die Logikengine.
Wir sind hier doch nicht bei HA und Co. wo man für jeden Link zwischen den Systemen sich ne Automation basteln muss.

Ich muss mich wohl mal mit "dem Dispatcher" auseinander setzen...

Naja den hast immer auf dem Schirm wenn Du irgendetwas mit irgendetwas verbindest.
Und n:m Beziehungen sind da kein Problem, das lehnt er nicht ab.

und an jedem Objekt selbst siehst ganz genau wo es über dran verwendet wird.

Hi, weil das die Thema die letzten Tage ein paar mal durchs Forum ging und ich mir nicht sicher bin, ob ich da einen klugen Weg gewählt habe:

Ich habe im TWS eine Stelle gesucht um Strings zu speichern die ich evtl. in mehreren Logiken nutzen werde. So direkt im Objektmanager kann ich keine Daten hinterlegen, oder?

Meine Lösung war eine Logik mit x Eingängen anzulegen und die auf „Parameter“ zu stellen. In der GUI kann ich so die Daten wi geben. Die Eingänge habe ich dann auf x Ausgänge gelegt. Damit die an anderer Stelle nutzbar sind. - Ist das Safe?

VG
Stefan

Das macht das Objektsystem weitestgehend allein.

Irgendwo entsteht ja der String, dann ist er im Objektsystem und der Dispatcher hat es damit zur Verfügung und stellt es direkt jedem Zielsystem zur Verfügung.

Und somit haben auch 20 Logiken die das als Eingang haben diesen Wert instant zur Verfügung. Ob so eine Logik bei einem eingehenden Wert an einem Eingang direkt loslegt etwas neues zu ermitteln oder den Wert einfach entgegen nimmt aber andere Rechentrigger hat und hier einfach nur den zuletzt eingegangen Wert benutzen soll ist dann eine Frage der Definition der Eingangsparameter in der jeweils konsumierenden Logik.

Woher kommt hier der Gedanke das man irgendetwas extra wo speichern muss, wofür?

Die konsumierenden Logiken kannst auf persistent stellen, dann bleibt denen auch der letzte Eingansgwert über einen Serverreboot erhalten.

In meinem Fall entsteht der String dort wo ich ihn eingebe - es handelt sich um Authentifierzungsdaten (Oauth, d.h. die integrierten Funktionen kann ich nicht nutzn) und Geräte-IDs die bei HTTP-API Abfragen benötige.

Eine Visu-Seite fiele mir als Alternative noch ein....?

Wenn es darum geht irgendeine eingehende Zeichenkette zu prüfen und erst nach positiver Prüfung weiter zu reichen, dann ist es eine notwendige Transformation / bzw. Timing Definition und ja dann macht es auch Sinn diese Information auch aus der Logik heraus zu reichen, aber dann ist es eigentlich ein anderer String, denn am Eingang ist es irgendein String und am Ausgang ein verifizierter Code. Und damit gibt man das Signal nicht auf das selbe Objekt wie wo der Eingang herkommt.

Ansonsten verstehe ich Deine Anwendung nicht und kann keinen Zusammenhang zu dem Thema hier herleiten.