Fehlermeldung nach der Erweiterung von Ausgängen Thema ist als GELÖST markiert

[jueff]

Hallo Peter,

vielen Dank! Den Fehler habe ich auch soeben gefunden, eine neue Version ist somit schon fertig. Link wie gehabt.

Jürgen...

[PeterVT11]

Hallo Jürgen,

vielen Dank für die schnelle Korrektur. Hab's eingebracht und es funktioniert.

[jueff]

Hallo Zusammen,

leider habe ich bisher nur von PeterVT11 Rückmeldung zu der Testversion bekommen - danke Peter für deine Unterstützung.
Für einer allgemeine Freigabe der Änderungen brauche ich noch weitere Testergebnisse.
Ich bitte erneut um Unterstützung beim Testen.
Details siehe Beitrag #8 viewtopic.php?p=4862#p4440

Jürgen...

[EP2Bernie]

Hallo ihr Spezialisten,

zuerst möchte ich noch allen ein gutes, erfolgreiches, friedliches und besonders gesundes neues Jahr wünschen.

Wenn ich mit der Version 3.5.0C1 teste (101-Platine mit Arduino), dann bekomme ich weiterhin folgende Fehlermeldung:

Fehlermeldung 250

Die Änderung die in der M06_write_header zu machen sind (250 ---> 4091), gibt es nicht mehr?
Entferne ich einige Zeilen und inaktiviere die Debug-Funktion sowie die Store-Status-Zeile, erscheint folgender Fehler:

Visual Basic-Fehler

Nachdem ich die MLL auf die Version 3.4.0 zurückgedreht habe, kann ich wieder mit den beschriebenen Änderungen wie zuvor testen.
Ich benutze da die eingebaute 101-Platine mit ESP.

Ich komme hier nicht weiter.
Was kann/muss ich ändern um weiter testen zu können?

Vielen Dank für die Mühe. Gruß, Bernd

[PeterVT11]

Hallo Bernd,

