[Featurewunsch] Freie Parameter bei Makros

[pio]

Ich möchte gerne an Makros eine unterschiedliche Anzahl an Parametern übergeben, ohne jedesmal ein neues Makro schreiben zu müssen, oder ein generisches, das von Anfang an 21 Parameter vorsieht, aber über z.B. den ersten mitteilt, dass nur die folgenden 8 benutzt werden sollen.
Sinngemäss:

MakroWriteGA ("Lampe1GA", 0%)
MakroWriteGA ("Lampe46GA", 10%, "Lampe47GA", 33%)
MakroWriteGA ("Lampe1GA", 0%, "LampeXXGA", yy%, "LampeZZGA", ZZ%)

aber nicht
MakroWriteGA (2, "Lampe1GA", 0%, "LampeXXGA", yy%, "Dummy", egal%)

[MarkusL]

Jetzt geht's aber ab hier: Nun kommt schon die Anfrage Funktion überladen zu können.
Mal sehen ob Michael das auf die Featureliste setzt?

[pio]

Hechel, hechel, *lechz* (immer noch ein lechz-Smiley )

Naja, es dürfte bei der aktuellen Implementation relativ schwer fallen. Man kann ja "noch nicht mal"
Funktionen deklarieren, oder Prozeduren. Ist halt SPS-Funktionalität.

Muss ich halt bei den Makros kreativ werden.

@enertegus: Nimms nicht so schwer!

[enertegus]

Sinngemäss:

MakroWriteGA ("Lampe1GA", 0%)
MakroWriteGA ("Lampe46GA", 10%, "Lampe47GA", 33%)
MakroWriteGA ("Lampe1GA", 0%, "LampeXXGA", yy%, "LampeZZGA", ZZ%)

Wenn Du diese Makros in verschiedene Bibliotheken auslagerst, geht das so. Allerdings kannst Du die nicht gleichzeitig einbinden.

[saft6luck]

MakroWriteGA (2, "Lampe1GA", 0%, "LampeXXGA", yy%, "Dummy", egal%)

Man kann sich ja auch einfach mehrere Makros machen und den Namen hochzählen,
z.B. MakroWriteGA_3("Lampe1GA", 0%, "LampeXXGA", yy%, "Dummy", egal%)

[IBFS]

Man kann sich ja auch einfach mehrere Makros machen und den Namen hochzählen,
z.B. MakroWriteGA_3("Lampe1GA", 0%, "LampeXXGA", yy%, "Dummy", egal%)

Der Tip ist sehr gut - die einfachen Ideen sind die besten!

[pio]

Der Tip ist sehr gut - die einfachen Ideen sind die besten!

Ja, aber das ist doch das, was ich nicht will ??!!

[IBFS]

Ja, aber das ist doch das, was ich nicht will ??!!

Das ist mir schon klar, aber wenn man den Preis vom EibPC + Software
sieht, dann kann in der V1 noch keine Wunder erwarten. Die Frage ist auch,
wieviele - außer dir - das sonst noch gern hätten. Sowas im Compiler
zu integrieren ist nun nicht gerade die einfachse Übung.

Frank

[enertegus]

Die Frage ist auch,
wieviele - außer dir - das sonst noch gern hätten. Sowas im Compiler
zu integrieren ist nun nicht gerade die einfachse Übung.
Frank

Ja, und dann will man noch Schleifen, Felder, Dynam. Allokation etc.

Da wäre es einfacher, einen Crosscompiler freizugeben- allerdings wird es dann nimmer so einfach.
if a==0 then write ... endif
if a==1 then write ... endif
if a==2 then write ... endif
ist so schön einfach, dass es fast jeder kapiert - und selbst da muss man noch die Sache mit Ereignisschleifem Validierung etc. verstehen.

Naja, bei den Makros lässt sich längerfristig (10 Monate) schon noch was machen, aber vorher kommen erst mal die Features auf der Liste
Michael

[JoeHorn]

Ja, und dann will man noch Schleifen, Felder, Dynam. Allokation etc.

Pointer/Referenzen...

Ja, aber sicher! Vieles geht damit bequemer und effizienter, manches läßt sich nur damit überhaupt lösen.

Da wäre es einfacher, einen Crosscompiler freizugeben -

Hatte zumindes ich doch schon mal irgendwo angedeutet?

