Wunsch-Logikbausteine

Das mag sein.
Mit PHP ist gar „fast“ alles möglich, nur müssen PHP-Unkundige sich mühsam alles irgendwo rauslesen und vorkramen.
In manchen Situationen ist es doch einfacher, wenn man paar fertige Bausteine hat, die man schnell verbinden kann, ohne viel Tipp- u. Sucharbeit.

Es wird ein Ding der Unmöglichkeit, zu jedem Modul einen fertigen Baustein zuerstellen …für paresy!
Aber die Basis der Digitaltechnik ist überschaubar. :wink: :wink: :wink:
Dahin sollte der Weg gehen!
Ich fände es jetzt auch nicht gut, wenn hier die SPS-Technik nachgestellt wird …das endet ins uferlose.
Mit ein paar Flipflops, Gattern, Taktgenerator und anpassbaren Schiebregistern ist schon viel getan.

Bei größeren Projekten sehe ich nur die Gefahr von Timingproblemen, die es in der wirklichen Digitaltechnik nunmal auch gibt.

aber wirklich nur kurz … da hier fast jeder das was ich sage in den falschen Hals bekommt (muss wohl an mir liegen) … das sind alles nur Vorschläge und Ideen und immerhin sind Gedanken immer noch frei … aber gerade die große Reaktion auf dieses Thema scheint doch klar einen Bedarf aufzuzeigen.

Ich gebe nancilla uneingeschränkt recht … schaut doch auch mal über euren eigenen Tellerrand … und die Bricks heißen ja nicht das php programmieren in ipsymcon nicht mehr geht …

So … ich zieh mich dann erst mal aus der Diskusiom zurück und harre der Dinge die da (von paresy) kommen …

Hallo,

ich geb jetzt auch mal meinen Senf dazu. Ich komme aus der Mess-Steuer-Regeltechnik (MSR :wink: ) und kenne mich mit ein paar DDC-Systemen aus die es auf dem Markt gibt (z.B. Kieback&Peter, Andover Controls, Plueth-Regeltechnik, Microtrol). Das System Andover Controls ist wie IPS frei programmierbar. Die Programmierung ist ein gemisch ähnlich Basic, Pascal also Quelltext. Die anderen Systeme sind über Grafiksymbole zu programmieren.
Ich kann euch sagen das man mit nichts flexibler ist als mit einer freien Quelltext Programmierung. Was man sich mit Symbolen mühsam erstellen muß, gerade bei komplexen Aufgaben, hat man mit Quelltext oft in ein paar Zeilen gelöst. Die grafische Programmierung hat dafür den Vorteil das es übersichtlich und leicht verständlich für jedermann ist. Ich habe mir schon oft eine Mischung beider Varianten gewünscht aber mir ist kein System bekannt welches dies kann.

Es gibt verschiedene Ansätze der Firmen die die grafische Programmierung einsetzen.
Kieback & Peter z.B. hat in den Reglern fertige Regler-Makros hinterlegt die entsprechend aktiviert und nur noch parametriert werden müssen, also Eingänge, Ausgänge, Merker usw. zuweisen.
Man kann damit ca. 90% aller Anwendungen in der HLK erschlagen. Der SPS-Teil ist über Logikmodule frei programmierbar.

Plüth Regelsysteme gehen da noch einen (besser gesagt mehrere) Schritt(e) weiter. Die Programmierung ist auch grafisch, aber hier gibt es eine komplexe Makrobibliothek die es ermöglicht nur durch Zuweisungen und Parametrierung Anlagen zu erstellen. Das geht soweit das hinter Makros das Programm, die Grafiken und die Programmierung der Bediengeräte komplett hinterlegt sind und das automatisch. Hinter jedem Makro sind Grafikbausteine die voll mit dem Quellprogramm verknüpft sind hinterlegt, d.h. wenn man z.B. eine Kaskadenregelung für eine Lüftungsanlage erstellt sind die Grafiken für die Visualisierung und die Bediengeräte schon fertig und man setzt dann im Grafikblatt nur noch die einzelnen Bausteine zusammen, dann sind auch die Bedienebene, Parameterebene usw. in der Grafik aktiv. Mit programmieren hat das aber nichts mehr zu tun (man kann aber jederzeit etwas dazu programieren und auch die Grafiken ändern, erweitern), ist mehr wie ein Lego Baukasten. Man kann damit aber sehr schnell Anlagen erstellen und Zeit ist Geld heutzutage denn das Geld wird nur über die Dienstleistung verdient und nicht mehr mit der Hardware.
Wenn man jetzt so einem System noch eine Schnittstelle zur freien Quelltextprogrammierung spendieren würde, wäre das unschlagbar.

So eine Makrobibliothek zu erstellen ist ein immenser Aufwand den einer alleine nicht bewältigen kann. Auch wird das System damit ganz schön aufgeblasen da immer alle Attribute der Verknüpfungen vorgehalten werden müssen. Da IPS aber auf einem vollwertigen PC läuft ist dies eher nebensächlich. DDC -Controller sind hier was die Leistung und den Speicher angeht immer etwas beschränkt.

Ich fände es jedenfalls innovativ in IPS eine Mischung beider Varianten zu implementieren :slight_smile:

Grüße
Thomas

Ist man nur einen Tag nicht da, bekämpfen sich hier alle. :smiley:

Ich brauche wohl noch einen Tag, aber dann kann jeder sehen, was ich aus „eueren“ Anregungen gebastelt habe.

