[Featurewunsch] Schachteln von LBS

[MrIcemanLE]

Hallo Zusammen,

ich würde gern mal auf den Busch klopfen und eure Meinung zu einem Featurewunsch in Erfahrung bringen.

Wie der Titel schon sagt, habe ich mich schon öfter gefragt, ob man das Verschachteln von LBS nicht systemseitig ermöglichen könnte. Vom Prinzip her, stelle ich mir vor, dass es einen Inputbaustein für jeweils einen Eingang und einen Outputbaustein für je einen Ausgang gibt. Damit kann man eine Logikseite bauen, die man an anderer Stelle als LBS verwendet, der über die Ein-/Ausgänge verfügt, die in der "Include-Logik" definiert wurden. Ich versuche mal das Ganze zu skizzieren:

IncludeLBS.PNG

So müsste man nicht jede etwas komplexere Logik gleich in einen LBS gießen. Und auch die nicht so programmieraffinen User können komplexe Logiken einfach handhaben.
Zusammen mit der Import-Funktion könnte man so auch LBS-Konstrukte austauschen und einfach in die eigene Struktur einbinden.

Was meint ihr dazu?

p.s. Mir ist bewusst, dass man das alles auch mit iKOs realisieren kann --> Input-iKO + Output-iKO und dann an anderer Stelle nur die KOs setzen. Bei dieser Variante geht aber auch schnell die Übersicht verloren, da u. U. viele iKOS erstellt werden müssen und die Ausgangsboxen auf den ersten Blick nicht verraten, welche KOs damit gesetzt werden.

So jetzt *duck und weg*

[uzi10]

wäre toll.... wie bei einer sps funktionsblöcke, die so oft aufgerufen werden können, wie man sie braucht. speichersparend.... wie bei codesys

[vento66]

Bring erst mal dein EDOMI zum laufen Ich finde das überhaupt nicht nötig, da mann sich die LBS auf ein neues Blatt inclusive Verbindungen kopieren kann.

[hx5]

Ich finde es eine gute Idee, dadurch könnte ich viel Übersicht gewinnen ohne viele IKO´s anzulegen..

[gaert]

Die Idee ist ja nicht neu (hatten wir schon vor einiger Zeit) - und im Prinzip auch gut. Ich habe ein solches Feature allerdings nie vermisst - entweder dupliziere ich die entsprechenden Logiken (i.d.R. auf eigene Seiten in entsprechenden Ordnern), oder ich baue mir einen speziellen LBS für eine Aufgabe. Finde ich vollkommen ausreichend und auch übersichtlich genug.

[starwarsfan]

entweder dupliziere ich die entsprechenden Logiken, oder ich baue mir einen speziellen LBS für eine Aufgabe. Finde ich vollkommen ausreichend und auch übersichtlich genug.

Ack, so mache ich das auch. In der Regel gibt es zudem doch auch immer wieder kleine Unterschiede bei den kopierten Logiken, so dass sich eine Zusammenfassung und Mehrfachverwendung direkt wieder erübrigt.

[gaert]

Das stimmt - 1:1 ist bei mir fast keine Logik geklont. Höchstens mal bei diversen "bulk"-Geschichten, wie Reed-Auswertung (Alarmanlage).

[WagoKlemme]

Die Idee ist ja nicht neu (hatten wir schon vor einiger Zeit) - und im Prinzip auch gut.

Stimmt, dafür wurde ich geteert und gefedert.
Ich komme auch von der SPS Seite, zuerst S7 dann Wago. Bei Wago war und ist die Stärke, dass es unzählige (sehr umfangreiche) Funktionsbausteine mit guter Doku gibt.
Das war schon toll. Und eine KNX-Verbindung gibt es auch.
Leider sind viele dieser Funktionsbausteine nicht "offen", d.h. Anpassungen Fehlanzeige. Ferner war halt eine Wago auch nicht für die ganzen IP-Geschichten (Kamera...) konzepiert, klar logisch, ist ja auch eine Industriesteuerung.
Am Anfang tat ich mich mit Edomi schwer, weil ich aus einer völlig anderen Ecke dazugestossen bin. Z.B. meine Visu war per Modbus TCP an die Wago gekoppelt. Viele hier hatten schon Erfahrung mit Gira HS und mussten wenig Umdenken.
Inzwischen läuft Edomi bei mir seit 2/2016 - Logik und Visu und stabiler als alles Andere vorher. Ich vermisse die Funktionsbausteine nicht mehr, denn der neue Weg heisst LBS. Falls mir eine Logik aus Einzelteilen zu komplex/unübersichtlich wird, dann mache ich daraus einen LBS. Fertig.
Ausserdem kann JEDER LBS an die eigenen Bedürfnisse angepasst werden, auch mit obenflächigen PHP Kenntnissen. Alles ist OFFEN.
FAZIT: Edomi verstehen und feststellen -> nicht nötig