Mal so als Anregung:
Alternativ zum EibStudio halt noch einen Crosscompiler mit extra (oder angepasster/erweiterter) IO-Library für KNX anbieten (müste es für EibStudio doch eh schon geben)...
Dann müßt Ihr für die HardCore-User nicht alle Räder noch einmal neu erfinden und habt erst einmal Ruhe...

- allerdings wird es dann nimmer so einfach.
if a==0 then write ... endif
if a==1 then write ... endif
if a==2 then write ... endif
ist so schön einfach, dass es fast jeder kapiert -

Das sieht in C nicht großartig anders aus. Wer es nicht in einer "normalen" Programmiersprache kann, wird auch hiermit nicht so schnell glücklich werden. Von der Arbeitsweise mit der ETS unterscheidet das sich schon beträchtlich.

- und selbst da muss man noch die Sache mit Ereignisschleifem Validierung etc. verstehen.

Eben! Und um das zu verstehen wäre es zumindest für mich einfacher, es wäre normales C und die Validierung ist dann explizit zu sehen und nicht im Compiler versteckt. Kein normaler Programmierer vermutet hinter:
if a==1 then write ... endif
eine Abfrage der Form:
if (old_a != a) {old_a=a; if (a == 1) {write ... }}

Die Validierung macht es auch schwierig die aus anderen Bereichen bekannten Zustandsautomaten umzusetzen, denn eine Verschachtelung von Abfragen funktioniert ja nicht so wie dafür benötigt. Also müßte die Statusvariable zusätzlich in jedes if-Statement eingefügt werden - was für ein Aufwand, vor allem bei verschachtelten Zustandsautomaten...

Oder kann ich bei if zumindest Abfragen von internen Variablen so gestalten, das immer entweder then oder else ausgeführt wird, so das dort enthaltene ifs auf jeden Fall noch zum Zuge kommen?
Konnte ich so bislang nicht aus der Dokumentation herauslesen...

[saft6luck]

Ja, aber das ist doch das, was ich nicht will ??!!

Ja, ist mir auch nur so rausgerutscht

[saft6luck]

if a==1 then write ... endif
eine Abfrage der Form:
if (old_a != a) {old_a=a; if (a == 1) {write ... }}

Leider ist es nicht so einfach, denn es wird auch noch auf gültig abgefragt, siehe Anleitung S. 34.

[enertegus]

Leider ist es nicht so einfach, denn es wird auch noch auf gültig abgefragt, siehe Anleitung S. 34.

Wenn ich meiner Frau zeige:
if "KücheLicht-1/2/3"==EIN then write("KücheDuntabzug-1/2/2", EIN) endif

versteht sie es sofort. Sie denkt nicht drüber nach,
- wie ist das nun mit Gültigkeiten
- Änderungen
etc.
"Wenn das Küchenlicht angeht, dann soll auch der Dunstabzug angehen" - das will ich haben, JA , es wird intuitiv so verstanden, dass es logischerweise um Änderungen geht und dass der EiBPC einfach immer wieder diese Abfrage durchgeht.

Mit dieser geistigen Grundhaltung wurde die Programmiersprache des EibPC entworfen, um die vielen Notwendigkeiten im Komforthaus optimal und schnell zu automatisieren. Das ist der Kern des EibPC.

Dass wir auch Webserver etc. mit dieser Grundhaltung programmieren, ist die logische Konsequenz, wobei wir uns bemühen, das Ganze in sich schlüssig zu halten.

[saft6luck]

Michael, es ist zwar nicht mein Thema, aber wenn du mich direkt fragst ...

Wenn ich meiner Frau zeige:
if "KücheLicht-1/2/3"==EIN then write("KücheDuntabzug-1/2/2", EIN) endif

versteht sie es sofort. Sie denkt nicht drüber nach,
- wie ist das nun mit Gültigkeiten
- Änderungen
etc.

Wenn ich nicht darüber nachdenke, könnte ich das einfach und logisch finden. (Könnte ich ja auch per ETS implementieren.) Aber, ein bisschen länger gedacht und schon kommen die Fragen:
- wie oft schreibt er denn? Wenn das immer wieder durchlaufen wird ...
- merkt er sich den Zustand oder verwirft er ihn? D.h. kann ich den Wert öfter verwenden?
- wie ist der Zustand beim Systemstart? Und wenn bei dieser GA die Logik invertiert ist?
- wie mache ich die Lüftung wieder an, wenn sie automatisch (durch den Aktor) aus gegangen ist? "Aus" und wieder "ein" oder nur "ein"?
- wie kann ich die Lüftung automatisch triggern, damit sie erst Zeitverzögert nach dem ausschalten der Beleuchtung aus geht?

