Seite 4 von 4

Re: Mehr Debug Outputs im LE (Sprachdefinition Notepad++ zum Download)

Verfasst: Mi Jun 10, 2020 11:33 am
von Robert_Mini
Super! Ich befürchte ich muss nun doch wieder in Notepad++ programmieren :angry-banghead:

Danke
Robert

Re: Mehr Debug Outputs im LE (Sprachdefinition Notepad++ zum Download)

Verfasst: Mi Jun 10, 2020 11:39 am
von Sun1453
Ach Robert das muss doch nicht sein. --> :angry-banghead:

Bei diesen Kopfschmerzen kannst du doch nicht diese super Logiken programmieren.

Außerdem hast du jetzt eine schnelle Lösung des Problems. Wie Stefan schon meinte es wird auch im TWS kommen aber alles zu seiner Zeit. Schittstellen sind eben erstmal wichtiger und das sehe ich auch so.

Re: Mehr Debug Outputs im LE (Sprachdefinition Notepad++ zum Download)

Verfasst: Mi Jun 10, 2020 11:53 am
von Eraser
Super danke!

So lässt es sich vernünftig arbeiten... :handgestures-thumbsup:
Unbenannt.png

Re: Mehr Debug Outputs im LE (Sprachdefinition Notepad++ zum Download)

Verfasst: Mi Jun 10, 2020 12:23 pm
von Robert_Mini
@Eraser: Ist zwar offtopic, ich erlaube mit den Hinweis trotzdem:
Für "Letzte Höhe merken" in Zeile 202 ist LATCH meiner Erfahrung nach wesentlich besser:
- Vor allem lesbarer
- Latch ist nur ein a=b, Polynom ein a=d+k*x mit d=0 und x=1.

Zweites kann bei Gleitkomma schon einen Unterschied machen!
Ich hatte schon öfters das Gefühl, dass spätere Abfragen auf (a == k) dann ein false ergeben, da an der 15 Stelle hinter dem Komma was nicht mehr gleich ist. Und ja, richtig wäre für so was immer ein eps=0.00001. Hab ich mit limiter auch gemacht, braucht aber eine weitere Zwischenrechnung mit (a-k) und dann -eps <(a-k) < eps per Limiter.

lg
Robert

Re: Mehr Debug Outputs im LE (Sprachdefinition Notepad++ zum Download)

Verfasst: Mi Jun 10, 2020 1:04 pm
von Eraser
@Robert_Mini

Danke für den Hinweis, gut zu wissen für die Zukunft.
Ich muss aber gestehen, dass diese Zeilen nicht mein Code sind sondern eh deiner von der Jalousie-Steuerung. :lol:

Ich habe nur die Variablennamen adaptiert, das Polynomial war schon da...
viewtopic.php?f=65&t=1565#p16487

Das mit der Änderung an der gefühlt 15. Stelle hinter dem Komma erinnert mich an die Verstellung der Lamellen, die von Zeit zu Zeit auch Werte im Bereich - 0.00001 und + 0.00001 geben, was aber kein Problem darstellt, da der minimale Verstellwinkel für eine Änderung dadurch noch nicht erreicht ist.

"Beer-Smiley"
(gibt es leider noch nicht)

Re: Mehr Debug Outputs im LE (Sprachdefinition Notepad++ zum Download)

Verfasst: Mi Jun 10, 2020 1:07 pm
von Eraser
Robert_Mini hat geschrieben: Mi Jun 10, 2020 11:33 am Ich befürchte ich muss nun doch wieder in Notepad++ programmieren :angry-banghead:
Was stört dich daran?
Vielleicht gibt es einen Workaround für ein Problem...
Robert_Mini hat geschrieben: Mi Jun 10, 2020 9:58 am Wichtiger als das Highlighting ist eher das Fehlerhandling im Editor (Ursprung dieses Threads), das hat mir schon öfters eine längere Suche beschert...
Das Highlighting ist dazu eben auch eine Hilfe, weil zB Variablen nicht richtig gefärbt ein Hinweis auf ein fehlendes "$" sind...
Ich mache es z.B. folgendermaßen:

-) Programmierung in Notepad++
-) Kopieren des fertigen Codes von Notepad++ in einen CustomLogic-Baustein im TW
-) Speichern und schauen, ob der Baustein auf OK wechselt
-) Falls nicht, dann nach der Reihe Logik-Blöcke rausschmeißen und probieren zu speichern
Dies so lange fortsetzen, bis die Logik OK wird und dann den Fehler eingrenzen

Ja da gibt es keine andere Möglichkeit derweil, weil wie du schon geschrieben hast, der interne Logik-Editor des TW diese Fehler nicht anzeigt.

Hab auch schon probiert mit einem JSON-Checker im Internet, aber die spießen sich an den Kommentaren.
Darum bin ich dann mit der obigen Methode dann wieder schneller, als dass ich vorher wieder alle Kommentare rauslösche.

Re: Mehr Debug Outputs im LE (Sprachdefinition Notepad++ zum Download)

Verfasst: Mi Jun 10, 2020 3:18 pm
von Robert_Mini
Danke Wolfgang!

Mach ich im Prinzip nicht anders, nur seit geraumer Zeit wieder direkt im LE, da kann ich öfters speichern und prüfen. Das hilft bei der Ersterstellung.

Für Änderungen hatte ich leider schon öfters das Problem, dass große Logiken funktionierten und ich dann an 5 Stellen was erweitert habe.
Bei >200 Zeilen ist das mit dem Auskommentieren wirklich problematisch, das vergessene "$" die Suche nach der Nadel im Heuhaufen. Hier fehlt mir noch die Idee für Best Practise.