uzi10
Sehe ich das richtig ? Du suchst eine "Anleitung" für Dummies in deinem 1. Post und hier weisst Du schon, dass Du Funktionsblöcke ala Codesys in Edomi brauchst.

[uzi10]

haha naja ich les nur mit was gepostet wird und komm aber nicht weiter, weil ich noch im Anfang stecke... Vielleicht liegts auch daran, dass ich es im Docker Container teste.. Aller Anfang kostest halt Zeit!
Jap ich bin halt gwohnt, wenn ich immer das selbe brauche, dass ich einen Funktionsblock aufrufe! Zb ERR oder Jalousie....

[WagoKlemme]

Aller Anfang kostest halt Zeit!
Jap ich bin halt gwohnt, wenn ich immer das selbe brauche, dass ich einen Funktionsblock aufrufe! Zb ERR oder Jalousie....

Genau. Ohne Zeitaufwand gehts mit keinem System, auch bei der Wago nicht.
ERR und Jalousie habe ich mir selber gestrickt und zwar genau das was ich brauche.
2017-05-13 10_11_15-EDOMI · Administration.png2017-05-13 10_12_28-EDOMI · Administration.png

[MrIcemanLE]

Ich will nur mal noch ein kleines Gegenbeispiel bringen, dann bin ich auch still und füge mich der Meinung des Entwicklers

Aktuell versuche ich den Beschattungs-LBS von starwarsfan zu implementieren. Da ich nur Rollläden habe, fallen einige der Funktionen weg. Trotzdem sind nicht wenige der Eingänge Konfigurationsparameter, die fest für das ganze Haus sind und nur wenige sind Fensterabhängig. Wenn ich diesen LBS jetzt für ca. 10 Fenster im Haus duplizieren soll, müsste ich jeden Eingang an ein iKO binden, um später komfortabel anpassungen vornehmen zu können. Ganz mal davon abgesehen, dass die Logikseite aufgrund des sehr großen LBS sehr unübersichtlich werden würde.

Mit der Include-Funktion hätte man nur noch 2-10 Eingänge und zwei/drei Ausgänge, könnte die Konfiguration des LBS zentral und übersichtlich anpassen und alles ist gut nachvollziehbar.

Ich bin auch eher dazu geneigt einen LBS anzupassen oder zu schreiben, aber es gibt halt auch Anwendungsfälle oder Anwender, die eine andere Arbeitsweise benötigen bzw. bevorzugen. Es kann doch mehrere Wege geben eine Lösung zu erreichen. Oder sollen die Stärken von EDOMI (Logik und LBS) den programmieraffinen Usern vorbehalten beleiben?

Gut nun ....

[gaert]

Wo ist das Problem?! Du kannst doch die KOs für die diversen Parameter an den Baustein "anlegen" und den LBS erst danach(!) duplizieren - und schon sind die KOs auch am Duplikat gesetzt

[MrIcemanLE]

Wo ist das Problem?!

Das Prinzip ist mir schon klar. So mache ich es ja auch bei anderen LBS.

Es gibt kein Problem alles funktioniert und alles lässt sich (ggf. mit Programmierleistung) umsetzen. Es geht mir eher um einen optionalen Weg, der in bestimmten Fällen vielleicht verständlicher/einfacher ist.

Bei LBS, die so viel Platz auf der Zeichenfläche einnehemen wird es auch schnell unübersichtlich, wenn ich am Ende nur ein paar Eingänge individuell beschalte. Zehn Beschattungs-LBS auf einer Seite? Die Alternative: 10 Logikseiten für jeden LBS. Wenn ich dann an der vorgeschalteten oder nachgeschalteten Logik was ändern möchte, muss ich das auf 10 Seiten machen.

Vielleicht kommt meine Idee auch ein bisschen falsch rüber. Das ist jetzt alles kein Beinbruch, eher so "Jammern auf hohem Niveau" oder "Nice to have".
Ich will auch garnicht undankbar sein. EDOMI ist klasse so wie es ist.

[WagoKlemme]

Wo ist das Problem?! Du kannst doch die KOs für die diversen Parameter an den Baustein "anlegen" und den LBS erst danach(!) duplizieren - und schon sind die KOs auch am Duplikat gesetzt

oder die entsprechenden, für alle LBS gleichen, KOs zentral platzieren (z.B. Eingangsbox) und auf die 10 LBS verdrahten. Dann muss ich auch nur an einer Stelle was ändern. Die anderen KOs am LBS sind ohnehin individuell für jedes Fenster/Rollo separat zu sehen, was soll man da zusammenfassen ?
In meinen Augen ein eher verkrampft konstruiertes Beispiel, welches mit OOP/include auch nicht eleganter umgesetzt werden kann. Oder ich habs nicht verstanden.
Beweis: So siehts in Codesys aus:

2017-05-19 19_37_17-CoDeSys - Haussteuerung Ver 20 mit Garage.pro - [Rollos (PRG-CFC)].png