Sprich, wenn ich das Ding für eine Automatisierung verwenden will, komme ich um die Zusammenhänge nicht herum.

Da frage ich mich, warum es dann nicht konsequent heißt:
if ( event("KücheLicht-1/2/3") and ("KücheLicht-1/2/3" == EIN)) then write("KücheDuntabzug-1/2/2", EIN)

wenn das zu umständlich ist, muss ich eben einen Befehl für diese Abfrage erfinden und nicht implizit etwas annehmen, dass dann in allen anderen Fällen vom Programmierer unerwartet ist.

Dafür kann ich dann:
if cycle(0,60) then \\
if ( "KücheLicht-1/2/3" == EIN ) then write("KücheDuntabzug-1/2/2", EIN) endif \\
endif
schreiben, und es macht was man erwartet: es prüft alle 60 sec den Zustand von "KücheLicht-1/2/3" und sendet entsprechend ein "ein" Telegramm oder nicht.

Wie gesagt, es ist nicht mein Thema. Bisher habe ich noch immer eine Lösung gefunden aber die Sprache bleibt, sagen wir mal, "gewöhnungsbedürftig"
P.s. Alle Beispiele ungetestet.

[IBFS]

Für einen ETS Programmierer, der nie nie wirklich programmiert hat
und den event-Charakter (GA wird nur einmal über den BUS gejagt)
des Eib kennt mag der Code:

[B]if "KücheLicht-1/2/3"==EIN then write("KücheDuntabzug-1/2/2", EIN) endif[/B]

logisch sein auch mit dem zugehörigen Seiten im Handbuch.

Wer aber von der realen PC-Programmierung kommt oder
von der SPS-Programmierung, der ist es nunmal gewohnt,
das IMMER wenn die
if...then...endif
Bedingung durchlaufen wird,
ob nun zyklisch (SPS) oder einmalig (Button in einer PC-App.)
der hat jetzt eine dritte Variante die es vorher noch nie gab.
Das ist auf alle Fälle erstmal ungewöhnlich.

Ich bin noch nicht soweit sagen zu können ob ich das nun gut oder
schlecht finden soll. Aber Fakt ist auch, das in der SPS das
Abbild ständig aktualisiert wird und werden muss. Im EibPC kann
man nunmal nicht zyklisch IMMER DASSELBE auf den Bus schreiben.

Theroretisch könnte man den EibBus bei wenigen Telegrammen
schon zu einem zyklischen Bus vergewaltigen, indem man einfach
aller 5 Sekunden immer dieselben EIN-Befehl z.B. zu einer Lampe
sendet,aber das ist natürlich Quatsch.

Daher macht eine 1:1-Adaption eines SPS - if..then - Konstruktes keinen Sinn,
denn sonst müßte man IMMER die FLANKE einer GA auswerten
damit es nicht zum STÄNDIG-SENDEN kommt.


---
if FLANKE_POSITIV("GA") then SCHREIBE (GA,EIN)
if FLANKE_NEGATIV("GA") then SCHREIBE (GA,AUS)
---


deshalb heißt dann die echte Mitnahmeschaltung für beide
Flankenrichtungen im EibPC

 
[B]if "KücheLicht-1/2/3"==EIN then write("KücheDuntabzug-1/2/2", EIN) endif[/B]
[B]if !"KücheLicht-1/2/3"==EIN then write("KücheDuntabzug-1/2/2", AUS) endif[/B]

Da muss man dann als "gelernter" PC/SPS-Programmierer schon etwas
umdenken. Es ist für manche Aufgaben (siehe WebDimmer) allerdings
schon ein ziehmlicher Aufwand zu treiben, damit man alle beteiligen
Schalt- und Status-GAs in der richtigen statischen und dynamischen (event)
Schaltrichtung beachtet. So gesehen wird die event()-Abfrage wohl noch sehr
oft in den nächsten Wochen getippt werden müssen.

Gruß

Frank