lg
Robert

Re: Mehr Debug Outputs im LE (Sprachdefinition Notepad++ zum Download)

Verfasst: Mi Jun 10, 2020 3:29 pm
von fechter65
Hallo Robert

Mit allergrösster Wahrscheinlichkeit kennst Du diese Möglichkeit schon, aber trotzdem vorsorglich mein Vorschlag:

Wenn ich die berühmte Nadel im Heuhaufen suche, verwende ich die /* */ Kommentierungsvariante. Damit kann ich mit der Eingabe von vier Zeichen ganze Blöcke auskommentieren und so den Bereich, in welchem der Fehler sitzt, rascher orten.

Gruss
Diego

Re: Mehr Debug Outputs im LE (Sprachdefinition Notepad++ zum Download)

Verfasst: Mi Jun 10, 2020 3:46 pm
von Eraser
fechter65 hat geschrieben: Mi Jun 10, 2020 3:29 pm Wenn ich die berühmte Nadel im Heuhaufen suche, verwende ich die /* */ Kommentierungsvariante.
Ja geht natürlich auch und hat den gleichen Effekt :mrgreen:

Re: Mehr Debug Outputs im LE (Sprachdefinition Notepad++ zum Download)

Verfasst: Mi Jun 17, 2020 8:25 am
von Robosoc
Ich bin zwar in letzterZeit sehr wenig aktiv gewesen und habe mich auch nicht viel mit meinem TWS beschäftigen können, aber gestern habe ich mal wieder eine Custom-Logik gebaut und vorgestern gerade diesen Thread zum Thema Notepad++ gefunden und das auch gleich genutzt....genial. Danke!
Dragonos2000 hat geschrieben: So Aug 11, 2019 8:05 pm Was mir beim bauen von Custom Logiken doch stark auffällt ist die Tatsache, dass der Logikeditor recht unspezifische Fehler spuckt. Manchmal kommt eine Meldung, dass etwas nicht definiert ist, dann sucht man sich aber zu Tode, weil er nicht genau anzeigt welche Deklaration fehlt.
In anderen Fällen kommt es erst beim Speichern zu einem Fehler und man steht ganz im Regen.
Genau zu dem eigentlichen Thema hier (also zu dem Beitrag #1) habe ich gestern wieder einmal einen Error gehabt, bei dem ich fast wahnsinnig geworden bin. Bis zum Speichern sah alles gut aus und dann kam permanent Error und ich habe den Fehler lange nicht gefunden. Am Ende lag es daran, dass ich bei einem Modul den Modulnamen komplett groß geschrieben habe. In diesem Fall das AND:

Code: Alles auswählen

  
{
  "Input":[
    ["Feuchtigkeitssensor","","$Feuchtigkeit","u"],
    ["Niederschlagssensor","","$Niederschlag","u"],
    ["Zeit nach letztem Regenschauer in s","Wie lange nach einem letzten Regenschauer, oder nach Bodenfeuchter soll wieder gewäsert werden?","$delay","u"],
    ["Bewässerungszeit in s","","$wasserzeit","u"]
  ],
  "Output":[
    ["Pumpenschalter","Aktiviert oder Deaktiviert die Bewässerungspumpe","$Out","ct"]
  ],
  "Level":[
    ["$Niederschlag","bool",false],
    ["$Feuchtigkeit","bool",false],
    ["$Regennaesse","bool",false],
	["$delay_aktiv","bool",false],
	["$delay","integer",86400],
	["$wasserzeit","integer",90],
    ["$Out","bool",false],
	["$Initiator","bool",false]
  ],
  "Module":[ 
    ["Or" , ["$Niederschlag" , "$Feuchtigkeit"], "$Regennaesse"],
    ["Monoflop","$Regennaesse",0,"$delay_aktiv","$delay",5], // trigger nur bei fallender Flanke, also wenn Regen oder Feuchtigkeit zu Ende.
    ["AND" , ["-$Regennaesse" , "-$delay_aktiv"], "$Initiator"],
    ["Monoflop","$Initiator",0,"$Out","$wasserzeit",0]
	]
}
]
Eigentlich passiert mir dieser Fehler aber meistens bei OR, weil ich da scheinbar einen eingeschlichen Tippfehler habe und nicht schnell genug die shift-Taste löse, bevor ich das R klicke.

Aber solche Fehler zu finden ist wirklich wirklich schwierig, weil das Auge ja gerne selektiv schaut.
Ganz konkrete Wunschvorstellungen zu diesem Error:

Der Custom-Editor markiert eine Zeile, in der der Modulname nicht erkannt wird, gleich als fehlerhaft - gerne natürlich mit entsprechendem Fehlerhinweis "Modulname inkorrekt oder unbekannt".
Oder für diesen Fall noch besser: Modulnamen (wenn es nach mir geht gerne auch Variablennamen) sind nicht Case-Sensititv...also quasi so wie ja inzwischen glaube ich auch Tags nicht Case-Sensitive sind.

Mir ist völlig klar, das AND und And unterschiedliche ASCI-Zeichen sind und das dies mein Tipp- oder Flüchtigkeitsfehler ist. Aber es passiert mir einfach ab und an, und die Fehlersuche ist dann meist zeitraubend und nicht nervenschonend .... Ich denke dann immer mit Blick auf den LogikEditor: Arrrrh, wenn Du schon Error spuckst, warum sagt Du mir nicht wenigstens in welcher Zeile :angry-argument: