Freie Parameter bei Makros

[saft6luck]

Damit programmiert man sehr schnell unbedacht Endlosschleifen ... Genau aus dem Grund haben wir das Validiierungsschema eingeführt.

1. Sind das keine Endlosschleifen, sondern höchstens Code-Teile, die ständig aufgerufen werden. Schleifen lehnst du ja nachwievor ab, oder?
2. Fehlt diese Möglichkeit trotzdem und da hilft dann das Validierungsschema nicht weiter.
3. Kann ich das auch z.B. in einem ABB Logik-Modul problemlos machen. Da kann man dann im Handbuch drauf hinweisen. Es gibt ja genügend andere Hinweise zu problematischem Code im Handbuch!

[enertegus]

Fehlt diese Möglichkeit trotzdem und da hilft dann das Validierungsschema nicht weiter.

Bitte ein Beispiel hierzu...

Kann ich das auch z.B. in einem ABB Logik-Modul problemlos machen. Da kann man dann im Handbuch drauf hinweisen. Es gibt ja genügend andere Hinweise zu problematischem Code im Handbuch!

Derzeit ist die event-Funktion "künstlich" begrenzt auf GA. Eigentlich gibt es sowas wie
if event("1/3/4"==10) then ... endif
Vielleicht löse ich da mal die Bremse im Compiler, aber ich weiss auch gar nicht mehr, inwieweit die Firmware das noch kann (war mal in der 1.029 oder so drinne)
Michael

[saft6luck]

Bitte ein Beispiel hierzu...

Posting #14 dieser Thread

Derzeit ist die event-Funktion "künstlich" begrenzt auf GA. Eigentlich gibt es sowas wie
if event("1/3/4"==10) then ... endif

Die bereits vorhandene Funktion event() entspricht dem Validierungsschema, reduziert auf GAs.

if event( "einfacheineGA-1/0/1" ) and ( "einfacheineGA-1/0/1" == TRUE ) then ...

entspricht nach Validierungschema (wobei das Beschreiben der GA durch den eibPC noch ein Sonderfall sein könnte):

if "einfacheineGA-1/0/1" == TRUE then ...

=> ist genau das Gegenteil von eval().

[IBFS]

Au weia,

an diesem Thread zeigt sich sehr schön, warum es SPSen gibt. Dort wird
das Abbild zyklisch "abgeklappert" und spätestens nach Ende des ersten
SPS-Zyklus stimmen der ZUSTAND IM FELD mit dem ZUSTANDSABBILD in der
SPS überein. Deshalb heißt es ja auch ABBILD.

Und genau hier liegen die Probleme in allen KNX-QUASI-MASTERN (EibPC, HS, KNX-OPC-VISU usw).

Sie stellen einen Master im Sinne von "Gerät mit aktuellem Zustandsabbild aller GAs" dar.

Leider stimmt das ABBILD im diesen Geräten (ab jetzt EibPC) erst dann über ein, wenn man aus allen Geräten die Zustandslage der GAs abgefragt hat
ODER
wenn endlich irgendjemand eine Taste (GA) drückt.


Deshalb hat z.B. (PeterPan wirds wissen) die KNX2S7-Software (Kopplung KNX<->S7-SPS) zwei "Arbeitsbereiche"
1. Zu Beginn des Einschaltens der SPS (mit der KNX2S7-Applikation) werden alle WISSENSWERTE (mit alle GAs) GAs einmal abgefragt.
2. Im Regulären Betrieb werden alle WISSENSWERTE GAs beobachtet und der Zustand - so wie im EibPC- nachgeführt.
Auf bestimmte GAs schreiben kann man natürlich auch UND
Man kann auf ALLE GAs lesen, auch auf jene GAs, die nicht in der Liste der WISSENSWERTEN GAs sind.

So...

Warum ich das nun schreibe, hat den Grund, das mir besonders der Punkt 1
noch fehlt. Zum Beispiel könnte der EibPC in den ersten 2 Minuten nach dem
einschalten eine bestimmte Liste (oder in kleinen App. auch alles) erstmal
einlesen. Dann stimmt das Abbild im EibPC. Und spätestens dann ist der erste
Einschaltvorgang nach einem Programmdownload (der ja alle GAs killt) nicht mehr
dadurch geprägt, das der EibPC nicht weiß, was im FELD los ist,


Fehlt dann nur noch das BESCHREIBEN des INTERNEN GA-Abbildes.