auch Dir ein gutes, vor allem gesundes neues Jahr.
Die Änderung gibt es bis jetzt nur als wirkliche Beta-Version. Siehe unten in diesem Thread (#28). Sie ist noch nicht veröffentlicht.

[jueff]

Hallo ihr Spezialisten,
...101-Platine mit Arduino...

Hallo Bernd,

bei der 101 Platine bleibt das Limit bei 250 Variablen, der Prozessor hat zu wenig RAM- und Flash Speicher für mehr.
Bei den Plattformen ESP32 und Pico ist das Limit auf >4000 erhöht.

Grüße,
Jürgen....

[jueff]

Hallo Zusammen,

für die Erweiterung der Inputs habe ich ausser von peterVT11 leider kein wertvolles Feedback bekommen.
Für eine Freigabe einer so gravierenden Änderung ist es mir zu wenig.
Ich teste zwar ebenfalls ständig mit dem geänderten Code, aber kann mich noch nicht dazu überwinden, die Änderung mit so wenig Rückmeldung freizugeben.

Bitte erneut um euer Feedback. Auch wenn es nur lautet: meine bestehende Konfiguration funktioniert wie zuvor. Explizite Tests mit mehr als 250 Variablen sind nicht notwendig.
Ein möglicher Fehler bei mehr als 250 Variablen betrifft zur Zeit einen User. Die Änderung betrifft aber ALLE User, ohne dass sie einen Mehrwert haben (und brauchen). Das wichtigste Ziel ist es, dass diese User duch die Änderung nicht eingeschränkt oder gestört werden.

Ich habe die Testversion auf den Stand 3.5.0D1 gebracht.
Der Link ist unverändert.
Danke fü euer Mitwirken.

Grüße, Jürgen...

[PeterVT11]

Hallo zusammen,

ich finde es sehr schade, dass es für eine neue MobaLedLib-Version so wenig Begeisterung hervor gebracht wird. Klar, da gibt es den Spruch "never touch a running system". Aber dann bekommen wir auch nie neue Funktionen, und ärgern uns über irendwelche Fehlerchen.

Wer Angst um seine "MLL-Version" hat, kann ja das Arduino-Verzeichnis (unter C:\Benutzer\<Username>\Dokumente\) weg kopieren und hat den "alten" Stand dann immer noch, falls das neue nicht gefällt.

Und wie Jürgen schon schrieb: Auch ein "bei mir gab es keine Probleme, alles läuft wie vorher" hilft ungemein weiter. Jeder hat doch eine eigene Konfiguration am laufen und damit gibt es damit einen eigenen Testfall.

Bitte macht mit.

[raily74]

Hallo Jürgen,

entschuldige vielmals, das habe ich die ganze Zeit über falsch verstanden. Ich habe immer überlegt, wie ich auf die Schnelle weitere 220 Variablen hinzufüge.

Heute Abend kommt die 3.5.0D1 drauf und dann schalte ich alle Funktionen mit Variablen durch und teste es im Dauerbetrieb. Feedback folgt!

[Frank_TT]

Jeder hat doch eine eigene Konfiguration am laufen und damit gibt es damit einen eigenen Testfall.

Bitte macht mit.

Ich würde gern mitmachen, habe aber noch keine Konfiguration

[jueff]

Bitte zur Auffrischung hier noch der Link zum ursprünglichen Beitrag, der die Installation beschreibt:

viewtopic.php?t=413&start=25#p4440

Ich habe alle Änderungen der aktuellen Beta auch in diese Version nachgezogen.

Grüße, Jürgen...

[raily74]

Hallo Jürgen,

seit Kurzem läuft bei mir auch die 3.5.0D4-long. Die Übertragung an den ESP32 lief bis auf ein nötiges Rebuild fehlerfrei. Ich arbeite nicht mit Platform I/O, weil das bei mir länger dauert als über den üblichen Weg.

Die übertragenen Befehle arbeiten alle fehlerfrei, sowohl die DCC Befehle, als auch die Variablen. Ich werde nun in den kommenden Tagen beobachten, wie es sich beim Programmieren neuer Funktionen verhält.

[raily74]

Hallo Jürgen,

leider hab ich schlechte Nachrichten. Im ersten Moment sah noch alles gut aus. Doch irgendwann musste ich feststellen, dass mein Pattern der Ampel nicht korrekt startet. Normalerweise geht das direkt mit dem Licht an. Seit Installation der 3.5.0D4-long geht es verzögert an und durchläuft nicht mal eine Phase korrekt. Irgendwann leuchten dann alle drei Farben (Rot, Gelb und Grün) gleichzeitig und das Licht des Fahrzeugs erlischt. Zwischendurch durchläuft es auch mal wieder eine Phase korrekt.

Zuerst dachte ich, ich hätte beim Bau bzw. der Programmierung meiner Burg und der Brauerei etwas falsch gemacht. Deswegen habe ich das Pattern dann durch sechs Einzeladressen ersetzt, mit denen ich jeden Zustand der Ampel korrekt schalten konnte. Also bin ich zurück zur 3.5.0D5 und auf einmal lief alles wieder einwandfrei. Das Pattern hänge ich hier an und hoffe, dass du daraus etwas ableiten kannst.

Vielleicht habe ich aber auch bei der Installation der 3.5.0D4-long etwas falsch gemacht. Ich habe alle bestehenden Dateien im Verzeichnis ...\library\MobaLedLib durch die im ZIP-File enthaltenen Dateien ersetzt und dann den ProgGenerator.xlsm in library\MobaLedLib\extras geöffnet.
Wenn man das ganze Verzeichnis "MobaLedLib-longInpAddresses" in diesen Ordner kopiert, laufen die Prozesse ja gar nicht im Hintergrund (Abfrage, ob die alte Programmierung importiert werden soll, Abfrage, welche Icon gewählt werden soll).

Also hab ich es zur Sicherheit ein zweites Mal auf dieselbe Weise installiert, leider mit dem selben Ergebnis. Alle anderen Pattern scheinen auf den ersten Blick einwandfrei zu laufen (Burg, Kunststoffspritzerei, Baustelle, Bahnsteig). Ich gehe jetzt wieder zurück auf die 3.5.0D5.

Auto dunkel aber alle Lampen in der Ampel sind an

Ampel_L+R_Example.MLL_pcf

(3.48 KiB) 10-mal heruntergeladen

[Eckhart]

Moin!

leider hab ich schlechte Nachrichten. Im ersten Moment sah noch alles gut aus. Doch irgendwann musste ich feststellen, dass mein Pattern der Ampel nicht korrekt startet. Normalerweise geht das direkt mit dem Licht an. Seit Installation der 3.5.0D4-long geht es verzögert an und durchläuft nicht mal eine Phase korrekt. Irgendwann leuchten dann alle drei Farben (Rot, Gelb und Grün) gleichzeitig und das Licht des Fahrzeugs erlischt. Zwischendurch durchläuft es auch mal wieder eine Phase korrekt.

Zuerst dachte ich, ich hätte beim Bau bzw. der Programmierung meiner Burg und der Brauerei etwas falsch gemacht. Deswegen habe ich das Pattern dann durch sechs Einzeladressen ersetzt, mit denen ich jeden Zustand der Ampel korrekt schalten konnte. Also bin ich zurück zur 3.5.0D5 und auf einmal lief alles wieder einwandfrei. Das Pattern hänge ich hier an und hoffe, dass du daraus etwas ableiten kannst.

Ich hatte mich schon gefragt, wann es auffällt? Jürgen hat ja meine Beiträge in seiner Forenkonfiguration ausgeschlossen, so dass ich Fehler nur "über Bande" kommentieren kann und warten muss, bis jemand den Fehler meldet und vielleicht meinen Kommentar dazu quoted.

Erfrischend ist übrigens auch, dass du Michael, dass entscheidende zum Fehlerfinden weggelassen hast! Quasi wie ein normaler Anwender, der nicht ahnt, worauf es ankommt. Wenn man nämlich deine pcf an eine Konfiguration, mit bestehenden DCC oder Buttons, hinten anhängt, oder gar keine DCC Adresse, oder Buttons verwendet, läuft das einwandfrei. Ich konnte das nur zuordnen, weil ich alle deine pgf und pcf (auch schon im Stummifoum) gesammelt habe.

Der Fehler tritt nämlich nur auf, wenn man ein InCh-to-X-Var, oder ein Bin-InCh-to-TmpVar vor einem Pattern benutzt und dieses auf der ERSTEN verwendeten DCC Adresse, oder auf dem ersten verwendeten Button liegt. Dann bekommt das nämlich den InCh 0 (Null) und der funktioniert mit den beiden genannten Service-Macros, bzw. dem Pattern dahinter, nicht mehr. Bei dir liegt der Start des Pattern auf einer DCC Adresse, die wiederum ganz vorne in deiner Konfiguration, nach den Heartbeats, von einem anderen Macro als erstes verwendet wird und daher die InCh 0 (Null) Resource bekommt.

Es liegt an diesen beiden Zeilen hier in MobaLedLib.cpp (die Zeile gibt es 2 mal):

if (InCh==0) return; // 08.12.2025: Juergen don't overwrite TmpVar is InCh = 0, allow usage of LED_to_TmpVar for complex macros

die irgendein Artefakt von einer weiteren Entwicklung sind, die nur Jürgen kennt.

Auf jeden Fall funktioniert InCh 0 (Null) nicht mehr richtig und ein Pattern mit GoTo Tabelle liest nur irgendwelche unsinnigen TmpVar Zustände, die von vor dem wirkungslosen InCh-to-X-Var, oder Bin-InCh-to-TmpVar, stammen.

Du kannst die beiden Zeilen löschen, oder ihn fragen wofür es gedacht ist und drin belieben muss, oder irgendwas dummy mäßig in deiner Konfiguration machen, was vorher die Resource InCh 0 verbraucht und keine InCh-to-X-Var oder Bin-InCh-to-TmpVar benutzt.

Gruß, Eckhart

[raily74]

Quasi wie ein normaler Anwender, der nicht ahnt, worauf es ankommt.

Wer hat eigentlich das Gerücht verbreitet, ich sei mehr als ein "normaler Anwender"?
Ich hatte tatsächlich keinen Plan, worauf es ankommt, da ich von der Programmierung im Hintergrund absolut keine Ahnung habe.

Der Fehler tritt nämlich nur auf, wenn man ein InCh-to-X-Var, oder ein Bin-InCh-to-TmpVar vor einem Pattern benutzt und dieses NICHT AUF DER ERSTEN verwendeten DCC Adresse, oder dem ersten verwendeten Button liegt.

Vielen Dank für das Lokalisieren. Dank dieses Hinweises konnte ich drei Pattern in meiner Konfiguration ausfindig machen, die dafür infrage kommen:

Zeile 1 (DCC #27) und 3 (DCC #100) zählen zu solchen Fällen, bei denen die verwendete DCC-Adresse nicht ausschließlich für das Pattern verwendet wird, sondern bereits einige Zeilen drüber andere Funktionen schaltet. Daher funktionieren diese beiden Pattern mit der 3.5.0D4-long NICHT.
Zeile 2 (Variable 'Stapler') ist explizit nur für diese eine Funktion zuständig. Dieses Pattern funktioniert mit der 3.5.0D4-long.

Also habe ich der Ampel nun eine eigene DCC-Adresse gegeben kann damit bestätigen, was Eckhart oben beschreibt:
Mit eigener DCC-Adresse funktioniert das Pattern auch mit der 3.5.0D4-long einwandfrei. Was ich noch testen könnte, ob nachfolgende Effekte mit der Ampel DCC Adresse das ganze wieder durcheinander bringen, gehe aber nicht davon aus, weil Eckhart das bereits bestätigt also getestet hat.

[Eckhart]

Hallo Michael!

Zeile 1 (DCC #27) und 3 (DCC #100) zählen zu solchen Fällen, bei denen die verwendete DCC-Adresse nicht ausschließlich für das Pattern verwendet wird, sondern bereits einige Zeilen drüber andere Funktionen schaltet. Daher funktionieren diese beiden Pattern mit der 3.5.0D4-long NICHT.
Zeile 2 (Variable 'Stapler') ist explizit nur für diese eine Funktion zuständig. Dieses Pattern funktioniert mit der 3.5.0D4-long.

Es ist noch etwas spezifischer!

Bei dir wird es die DCC Adresse 100 sein, die ganz oben in deiner Konfiguration als allererstes als externer Trigger verwendet wird (imho ganz vorne, nach drei Heartbeats, von einem APattern1). Dadurch wird vom Excel VBA Code dafür der InCh 0 (Null) vergeben. Dieser funktioniert aber nicht (aufgrund der besagten Zeilen von Jürgen). Wenn du natürlich DCC 100 deaktivieren würdest, oder DCC 27 die Rolle der ersten Trigger Resource einnehmen würde, dann würde das Phänomen auf DCC 27 auftreten, das Excel VAB nun hier den InCh 0 vergibt.

Gruß, Eckhart

[raily74]

Ja, die erste Funktion, die die DCC Adresse #100 steuert, ist ein XPatternT1.
Die erste Funktion, die die DCC Adresse #27 steuert, ein RandomTime Pattern.
Bei beiden Pattern folgt irgendwann später ein "Bin-InCh-to-TmpVar", das dann nicht mehr funktioniert.

Um es besser einordnen zu können, hänge ich jetzt hier die vollständige PGF an.

3-Generationen-Bahn_2026-02-18.MLL_pgf

(63.03 KiB) 9-mal heruntergeladen

[jueff]

Hallo Michael,

danke für den Test und die Fehleranalyse.

Die gute Nachricht: es hat nichts mit der Umstellung auf lange Inputadressen zu tun
Die zweite gute Nachticht: der Fehler ist gefixt. In MobaLEDLib.cpp haben sich zwei Programmzeilen eingeschlichen, die im Produktivcode nichts verloren haben, da ist mir beim Mergen der Änderungen einen Fehler unterlaufen.

Anbei eine geänderte Version der Datei, bitte nach ..\Documents\Arduino\libraries\MobaLedLib\src kopieren.
Der Fehler ist auch in der Beta-Long behoben.

Jürgen....

[raily74]

Hallo Jürgen,

danke für die schnelle Rückmeldung, doch leider hilft das nicht, das Problem zu lösen.
Zunächst habe ich die Datei einzeln getauscht. Das brachte keine Änderung.

Also habe ich als nächstes die komplette Installation durch Ersetzen aller Dateien neu angestoßen und habe auch alle Dateien wieder neu geladen. Doch auch auf dem Weg funktionieren die beiden oben erwähnten Pattern nicht mehr. Die Ampel mach nach wie vor ein großes Durcheinander.

Tut mir leid, dass ich hier noch keine Entwarnung geben kann.

[PeterVT11]

Hallo Michael,

Lief die Kompielierung über 3 Minuten? Oder war es die kurze Kompielierung? Wenn ja, mach das ganze mal mit gedrückter Alt-Taste (bis das DOS-Fenster erscheint). Die IDE hat ja einen Cache, und der wird nicht immer aktualisiert.

[raily74]

Ich glaube, es war ohne Rebuild. Lasst mich das morgen noch mal checken. Ich gebe euch Bescheid.