[EibStudio] - √ - v2.311 Gruppenadressen

[OColu]

vor ein paar Wochen habe ich auf die v2.311 umgestellt als ich eine Kleinigkeit im Programm geändert habe. Bin mir nicht sicher, aber ich glaube es war nach der Änderung.
Jetzt habe ich ein neues Gerät verbaut und in der ETS4 in Betrieb genommen, alles ohne Probleme...
Natürlich sind jetzt auch im Programm des eibPC ein paar kleine Anpassungen notwendig.
Also habe den OPC export in der ETS4 genutzt, das EibStudio (Linux) angeworfen, die Adressen importiert ....
Fehler über Fehler.
1. Problem, die "ungenutzten" Adressen werden nicht exportiert, was zu Fehlermeldungen des Parsers führt. Lässt sich per Dummy in der ETS beheben, aber wieso brauchte ich früher keinen Dummy??? Im Adressen Fenster im EIB-Studio warren die auch alle vorhanden, obwohl sie in der esf Datei fehlen.
Ok eventuell hat das EibStudio die Änderungen nicht richtig übernommen.
Also Speichern, EibStudio beenden, neu Starten ....

AAAARRRRRGGGG

Jetzt sind im Adressen Fenster GARKEINE Adressen mehr. Auch nicht wenn ich die Adressen neu Importiere.
Und der EIbParser meldet einen Laufzeit Fehler, die Variable "Fenster" wäre nicht definiert.
Für diese Zeile:
[InitGA]
// Initialisierte Gruppenaddressen
"Fenster DWn verriegelt-8/5/21"

Das hat so Jahre und Generationen von EibStudio -Parser -PC Versionen funktioniert! Ich habe an diesem Teil schon lange nichts mehr geändert!

Alles neu gebootet, neu gestartet, neu ex und importiert, es bleibt bei der bescheuerten Fehlermeldung.
Probehalber ein paar Zeilen auskommentiert, Ergebniss: Das EibStudio bleibt hartnäckig dabei das "Fenster irgendwas" eine Variable sei....

Völlig ratlos,

Olaf

[saft6luck]

Also habe den OPC export in der ETS4 genutzt, das EibStudio (Linux) angeworfen, die Adressen importiert ....
Fehler über Fehler.

Mach mal einen Vergleich der alten und neuen etf-Datei. Dann siehst du die Unterschiede. Die Ursachenforschung ist dann bestimmt leichter.

Die Anzeige der Adressen im EibStudio funktioniert nur, wenn der Code sich erfolgreich compilieren lässt

1. Problem, die "ungenutzten" Adressen werden nicht exportiert, was zu Fehlermeldungen des Parsers führt. Lässt sich per Dummy in der ETS beheben, aber wieso brauchte ich früher keinen Dummy??? Im Adressen Fenster im EIB-Studio warren die auch alle vorhanden, obwohl sie in der esf Datei fehlen.
Ok eventuell hat das EibStudio die Änderungen nicht richtig übernommen.

Wenn da was fehlt ist es wohl nicht der Fehler des eibPCs. Höchst wahrscheinlich machst du jetzt etwas anders oder hast etwas geändert , z.B. ETS3->4, script für den Export verwendet, "alle GAs exportieren", "GAs weiterleiten" deaktiviert, Geräte gelöscht etc.?

[Brick]

1. Problem, die "ungenutzten" Adressen werden nicht exportiert, was zu Fehlermeldungen des Parsers führt.

Das war bei der ETS3 auch schon so !

ich trag die mittlerweile all von Hand ein.. so kompliziert ist das Dank Copy/Paste nun auch wieder nicht...

Gruß Martin

[OColu]

Die Anzeige der Adressen im EibStudio funktioniert nur, wenn der Code sich erfolgreich compilieren lässt

das ist ja schon einmal ein Hinweis ....

Wenn da was fehlt ist es wohl nicht der Fehler des eibPCs. Höchst wahrscheinlich machst du jetzt etwas anders oder hast etwas geändert , z.B. ETS3->4, script für den Export verwendet, "alle GAs exportieren", "GAs weiterleiten" deaktiviert, Geräte gelöscht etc.?

ETS4 exportierte esf Datei hat schon früher funktioniert. Wenn ich alle Gruppenadressen dank dummy in der esf drin habe bekomme keine Fehlermeldung zu ungültigen Gruppenadressen mehr, dafür behauptet der Parser halt des der Begriff "Fenster" eine Variable sein MUSS, egal in welcher Syntax verwendet.

[saft6luck]

ETS4 exportierte esf Datei hat schon früher funktioniert.
Wenn ich alle Gruppenadressen dank dummy in der esf drin habe bekomme keine Fehlermeldung zu ungültigen Gruppenadressen mehr,

