- √ - v2.311 Gruppenadressen

[OColu]

Ich habe in der ETS einige Gruppenadressen geändert, dabei sind die Leerzeichen am Ende der Beschreibung gelandet.
OPC Export, dann Import in das EibStudio, da hebe ich vorher die gleichen Änderungen händisch vorgenommen da mir das esf File ja erst hilft wenn alles stimmt, leider ohne zu Wissen das Leerzeichen am Ende gestanden haben.
:-/
Um die Fehler zu finden habe ich das vorherige und das letzt esf File in einem Editor der mehrere Fenster beherrscht verglichen, das hatte mir beim letzten mal geholfen. Leider sieht man dabei eben jene Leerzeichen am Ende nicht, da die dort vom Tab verschluckt werden.

Das eine wahlweise Unterteilung des Code Fenster nicht einfach ist kann ich noch verstehen. Warum aber der Adressbaum bei Kompilierfehlern verschwinden muß ist mir ein Rätzel.

[saft6luck]

@Saft6luck:
Was hat das mit Makros zu tun? Versteh ich nicht.

Hatte ich doch schon hier geschrieben: die selbe Fehlermeldung kommt/kam auch bei einem unvollständigen Makro und zwar an falscher Position.

[enertegus]

Um die Fehler zu finden habe ich das vorherige und das letzt esf File in einem Editor der mehrere Fenster beherrscht verglichen, das hatte mir beim letzten mal geholfen. Leider sieht man dabei eben jene Leerzeichen am Ende nicht, da die dort vom Tab verschluckt werden.

Da würde ich zum einen anderen Editor empfehlen.
Wenn Du da GAs nicht definiert hast, gibt das eben den Fehler. Ich wüsste nicht, was ich da verbessern soll: Du nutzt eine ungültige GA und der Compiler mekert das eben an.
Eine Hilfe könnte für Dich das Utility vom bmx sein, welches erlaubt, GAs im Programm umzubenennen.

Das eine wahlweise Unterteilung des Code Fenster nicht einfach ist kann ich noch verstehen. Warum aber der Adressbaum bei Kompilierfehlern verschwinden muß ist mir ein Rätzel.

Die Adressen sind Bestandteil der Objekttabelle (Kompilererzeugnis). Wenn sich die ändern, dann auch grundsätzlich das EibPC Programm.
In der V3 haben wir unbenommen davon - auf ausdrücklichen Userwunsch - die Adressen stehen lassen und einen Warnhinweis generiert.

[enertegus]

Hatte ich doch schon hier geschrieben: die selbe Fehlermeldung kommt/kam auch bei einem unvollständigen Makro und zwar an falscher Position.

Hast Du ein kleines Demoprogramm?

[OColu]

Da würde ich zum einen anderen Editor empfehlen.
Wenn Du da GAs nicht definiert hast, gibt das eben den Fehler. Ich wüsste nicht, was ich da verbessern soll: Du nutzt eine ungültige GA und der Compiler mekert das eben an.
Eine Hilfe könnte für Dich das Utility vom bmx sein, welches erlaubt, GAs im Programm umzubenennen.

Was soll den ein anderer Editor besse machen? Ein Tab unterscheidet sich halt nicht von einem Leerzeichen mit nachfolgendem Tab. Auch nicht im EibStudio.
Und der ETS sind die Leerzeichen am Ende gleich ganz egal, zum Problem werden die erst wenn das EibStudie die mit der Adresse verheiratet....

Die Adressen sind Bestandteil der Objekttabelle (Kompilererzeugnis). Wenn sich die ändern, dann auch grundsätzlich das EibPC Programm.
In der V3 haben wir unbenommen davon - auf ausdrücklichen Userwunsch - die Adressen stehen lassen und einen Warnhinweis generiert.

Die alten Adressen stehen lassen? Oder die aus dem aktuellen esf File? Ersteres wäre imho Unsinn...