Angenommen durch irgendeine SZENE im FELD (diese ändert ja
NUR das SZENEN-GA-ABBILD im EibPC) ändern sich diverse STATUS-GAs.
Dann würde ich gern - da das logischerweise nicht autom. passiert - den
STATUS-GA Zustand auf den internen SCHALT-GA-ZUSTAND kopieren.




IF EVENT(STATUS-GA) AND STATUS-GA==EIN THEN INTERNAL_WRITE(LICHT-GA=EIN).....

IF EVENT(STATUS-GA) AND STATUS-GA==AUS THEN INTERNAL_WRITE(LICHT-GA=AUS)....

mind. so ODER mit noch vereinfachterem Konstrukt!!!






Ich will da nicht auf den BUS senden und ich will KEINE Variablen
anlegen - wozu auch - die ABBILD-GAs sind doch schon die ECHTEN
VARIABLEN die ich der AUSSENWELT nur angleichen will.

Ist das irgendwie klar geworden -was ich erreichen will!!!

Ich will, soweit es geht, die Benutzung von ZUSÄTZLICHEN Variabelen
im EibPC vermeiden, den die internen GAs habe ich schon, nur leider
kann ich diese nicht für MICH nutzen!

Gruß

Frank

[Uwe!]

zu 1: das macht der EibPC zwar nicht automatisch, aber man kann sie ja zum Systemstart abfragen.

Angenommen durch irgendeine SZENE im FELD (diese ändert ja
NUR das SZENEN-GA-ABBILD im EibPC) ändern sich diverse STATUS-GAs.
Dann würde ich gern - da das logischerweise nicht autom. passiert - den
STATUS-GA Zustand auf den internen SCHALT-GA-ZUSTAND kopieren.

Versteh ich nicht. Wenn sich die "SCHALT-GA" im "FELD" nicht geändert hat, dann darf sie sich doch auch im EibPC nicht ändern!? Und wenn sie sich geändert hat, bekommt das der EibPC doch mit.
Suchst Du evtl. eher einen stets aktuellen Schaltzustand? Das wäre dann eher ein Rückmeldeobjekt vom Aktor, oder?

[IBFS]

zu 1: das macht der EibPC zwar nicht automatisch, aber man kann sie ja zum Systemstart abfragen.

Ja und da schreibst du dann z.B. für 200 GAs jeweils separat eine READ-Zeile, oder wie?
Man darf doch nicht nur an die paar kleine Minibeispiele denken.
Das ist eine Liste oder ein Baum mit "MARKIERT AKTIV" doch viel simpler.
Vor allem muss das Lesen der GAs zeitversetzt erfolgen. 5 Abfragen pro Sekunde.
Das alles zu coden, da sind schon die ersten 220 Zeilen im Codefenster voll.
Das ist unübersichtlich.

Versteh ich nicht. Wenn sich die "SCHALT-GA" im "FELD" nicht geändert
hat, dann darf sie sich doch auch im EibPC nicht ändern!?
Und wenn sie sich geändert hat, bekommt das der EibPC doch mit.
Suchst Du evtl. eher einen stets aktuellen Schaltzustand? Das wäre
dann eher ein Rückmeldeobjekt vom Aktor, oder?

Wenn man auf die ZUSTANDS-GAs IM EibPC schreiben könnte, wäre
das programmieren der Web-Visu viel einfacher, weil man für das
Darstellen des EIN-Zustandes NUR die EIN/AUS-GAs verwenden müßte.
Diese wird weder beim HOCHDIMMEN noch beim Schalten einer SZENE z.B.
im DALI-Dimmer verändert.
D.h. die Anzeige stimmt nicht UND beim nächsten UM-Schalten, schalte ich
in die falsche Richtung.

Frank

[Uwe!]

Ja und da schreibst du dann z.B. für 200 GAs jeweils separat eine READ-Zeile, oder wie?.

Genau!

Man darf doch nicht nur an die paar kleine Minibeispiele denken.
Das ist eine Liste oder ein Baum mit "MARKIERT AKTIV" doch viel simpler..

Da bin ich bei Dir.

Wenn man auf die ZUSTANDS-GAs IM EibPC schreiben könnte, wäre
das programmieren der Web-Visu viel einfacher, weil man für das
Darstellen des EIN-Zustandes NUR die EIN/AUS-GAs verwenden müßte.
Diese wird weder beim HOCHDIMMEN noch beim Schalten einer SZENE z.B.
im DALI-Dimmer verändert.
D.h. die Anzeige stimmt nicht UND beim nächsten UM-Schalten, schalte ich in die falsche Richtung.