Das mag ja sein, trotzdem fehlen die Einträge in der esf (-> Exportproblem) und dann hat sich auch was geändert bei Export. Was du geändert hast kann ich nicht sagen. Unbenutze GAs wurden noch nie exportiert, höchstens mit zusätlichen Tools, Einstellungen etc.

dafür behauptet der Parser halt des der Begriff "Fenster" eine Variable sein MUSS, egal in welcher Syntax verwendet.

Ich würde eine unterschiedliche Schreibweise oder Adresse vermuten.
Falls nichts erkennbar ist, ersetz mal alle Einträge durch eine existierende GA und zieh dann die gewünschte GA aus der GA-Liste wieder rein.

[OColu]

mühsam, mühsam

Ich würde eine unterschiedliche Schreibweise oder Adresse vermuten.
Falls nichts erkennbar ist, ersetz mal alle Einträge durch eine existierende GA und zieh dann die gewünschte GA aus der GA-Liste wieder rein.

Zeile für Zeile habe ich die esf und die epc mit alten Ständen abgeglichen und 2 Differenzen gefunden und angepasst. Die hatten aber garnichts, aber auch rein garnichts, mit den bemängelten GAs zu tun!
Jetzt läuft es wieder, und ich frage mich mal wieder warum der Parser nicht wenigsten die richtige Zeile angibt in der der Fehler steckt?

[saft6luck]

Jetzt läuft es wieder, und ich frage mich mal wieder warum der Parser nicht wenigsten die richtige Zeile angibt in der der Fehler steckt?

Das kommt auf die Liste und versandet da

[saft6luck]

Ich hatte am Sonntag ein ähnliches Problem:
Am Ende des Programms waren ca. 10 Leerzeilen und das Keyword eines Makros, das ich im Makroeditor nachgeschlagen hatte (hat der da wohl eingefügt).

Beim kompilieren kam dann der Fehler mit dem gleichen Text 'Variable "blah" nicht bekannt', der Editor hat im Sourcecode auf das erste Vorkommen dieses Makros gezeigt.
Hat mich bestimmt eine Stunden gekostet.

[enertegus]

Zeile für Zeile habe ich die esf und die epc mit alten Ständen abgeglichen und 2 Differenzen gefunden und angepasst. Die hatten aber garnichts, aber auch rein garnichts, mit den bemängelten GAs zu tun!
Jetzt läuft es wieder, und ich frage mich mal wieder warum der Parser nicht wenigsten die richtige Zeile angibt in der der Fehler steckt?

Ich habe das eben mal gestestet. Wenn ich einen Code
c="WscheSchacht-3/0/5"
habe (und meine GA eigentlich "WäscheSchacht-3/0/5") heißt, so wirft mir hier der Compiler:

Syntaxfehler in Zeile:[13]
>c="WscheSchacht-3/0/5"< in der Datei "test.epc"
EIB-Adresse nicht bekannt. Überprüfen Sie den ETS Export oder die Schreibweise. in >"WscheSchacht-3/0/5"< in >=<
ID:15
EibParser wurde mit Fehler beendet.

Das ist doch brauchbar, oder was versteh ich da nun nicht?

[OColu]

Fehlermeldungen des Kompiler...

Leider verwies die Fehlermeldung auf eine GA in der [init] Sektion, die ich also noch nicht einmal selber geschrieben habe....

Zur Verdeutlichung:
Wenn ich ein Programmcode habe der die Zeile
C="Fenster Wohnzimmer GA-3/0/5"
sowie verschiedene Variationen der GA wie zB "Fenster Schlafzimmer GA-4/1/2" enthält.
Und dieser Programmcode über Jahre einwandfrei läuft.
Dann erwarte ich, das wenn ich in einem ganz anderen Abschnitt etwas änder, in dem nirgendwo der Begriff >Fenster< vorkommt, keine Fehlermeldungen beim Kompilieren auftreten das "Fenster" eine nicht definierte Variable wäre!

Erschwert wird die Fehlersuche dann auch noch dadurch das die Gruppenadressen nach dem Fehlalarm des kompiliert nicht mehr dargestellt werden, das hat mich schier in die Verzweiflung getrieben.
Erst eine vergleichende Fehlersuche in einem Texteditor mit einer älteren Version meines Programmcode hat zum Erfolg geführt. Vollkommen unverständlich auch deshalb weil man dadurch erst mühsam die richtige Schreibweise einer GA im gesamten Programmcode haben muß bevor man die Vorteile der Darstellung im EibStudio nutzen kann.

Weiters Problem für das ich aber noch Verständnis habe:
Fehler die sich aus dem Zusammenhang an unterschiedlichen Stellen des Programmcode ergeben.
Beispiel:
Ich definiere eine Variable, und habe darin einen Tippfehler. Bemängelt wird dann erst bei der Verwendung der Variable. In meinem Fall 600 Zeilen auseinander...

Ein teilbares Fenster für den Programm Code würde einiges helfen.