Warnhinweis ist ok, gut wäre noch wenn im Code Adressen drin sind die nicht im aktuellen esf Import vorkommen diese zu kennzeichnen. Gelb hinterlegt, oder dergleichen.

Dann noch ein horizontal teilbares Codefenster und alles wird gut. ;-)

[saft6luck]

Da würde ich zum einen anderen Editor empfehlen.

Bei einer integrierten Entwicklungsumgebung einen externen Editor verwenden finde ich etwas sonderbar. Leider wird es aber momentan grundsätzlich notwendig, wenn man z.B. includes bearbeiten möchte.

Wenn Du da GAs nicht definiert hast, gibt das eben den Fehler. Ich wüsste nicht, was ich da verbessern soll: Du nutzt eine ungültige GA und der Compiler mekert das eben an.

Es geht nicht um das berechtigte Markieren des Fehlers, sondern um den GA-Baum, im Editor, rechts oben. Dieser wird gelöscht, wenn nicht erfolgreich kompiliert werden kann. Das ist indiskutabel schlecht!

Eine Hilfe könnte für Dich das Utility vom bmx sein, welches erlaubt, GAs im Programm umzubenennen.

Welches Tool und warum ist ein externes Tool notwendig?

Die Adressen sind Bestandteil der Objekttabelle (Kompilererzeugnis). Wenn sich die ändern, dann auch grundsätzlich das EibPC Programm.

Die Adressen ist erst einmal Bestandteil der ESF. Es reicht deren Inhalt darzustellen, oder?

In der V3 haben wir unbenommen davon - auf ausdrücklichen Userwunsch - die Adressen stehen lassen und einen Warnhinweis generiert.

Versteh ich nicht, gestern kompiliert, mit Fehler -> Fenster ist leer. Welche Warnung meinst du?

Hast Du ein kleines Demoprogramm?

Hm, klar, aber geht es nicht zu reproduzieren?

Verwende ein Makro mehrfach am Anfang richtig (bei mir CommandFusion joins) und schreib das gleiche Makro nur als Namen ans Ende des Programms.

-> syntaktisch falsch, klar, nur wird das erste Auftreten des Makronamens markiert und im Fehler angegeben.

[enertegus]

Bei einer integrierten Entwicklungsumgebung einen externen Editor verwenden finde ich etwas sonderbar.

Der Workflow war so geplant, dass die GA vorliegen. Das umändern einer oder wenigen GAs sollte dennoch möglich sein - erst den Code auskommentieren, dann ESF importieren, die GAs im Code ersetzen und wieder den Kommentar entfernen.
Ich denke aber, das ist so schon klar, nur wohl nicht komfortabl genug empfunden.

Welches Tool

-> bmx fragen.

Die Adressen ist erst einmal Bestandteil der ESF. Es reicht deren Inhalt darzustellen, oder?

Nicht, wenn man im Fenster rechts auf den Bus kommunizieren will und kann. Da ist hinter der GA eben ein Objekt im EibPC.

Versteh ich nicht, gestern kompiliert, mit Fehler -> Fenster ist leer.

Erstes Öffnen-> kompileren -> ok. GAs erscheinen.
Programmierung -> Fehler -> GAs bleiben

-> syntaktisch falsch, klar, nur wird das erste Auftreten des Makronamens markiert und im Fehler angegeben.

Bei mir kommt da z.B.

Runtime error:
  ! variable not defined: >UmschaltShifter< ! 
ID:11

Erläuterungen zum Runtime-error und warum der so auftritt s.o.
Ggf. könnte man bei der Fehlermeldung auch nioch hinschreiben: Überprüfen Sie alle Vorkommen von >...< im Code (?)

[saft6luck]

Bei mir kommt da z.B.

Runtime error:
  ! variable not defined: >UmschaltShifter< ! 
ID:11