Also so was wie ein Rückmeldeobejkt, mit dem man auch schalten kann? Wäre sicher praktisch, aber das entfernt sich für mich auch mehr und mehr vom KNX-Standard, ohne dass jetzte als Ausschluss verstanden wissen zu wollen.

[saft6luck]

Also so was wie ein Rückmeldeobejkt, mit dem man auch schalten kann? Wäre sicher praktisch, aber das entfernt sich für mich auch mehr und mehr vom KNX-Standard, ohne dass jetzte als Ausschluss verstanden wissen zu wollen.

Nö, das ist der Standard!
Aktor schaltet -> Aktor schaltet eigenständig aus -> Status kommt auf anderer GA -> Schalt-GA stimmt nicht mehr. Siehe auch Thread https://knx-user-forum.de/eibpc/7623...-adressen.html.
Dafür gibt es natürlich eine Lösung und bald eine bessere, ABER sie kommt natürlich nicht ohne zusätzliche Variable aus.
Den Zustand von 3 GAs in eine zusammen zu fassen, die dann in der Visu angezeigt wird (und das ist völlig legitim und entspricht dem KNX Standard) ist der Aufwand pur, erst recht, wenn man mehrere Zentralbefehle (1. Stock Licht aus, Alle Lichter aus, Raumsteuerung, Notbeleuchtung etc.) hat. Man kann sich nur wundern!

Zum Thema Systemstart: Da dieser Event nur beim ersten Durchlauf auftritt, ist die Abfrage aller GAs zwar möglich, aber die Antworten dauern und bis dahin sind dann schon hunderte Durchläufe mit falschen Zuständen abgearbeitet worden. (Nicht zu vergessen: Datum und Zeit stimmen auch noch nicht). Nicht sehr hilfreich. Und dann das Abfrage-Feuerwerk am Bus ...

Aber so ist der eibPC: keine Kontrolle über die wichtigen Sachen, aber dafür einfach

[Tessi]

Nö, das ist der Standard!
Aktor schaltet -> Aktor schaltet eigenständig aus -> Status kommt auf anderer GA -> Schalt-GA stimmt nicht mehr. Siehe auch Thread https://knx-user-forum.de/eibpc/7623...-adressen.html.

Ja, dafür nutzt KNX das Konzept der KOs, welche der EibPC (noch?) nicht hat...

Zum Thema Systemstart: Da dieser Event nur beim ersten Durchlauf auftritt, ist die Abfrage aller GAs zwar möglich, aber die Antworten dauern und bis dahin sind dann schon hunderte Durchläufe mit falschen Zuständen abgearbeitet worden. (Nicht zu vergessen: Datum und Zeit stimmen auch noch nicht). Nicht sehr hilfreich. Und dann das Abfrage-Feuerwerk am Bus ...

Das "Abfrage-Feuerwerk" kann man nicht wirklich vermeiden, wenn man so schnell wie möglich nach dem Start alle Stati haben will, denn die werden üblicherweise nicht zyklisch gesendet. Was vermieden werden könnte wäre eine Abfrage derjenigen GAs, die man bis dato schon "zufällig" vom Bus bekommen hat.
Was vermieden werden müsste (was bislang aber wohl nicht geht) ist der Eintritt in die Endlosschleife bevor alle notwendigen Stati bekannt sind (inklusive Zeit und Datum), d.h. man müsste in der Start-Sektion bleiben können bis alle Anfragen beantwortet wurden (mit begrenztem Retry, Timeout und Default-Wert, falls GAs einfach nicht antworten).

Dazu das der EibPC das alles (noch) nicht kann passt auch, das er generell nicht auf Anfragen an eine GA antwortet - bei den meisten KNX-Geräten ist das zwar standardmäßig deaktiviert weil busweit je GA nur ein Gerät antworten sollte, kann aber wenigstens explizit freigeschaltet werden. Der EibPC kann das einfach nicht. Eine anderes Gerät im System kann also keine Stati vom EibPC lesen.

Je länger ich das Dilemma hier betrachte desto mehr steigt meine Anerkennung des Konzepts der konfigurierbaren KO's. Diese erlauben nun einmal sehr elegant, in der Applikation einfach statisch zu denken und den busweiten Abgleich in einer vorgefertigten Transportschicht zu verstecken und nicht in den Logikbefehlen der Applikation, wo sie zu mehr oder weniger Konfusion beim Entwickler führen.