Um nur auf ein paar Statements zu antworten:

  1. Man wird Bricks und Scripte kombinieren können.
  2. Jeder kann Bricks erstellen. Das IPS Team wird nur ein paar Grundlegende liefern.
  3. IPS wird dadurch keineswegs langsamer, weil die „Bricks“ im Endeffekt ja nur PHP Code generieren, der ausgeführt wird.
  4. Es wird vorerst bei den Features die oben genannt waren bleiben. Negieren macht die Sache zu kompliziert.
  5. Sobald mehr „Bricks“ vorhanden sein werden, werde ich den MacroEditor entsprechend umbauen. (Um Pkt.4 realisierbar zu machen) Dann kann man Bausteine auch verknüpfen. (Dazu bitte noch keine Diskussion. Soweit ist die Sache noch nicht. :))

Also noch ein wenig Geduld :slight_smile:
Ideen sind trotzdem noch erwünscht. Ich werde passendes schon entsprechend berücksichtigen.

paresy

Habe ich eigentlich schon erwähnt, dass ich wieder an den Weihnachtsmann glaube??? :slight_smile: :slight_smile:

Inverter: ist durch einen passenden Ziegelstein einfach zu kompensieren :smiley:

Bin neugierig und gespannt…

Gruss,
Olli

Ok … dann hier mein Codevorschlag für den Nagierer :

<?
$var=!$var
?>

Noch eine Frage am paresy : Wie werden bei den jetzigen Bricks die Events gehandelt? Nur durch Execute? Oder durch „OnChange=$Eingänge“?

negierer.jpg

Hier bekämpft sich keiner. Es wird nur heftig diskutiert !

Franz

Weihnachtsmann :confused: > erst mal sehen was der Osterhase bringt … :rolleyes:

wo schon so heftig diskutiert wird …

…leidet das bisherige IPS darunter. Bugs, die gefixt werden sollten, bleiben dann mal liegen um IPS immer wieder weiter auszubauen.
Wenn mehr in die Entwicklung von IPS gesteckt wird, heisst das auch mehr Aufwand, sprich mehr Ausgaben, und es wird nicht nicht jedem schmecken, wenn IPS auf einmal schlagartig drastig erhöht würde im Beitrag.
IPS wird immer ‚schwerer‘ und irgendwann wird aus Barebone Rechnern auch nichts mehr.

Arbeitest du noch mit DOS oder Windows 3.11???

Klar war das 1. billiger … 2. schneller … 3. lief es auch auf nem 486’er …

Also die Zeit geht weiter … alles wird teurer und PC immer „fetter“ …

-> Alte Bricks bitte vorher aus dem Script Ordner löschen.

Download:
spätere posts…

Der Watchdog Brick macht eigentlich nix. Ist vorerst nur zum testen der XML Konfiguration gewesen.
Die Funktion dazu gibt es wohl Morgen :slight_smile:

Nun liegt es an euch neue Bricks zu erstellen und Fehler zu finden :rolleyes:

steiner wollte das Unwetter-Script entsprechend umbauen
Olli meinte, er würde das Wetter Script entsprechend umbauen

Weitere Ideen wären:
-Als Input den Regencounter des KS300, als Ouputs Werte wie l/h l/24h…

Farben:
None - Weiß
Const - Gelb
Variable - Grün/Rot
Script - Lila
Unknown - Schwarz

paresy

Noch eine Frage :

Wie werden bei den jetzigen Bricks die Events gehandelt?
Nur durch Execute?
:confused: Oder durch „OnChange=$Eingänge“?

Sobald man Save drückt, werden alle Input Variablen als OnUpdate registriert.

paresy

jetzt hab sogar ich das kapiert …

ich werde mich … sobald der Download wieder freigegeben ist … mal an einen „Rufnummer-zu-Name“ Brick machen … das Script ist ja aus dem Fritzbox Modul fertig … brauch ich dann „nur“ zu „bricksen“… als Input Rufnummer mit Vorwahl … als Output Name …

wäre das was ? War so eine spontane Idee…

… so der Link ist wieder freigegeben.
Wir hoffen auf ein zahlreiches Feedback.

MST

PS: hier mein erster Versuch eines Bircks für die IP-Symcon-Unwetterzentrale
ToDo: Bundesländer > verschiedene ULR’s für die Niederschlagsbilder > Eingabe 1 bis 12 (siehe WetterOnline.de)

Kannst du mir einen Tipp geben was ich für NRW einstellen/ändern/patchen muss?

Wenn es Variablen Ein-/Ausgänge gibt die nicht mir einer Variablen belegt sind dann wird ggf. folgender Code erzeugt:


$__rain_strenght=GetValueInteger("");

Dadurch werden Warnings erzeugt.

Gruss,
Olli

Gibt es so eine Art „Update“ Funktion um die config.xml neu einzulesen und den Wrapper-Code neu erzeugen zu lassen? Am besten mit Übernahme der bisherigen Einstellungen :smiley:

Das würde die Entwicklung von Bricks vereinfachen - und auch Updates.

Gruss,
Olli

zu 1. Zur Zeit wird noch nicht überprüft, ob alle Eingaben vorhanden sind. Kommt aber noch.

zu 2. Einfach Brick per Save speichern und neu öffnen :slight_smile:

paresy

-Default Werte können definiert werden
-Konstanten Listen können definiert werden

Download Links sind die selben wie gestern.
Alte Bricks sind kompatibel. Die neuen Befehle sind optional.

paresy

screen.png

… so, nun sind auch die Bundesländer integriert …
Wir planen einen eigenen Download-Bereich für die Bricks einzurichten.
Dort wird es auch eine genaue Beschreibung vom jeweiligen Autor geben.

MST

rain_forecast.zip (2.03 KB)