Erläuterungen zum Runtime-error und warum der so auftritt s.o.
Ggf. könnte man bei der Fehlermeldung auch nioch hinschreiben: Überprüfen Sie alle Vorkommen von >...< im Code (?)

• Das Makro ist vorhanden, oder?
• Das Makro wird an der markierten Stelle richtig geschrieben und syntaktisch richtig verwendet, oder?
• Das Makro wird sehr weit weg, am Ende des Codes, falsch verwendet, das Makro existiert aber immer noch, oder?

Es stimmen also entweder Syntax oder Parameterliste nicht mit der Vorlage überein, oder?

Jetzt frage ich mich (auch mit der Erklärung oben) wieso das 1. Vorkommen dieses Makros als "Variable nicht deklariert" bemängelt wird?
Und selbst wenn es eine Erklärung für dieses Verhalten des Kompilers gibt, ist es falsch.

NB: Und wieso soll diese Fehlermeldung ein "Runtime-error" sein? Runtime-error treten bei Programmablauf auf, daher Runtime. Dies sind Kompiler- oder Linker-Fehler.

[enertegus]

Jetzt frage ich mich (auch mit der Erklärung oben) wieso das 1. Vorkommen dieses Makros als "Variable nicht deklariert" bemängelt wird?

Weil es möglich wäre, eine Variable UmschaltShifter zu definieren, egal ob es schon ein gleichnamiges Makro gibt.
Also fehlt dem Compiler die Zuweisung = ...

NB: Und wieso soll diese Fehlermeldung ein "Runtime-error" sein? Runtime-error treten bei Programmablauf auf, daher Runtime. Dies sind Kompiler- oder Linker-Fehler.

Nun, der Code ist sozusagen fertig und es werden nochmals alle Zuweisungen überprüft. Ob man das nun als Runtime oder wegen mir Pre-Runtime bezeichnet, ist mir egal.
1. Gelinkt wird nix und 2. Kompilerfehler sind sie alle.

[saft6luck]

Weil es möglich wäre, eine Variable UmschaltShifter zu definieren, egal ob es schon ein gleichnamiges Makro gibt.
Also fehlt dem Compiler die Zuweisung = ...

Aber an anderer Stelle.

Wer will jetzt eine Variable genauso nennen wie ein Makro?

Kompilerfehler sind sie alle.

Dann Kompilerfehler, oder Objektchecker etc. was ja auch der Linker macht.
Als Runtime error könnte man die Fehlereinträge im eibPC bezeichnen.

[OColu]

Weil es möglich wäre, eine Variable UmschaltShifter zu definieren, egal ob es schon ein gleichnamiges Makro gibt.
Also fehlt dem Compiler die Zuweisung = ...
Nun, der Code ist sozusagen fertig und es werden nochmals alle Zuweisungen überprüft. Ob man das nun als Runtime oder wegen mir Pre-Runtime bezeichnet, ist mir egal.
1. Gelinkt wird nix und 2. Kompilerfehler sind sie alle.

Ich greif das hier noch einmal auf, weil es mich immer noch den Kopf schütteln läst.

Wenn ich folgende GA, die so auch im esf File steht, im dargestellten Abschnitt habe:

[INIT]
"UmschaltShifter-1/2/3"

dann darf der Compiler das NICHT als undefinierte Variable missverstehen!
Egal wie viel Mist wo anders im Code steht.

Genau das ist bei mir aber passiert, nur das die GA halt "Fenster Ws-7/5/20" heist und es noch eine ganze Reihe anderer Fenster gibt. Und die hatte der Compiler ALLE als undefinierte Variable auf dem Zettel, obwohl es sich ausnahmslos um GAs handelt.
Das der Editor das Format einer GA richtig erkannt hat sieht man ja am Syntax-Highlight das er richtig gesetzt hat. Warum macht der Compiler dann den Versuch das als Variable zu deuten.