Falls man aber bei EibPC tatsächlich die totale Kontrolle in der Applikation belassen wollte, dann hätte das if aber nicht dieses besondere Validierungsschema haben dürfen, dann müsste die Applikation explizit auf Änderung und Status getrennt testen. Und die Freiheiten bei Verknüpfung und Manipulation von Daten müssten wesentlich größer sein.

Leider läßt sich das jetzt wohl nicht mehr ohne Verlust der Kompatibilität zu Vorversionen ändern, und wird daher wohl dauerhaft bleiben, wie es ist - eine eigenwillige Insellösung - nicht Fisch, nicht Fleisch - keine elegante High-Level-Lösung, aber auch keine gängige Universalsprache. Eben etwas ganz eigenes, das mit gewohnten Regeln bricht.
Üblicherweise ist solchen Ansätzen meist nur ein kurzes Leben beschert und sie verschwinden schnell wieder. In ganz ganz seltenen Fällen setzen sie einen neuen Standard...

[IBFS]

Das "Abfrage-Feuerwerk" kann man nicht wirklich vermeiden, wenn man so schnell wie möglich nach dem Start alle Stati haben will, denn die werden üblicherweise nicht zyklisch gesendet. Was vermieden werden könnte wäre eine Abfrage derjenigen GAs, die man bis dato schon "zufällig" vom Bus bekommen hat.

Deshalb ja der Vorschlag mit der Liste oder dem Markierbarem Baum.
Denn sollten auch die NAMEN der GAs beim erneuten Einlesen der ESF
nachgeführt werden können. Und das FEUERWERK muss ja nicht sein,
da gibt es Startup-FIFO mit Telegrammratenkontrolle, odrr?
Sowas ist doch programmierbar!

Eine anderes Gerät im System kann also keine Stati vom EibPC lesen.

DAS GEHT DOCH BEI KEINEN OPC-artig angebundenen Systemen, odrr?
Also das braucht es nun m.E. nicht.

Leider läßt sich das jetzt wohl nicht mehr ohne Verlust der Kompatibilität zu Vorversionen ändern, und wird daher wohl dauerhaft bleiben, wie es ist - eine eigenwillige Insellösung - nicht Fisch, nicht Fleisch - keine elegante High-Level-Lösung, aber auch keine gängige Universalsprache. Eben etwas ganz eigenes, das mit gewohnten Regeln bricht.

Bei gerade mal 200 Geräte und damit max. 150 Early Adoptern
(ich habe Gerät 00183) ist gibt noch genug Möglichkeiten, die
Erfahrungen aus der LERNPHASE einzupflegen. Ich glaube kaum,
das jemand schon den EibPC im Hardcore-Realeinsatz hat.
D.h. mit vernünftiger Begründung kann die paar Nutzer leicht
leicht überzeugen, wenn der Mehrwert stimmt.

Als Fazit muss ich sagen, das vielleicht doch die BETA-Runde
etwas zu klein und die Zeit zu kurz war.

Frank

[enertegus]

kann aber wenigstens explizit freigeschaltet werden. Der EibPC kann das einfach nicht. Eine anderes Gerät im System kann also keine Stati vom EibPC lesen.