Gruß, Olaf

[enertegus]

Beispiel:
Ich definiere eine Variable, und habe darin einen Tippfehler. Bemängelt wird dann erst bei der Verwendung der Variable. In meinem Fall 600 Zeilen auseinander...

schau mal:
[highlight=epc]
if y==2 then y=4 endif
/// Ganz viel Code dazwischen.
y=3
[/highlight]
ist gültiger Code, da es erlaubt ist, eine Variable y zu nutzen, die erst nacher definiert wird. Der Compiler "sagt sich" beim if: Syntax ok, Variable nicht definiert. Kommt im weiteren Code dann y als Definition, ist alles Paletti.
Wenn nicht, springt die Runtime - Überprüfung an die Stelle, wo die Variable zuerst verwendet wurde. Die Runtime - Überprüfung erfolgt erst am Ende des Einlesens. Gleich ist das bei den GAs.

Was soll man denn da bitte anders machen?

[OColu]

Ja, schwierig. Leider habe ich auch keine Lösung parat außer dem Editor die Möglichkeit einer zwei Fenster Ansicht zu geben. Das würde viel lästige scrollerei sparen, und die suche Fehlern die sich aus dem Zusammenspiel weit auseinander liegender Code Zeilen ergeben enorm verbessern.

[OColu]

Leerzeichen am Ende der Gruppenadresse

Noch eine Hürde beim Gruppenadressen Import:
Leerzeichen am Ende der Beschreibung.

Also:
"Fenster WWs verriegelt -6/5/10"
oder
"Fenster WWs verriegelt-6/5/10"

im esf File wegen der Verwendung von Tabs praktisch nicht zu erkennen.
In der ETS schon gar nicht.
Und leider auch nicht im EibStudio da es bei Kompilierfehlern den Baum mit den Gruppenadressen nicht anzeigt. Somit ist auch ein "Idiotensicheres" drag&drop nicht möglich.

Mein Workaround um überhaupt das Problem zu finden:
Vom Kompiler bemängelte Zeile Auskommentieren,
neu kompilieren
Vom Kompiler bemängelte Zeile Auskommentieren,
neu kompilieren
Vom Kompiler bemängelte Zeile Auskommentieren,
neu kompilieren
Vom Kompiler bemängelte Zeile Auskommentieren,
neu kompilieren
...
bis ohne Fehler beendet.
Dann in den auskommentierten Zeilen die Adressen deren Beschreibung sich geändert hatte aus dem nun angezeigten Gruppenadressbaum rüber ziehen.
Beim direkten Vergleichen des Teil in "" fällt dann auch das Leerzeichen auf.

DIE Lösung: Anzeigen des Gruppenadressbaum auch wenn der Kompiler mit Fehler beendet. Genau DANN braucht man diesen Adressbaum meine Meinung nach am Meisten.

Gruß,

Olaf
P.S. Ja ich weis, keine Leerzeichen am ende der Gruppenadressenbeschreibung machen...

[saft6luck]

ist gültiger Code, da es erlaubt ist, eine Variable y zu nutzen, die erst nacher definiert wird. Der Compiler "sagt sich" beim if: Syntax ok, Variable nicht definiert. Kommt im weiteren Code dann y als Definition, ist alles Paletti.
Wenn nicht, springt die Runtime - Überprüfung an die Stelle, wo die Variable zuerst verwendet wurde. Die Runtime - Überprüfung erfolgt erst am Ende des Einlesens. Gleich ist das bei den GAs.

Was soll man denn da bitte anders machen?

Hier ist das doch klar verständlich. Wieso redet der Kompiler denn bei unvollständigen Makronamen von Variablen? Und warum zeigt er nicht die Stelle, wo das Makro unvollständig ist? Genauso für GAs. Wieso sind dies Variablen?

[enertegus]

Noch eine Hürde beim Gruppenadressen Import:
Leerzeichen am Ende der Beschreibung.

Wie jetzt: Du kannst eine GA mit Leerzeichen am Ende im Namen nicht importieren? Wenn dem so ist, dann wäre das ein Bug im Compiler.
Oder editierst Du "händisch" die ESF Datei?
@Saft6luck:
Was hat das mit Makros zu tun? Versteh ich nicht.

Ich habe im aktuellen Eibparser die Fehlermeldungen/Erkennung erheblich "gepimpt".

Man teste
[highlight=epc]
// Fehler: vor sun() fehlt der ";"
if change(z) then {
write("TextFeldSynOhr-10/0/14",convert(z,$$c14))
sun()
} endif
[/highlight]
Der Compiler sagt nun, dass der Code nur bis zur Zeile von sun(), direkt vor dem s (Spalte und Zeile wird angegeben) gültig ist.
In eine der nächsten Versionen von EibStudio wird das sicher auch vom Highlight der Fehlermeldung besser umgesetzt.