Ob nun pre- post- oder Sternzeit- Fehler ist doch egal. Eine GA im richtigen Format bleibt eine GA, egal wie oft darin Begriffe vorkommen die auch eine Variable, ein Makro, oder eben Bullshit an anderer Stelle im Programm sein können.

[enertegus]

Ich greif das hier noch einmal auf, weil es mich immer noch den Kopf schütteln läst.

Sag ich doch: Wir reden von zwei verschiedenen Dingen. Das oben war der Fall, den saft6luck hier eingeworfen hatte. Hat nichts mit dem Problem des Threads zu tun.
Zu diesem kommt die Fehlermeldung, dass die GA nicht definiert wird, siehe https://knx-user-forum.de/381321-post9.html. Da steht "EIB-Adresse nicht bekannt. Überprüfen Sie den ETS Export oder die Schreibweise." das ist nix zum Kopfschütteln.

[saft6luck]

Sag ich doch: Wir reden von zwei verschiedenen Dingen. Das oben war der Fall, den saft6luck hier eingeworfen hatte. Hat nichts mit dem Problem des Threads zu tun.
Zu diesem kommt die Fehlermeldung, dass die GA nicht definiert wird, siehe https://knx-user-forum.de/381321-post9.html. Da steht "EIB-Adresse nicht bekannt. Überprüfen Sie den ETS Export oder die Schreibweise." das ist nix zum Kopfschütteln.

Er schreibt aber, genauso wie bei mir, dass da steht/stand "Variable nicht definiert". Ist leider so.

[enertegus]

Er schreibt aber, genauso wie bei mir, dass da steht/stand "Variable nicht definiert". Ist leider so.

Ich habe das aber anders verstanden.
Dann bitte das Programm mit dem Fehler. Nicht dass ich es nicht glaube, sondern ev. verbessern kann.

[alex275]

EibPC Anfängerfrage - bitte nicht hauen...;-)

nachdem ich die letzten zwei abende fast wahnsinnig geworden bin, hab ich heut diesen thread entdeckt, der thematisch passt, und ich hoffe, dass ihr mir die Tomaten von den Augen nehmen könnt:

ich hab folgenden code:

//Lüftung WC schalten
if event("L_WC_schalten-1/1/6") and !"L_WC_schalten-1/1/6" then write("LF_WC_schalten-7/1/2",EIN) endif
//Test
//if event("Zuhause-18/0/1") and !"Zuhause-18/0/1" then write("LF_WC_schalten-7/1/2",EIN) endif
//

--> eigentlich möchte ich mit der ga Zuhause über den eibpc diverse sachen schalten, hab zu testzwecken aber mal die wc-lüfter ansteuerung genommen, nur das interessiert den eibpc nicht die Bohne...????

- taster wc und flur sind die identischen
- ga's bzw. ko der taster identisch
- aber ga Zuhause nur mit dem Taster nicht auch mit nem Aktor verknüpft
- im ets-export ist die ga Zuhause drin, genau gleich parametriert wie die ga L_WC_schalten
- alle möglichen flag-kombinationen beim ko des tasters, auch wenn sie noch so unsinnig sind, ausprobiert

Dann hab ich in der Verzweiflung mal die ga des WoZi-Tasters genommen --> geht einwandfrei !!!

Nun hab ich folgenden code getestet:
//Lüftung WC schalten
if event("L_WC_schalten-1/1/6") and !"L_WC_schalten-1/1/6" then write("LF_WC_schalten-7/1/2",EIN) endif
//Test
//if event("L_WoZi_schalten-1/1/1") and !"Zuhause-18/0/1" then write("LF_WC_schalten-7/1/2",EIN) endif
//

--> es interessiert den eibpc nicht ob 0 oder 1 auf "Zuhause" kommt, das event WoZi-schalten reicht um den Lüfter anzusteuern...

Ich bin etwas ratlos, hab echt keinen Plan was da läuft... bitte um Hilfe, damit ich's kapier

Vielen Dank & Grüße