Auf welche soll er denn überhaupt antworten? Wenn das so ist, dann müsste man das ja auch in der ETS programmieren.
Wie ist das denn bei den anderen Geräten ... Bei meinem BJ Panel sind alle GA auf sendend geschalten - das nervt, weil die meisten Verknüpfungen einfach was melden (auch Statusobjekte etc.).
Auch bei den Logikmodulen muss ich explizit angeben, welche beim Start gelesen werden sollen.
Man kann natürlich ein Feature machen:
setreadflag("GA-1/2/3), also das Leseflag für den EibPC setzen.
Deine Argumente versteh ich nicht.

Üblicherweise ist solchen Ansätzen meist nur ein kurzes Leben beschert und sie verschwinden schnell wieder. In ganz ganz seltenen Fällen setzen sie einen neuen Standard...

Dazu sag ich nix und bin raus.PLONK.

[IBFS]

Ja, dafür nutzt KNX das Konzept der KOs, welche der EibPC (noch?) nicht hat...

Was ist den das für ein Unsinn!!!

Entweder man hat ein "Parametrierbares KNX-Gerät" welches man in der
ETS (und ggf. zusätzlich in einerr Applikation) programmiert

ODER

Man nutzt den OPC-Export-ESF-Datei-Möglichkeit!

Beides gleichzeitig man keinen Sinn
und wird auch von keinen QUASI-HOMESERVER
oder von einer OPC-VISU verwendet.


-----------------------------



Das bedingt auch das:

Dazu das der EibPC das alles (noch) nicht kann passt auch, das er generell nicht auf Anfragen an eine GA antwortet - bei den meisten KNX-Geräten ist das zwar standardmäßig deaktiviert weil busweit je GA nur ein Gerät antworten sollte, kann aber wenigstens explizit freigeschaltet werden. Der EibPC kann das einfach nicht. Eine anderes Gerät im System kann also keine Stati vom EibPC lesen.

keine externe VISU oder kein HOMESERVER von außen auslesbar ist.
Solche Geräte sind quasi versteckt am BUS und haben nur indirekt
eine Adresse, nämlich die vom IP- oder RS232-GW


-----------------------

Je länger ich das Dilemma hier betrachte desto mehr steigt meine Anerkennung des Konzepts der konfigurierbaren KO's.

Ja, dann nehme einfach ein Logikmodul von APP, dann ist dir geholfen




Frank

[IBFS]

Man kann natürlich ein Feature machen:
setreadflag("GA-1/2/3), also das Leseflag für den EibPC setzen.

Nein!!!!

Den EibPC von aussen auslesen zu wollen ist nun wirklich Unsinn.

Diese Funktion hat KEIN ESF-an Gerät oder OPC-Server. Das schöne
ist ja gerade, das man solche Arten von Geräten und Software losgelöst
von der ETS programmieren können. Mischmasch ist Mist!

Frank

[saft6luck]

Das "Abfrage-Feuerwerk" kann man nicht wirklich vermeiden, wenn man so schnell wie möglich nach dem Start alle Stati haben will, denn die werden üblicherweise nicht zyklisch gesendet.

Stimme dir zu, aber es war auch eher auf die fehlende Kontrolle gemünzt. Wenn ich einen Startblock verwenden kann UND ich z.B. 5 Tel/s konfigurieren kann, kann ich die Buslast niedrig halten, die Geräte antworten schnelle (jedes für sich gesehen) und evtl. möchte ich zwar alle abfragen, kann aber auf die späteren noch verzichten.

Ansonsten sehe ich auch den Bedarf, hier noch die nötigen Voraussetzungen zu schaffen, um auch den "Profis" ein sehr gutes Tool an die Hand zu geben. Gut reicht halt oft nicht

[saft6luck]

Und das FEUERWERK muss ja nicht sein,
da gibt es Startup-FIFO mit Telegrammratenkontrolle, odrr?
Sowas ist doch programmierbar!

Natürlich ist das programmierbar, aber momentan eben nicht, jedenfalls nicht für den eibPC Programmierer und darum geht es.

DAS GEHT DOCH BEI KEINEN OPC-artig angebundenen Systemen, odrr?
Also das braucht es nun m.E. nicht.

Was soll die Unterscheidung nach "OPC"-artig oder nicht? Wen interessiert das? Ich muss kein Gerät über die ETS programmieren, um GAs lesen zu können, ich muss auch kein Gerät über einen Datenexport programmieren, damit das nicht mehr geht. Das ist schlicht und einfach irrelevant.

Wenn ich Daten aus dem eibPC auslesen können will, z.B. weil meine Logiken jetzt in einem eibPC sind, z.B. die aktuelle Uhrzeit, dann ist die Art der Programmierung egal. Dann lege ich halt eine GA in der ETS an für die Abfrage und/oder die Antwort und gut ist. Da brauch ich auch nicht auf ein ABB Logikmodul downgraden.

Bei gerade mal 200 Geräte und damit max. 150 Early Adoptern
(ich habe Gerät 00183) ist gibt noch genug Möglichkeiten, die
Erfahrungen aus der LERNPHASE einzupflegen. Ich glaube kaum,
das jemand schon den EibPC im Hardcore-Realeinsatz hat.

Also meiner läuft im Realeinsatz, aber natürlich würde ich sofort meinen gesamten Code überarbeiten, wenn das Validierungsschema sich ändert . Ist aber auch nicht schwer, da es bei mir Abfragen zu GAs nur mit explizitem event() gibt.

Als Fazit muss ich sagen, das vielleicht doch die BETA-Runde
etwas zu klein und die Zeit zu kurz war.

Also, solange es der Michael nicht hört, stimme ich dir zu. Aber bitte nicht weitersagen