Hallo Jürgen,

ganz vielen Dank, dass Du Dir trotz Deiner 1:1 Baustelle die Zeit genommen hast ein Update zu veröffentlichen.

Es war ein toller Krimi gestern Abend.

Hardi

Hallo!

Zitat von Jueff im Beitrag #10525

---

Die Ursache war im 'unsichtbaren' Bereich, die Datei "LEDsAutoprog.h" hatte ein einer Stelle ein Zeilenende "Carriage Return" anstatt "Carriage Return Linefeed", was den Arduino Compiler zu wirren Fehlermeldungen über nicht vorhandene Header-Dateien verführte.

---

Zitat von Hardi im Beitrag #10526

---

Es war ein toller Krimi gestern Abend.

---

Zitat von fbstr im Beitrag #10528

---

Zitat von Hardi im Beitrag #10526

---

Es war ein toller Krimi gestern Abend.

---

Da ich gestern um 23 Uhr ins Bettchen bin: Wurde der Krimi komplett aufgezeichnet von Rolf?

---

Hallo MLL Gemeinschaft,

ab sofort gibt es einen neuen Thread unter Hersteller / Händler

MLL-Shop --- MobaLedLib - LEDs - Servos - Sound

Zitat von Eckhart im Beitrag #10527

---

Hallo!

Zitat von Jueff im Beitrag #10525

---

Die Ursache war im 'unsichtbaren' Bereich, die Datei "LEDsAutoprog.h" hatte ein einer Stelle ein Zeilenende "Carriage Return" anstatt "Carriage Return Linefeed", was den Arduino Compiler zu wirren Fehlermeldungen über nicht vorhandene Header-Dateien verführte.

---

Hierzu muss man wissen, dass es inzwischen viele junge Informatiker und Ingenieure diesen Fehler niemals mehr finden würden! Einfach weil sie heutzutage vollkommen "over tooled" sind und , obwohl sie ein abgeschlossenes einschlägiges Hochschulstudium absolviert haben, niemals mehr einen Compiler from scatch, komplett mit eigenem Parser und lexikalischer Analyse, selber geschrieben haben. Also Daumen hoch für die "alten Männer", die es geschafft haben, diese Fehler zu finden!

---

Hallo Theo!

Zitat von TMaa im Beitrag #10531

---

Zitat von Eckhart im Beitrag #10527

---

Hallo!

Zitat von Jueff im Beitrag #10525

---

Die Ursache war im 'unsichtbaren' Bereich, die Datei "LEDsAutoprog.h" hatte ein einer Stelle ein Zeilenende "Carriage Return" anstatt "Carriage Return Linefeed", was den Arduino Compiler zu wirren Fehlermeldungen über nicht vorhandene Header-Dateien verführte.

---

Hierzu muss man wissen, dass es inzwischen viele junge Informatiker und Ingenieure diesen Fehler niemals mehr finden würden! Einfach weil sie heutzutage vollkommen "over tooled" sind und , obwohl sie ein abgeschlossenes einschlägiges Hochschulstudium absolviert haben, niemals mehr einen Compiler from scatch, komplett mit eigenem Parser und lexikalischer Analyse, selber geschrieben haben. Also Daumen hoch für die "alten Männer", die es geschafft haben, diese Fehler zu finden!

---

LF - CHR$(10) / CR - CHR$(13) (Ich erinnere mich noch daran aus meiner Commodore VIC20-Ära)

Theo.

---

Zitat von Wolfi4711 im Beitrag #10518

---

...
Schön und auch sicherer wäre es gewesen wenn ich eben direkt die beiden Endlagen des Servos auswerten könnte. ...
Besten Dank und schöne Grüße

Wolfgang

---

Hallo Gerald
Damit habe ich wirklich nicht mehr gerechnet. Ganz herzlichen Dank für deine Information.
Echt super 👍 Ich bin froh dass ich nicht gleich Hallsensoren oder Reedkontakte als Endschalter bestellt habe.
Nochmals vielen Dank und schöne Feiertage.

Viele Grüße
Wolfgang

Zitat von gerald bock im Beitrag #10533

---

Zitat von Wolfi4711 im Beitrag #10518

---

...
Schön und auch sicherer wäre es gewesen wenn ich eben direkt die beiden Endlagen des Servos auswerten könnte. ...
Besten Dank und schöne Grüße

Wolfgang

---

Servus Wolfgang,
ich weiß nicht ob gestern dein Thema noch beim Stammtisch behandelt wurde (war nur bis 23.30 Uhr dabei) aber du kannst die Servostellungen mit dem Makro <LED_to_var> auswerten und damit andere Funktionen starten.
Die Servopositionen werden mit unterschiedlichen Helligkeitswerten in den LED-Kanälen definiert. Mit dem angeführten Makro kannst du die Werte abfragen und in einer Variablen weiterverarbeiten.
Im Wiki und in den Stammtischvideos gibt es einige Beschreibungen über die Einsatzmöglichkeiten. Entweder über die Suchfunktion oder im MLL-Almanach nach dem Makronamen suchen.
Ich hab dir eine ProgGenDatei angehängt. Sie ist jetzt nur im Simulator getestet aber ich bin überzeugt das sie auch in der Realität funktionieren wird .
Ich denke das ist das was du gesucht hast.

---

Hallo!

Zitat von GerdR im Beitrag #10535

---

Es stimmt zwar das die Servoposition über die Helligkeitswerte definiert ist, aber - und das ist das Problem - in dem Augenblick in dem z.B. das Servo aktiviert wird. steht der LED_to_VAR Wert auf dem Maximal Wert den das Servo einnehmen soll. die Position des Servo wird sich aber langsam, entsprechend der eingestellten Geschwindigkeit zu diesem Wert hin ändern.Bei A schaltest du das Servo ein, der Schaltzustand geht sofort auf das Maximum, egal wie hoch der Wert ist, er wird immer sofort auf diesen Wert gehen. Das Servo beginnt sich nun zu drehen und wird erst zum Zeitpunkt B den gewünschten Wert einnehmen. Bei C wird das Servo wieder auf Null geschaltet, der Schaltzustand wird sich sofort ändern, das Servo aber gemütlich und in aller Ruhe drehen und erst zum Zeitpunkt D die Nullposition einnehmen.Beim Anzeigen der Servo Position mit der LED_to_VAR Funktion wird es also immer eine Zeitverzögerung zwischen Schaltzustand (An / AUS ) und echter Servoposition ergeben, die daraus resultiert daß das Servo sich langsam zum gewünschten Punkt bewegt.

---

Zitat von Eckhart im Beitrag #10532

---

Fehlererhaltungssatzes

---

Zitat von Wolfi4711 im Beitrag #10518

---

...
Die Idee mit der LED_to_VAR Funktion klingt gut, wird aber so leider nicht funktionieren.
...
GerdR

---

@Jueff ,
Wenn man dann die Zeit des Servos ändert muss man also auch in den LED werten die Zeiten ändern?
Umständlicher geht's nicht - hier versucht man jetzt mit Gewalt die Kuh zum Fliegen zu bringen.

Muss man den unbedingt alles möglich machen?

Ich habe das Gefühl das sich die MLL langsam aber sicher immer mehr von der Beleuchtungs- und Bewegungsschiene entfernt. Irgendwie soll hier ein schwachbrüstiger uralt Prozessor ohne erweiterbare Ressourcen zur Eierlegenden Wollmilchsau aufgeblasen werden. Über die Raspis z.B. wird kein Wort mehr verloren....

GerdR

Zitat von GerdR im Beitrag #10539

---

@Jueff ,
Wenn man dann die Zeit des Servos ändert muss man also auch in den LED werten die Zeiten ändern?
Umständlicher geht's nicht - hier versucht man jetzt mit Gewalt die Kuh zum Fliegen zu bringen.

Muss man den unbedingt alles möglich machen?

Ich habe das Gefühl das sich die MLL langsam aber sicher immer mehr von der Beleuchtungs- und Bewegungsschiene entfernt. Irgendwie soll hier ein schwachbrüstiger uralt Prozessor ohne erweiterbare Ressourcen zur Eierlegenden Wollmilchsau aufgeblasen werden. Über die Raspis z.B. wird kein Wort mehr verloren....

GerdR

---

Zitat von GerdR im Beitrag #10539

---

@Jueff ,
Über die Raspis z.B. wird kein Wort mehr verloren....
GerdR

---

na toll, genau das habe ich erwartet- sagt man irgendetwas gegen die MLL und ihre Macher wird man gleich gedisst.

Keine Wunder das so viele von den Usern die hier am Anfang mit aktiv warten sich zurückgezogen haben.

Kritik ist her anscheinend nicht erwünscht - auch keine Konstruktive.

Ich habe nie gesagt das ich es besser kann - mich würde nur interessieren warum man so krampfhaft an den ATMEGAs hängt, eine immer schlimmere IDE (siehe 2.x), begrenzter Speicher, mit sich selber zu Teil nicht kompatibel (328P, 328PB),und noch einiges mehr.


GerdR

Edit:

Zitat

---

Noch eine Anmerkung: Raspis sind seit längerem und auch nicht in absehbarer Zukunft lieferbar - außer zu Preisen > 120€.

Grüße, Jürgen..

---

Ja nee, is klar, es muss ja auch ein Raspi4 sein ???

Raspberry Pi Pico, RP2040 Mikrocontroller-Board - Preis, 4,10 Euro, Sofort Verfügbar 3500 Stück.

Und das Dingelchen kann mehr als ein ATMEGA 328P

Die wichtigsten Merkmale sind:
RP2040-Mikrocontroller-Chip, entwickelt von Raspberry Pi in Großbritannien
Dual-Core ARM Cortex M0+ Prozessor, flexibler Takt bis zu 133 MHz
264KB SRAM und 2MB on-board Flash-Speicher
Modul ermöglicht direktes Löten auf Trägerplatinen
USB 1.1 Host- und Device-Unterstützung
Stromsparender Sleep- und Dormant-Modus
Drag & Drop-Programmierung mit Massenspeicher über USB
26x multifunktionale GPIO-Pins
2x SPI, 2x I2C, 2x UART, 3x 12-Bit-ADC, 16x steuerbare PWM-Kanäle
Präzise Uhr und Timer on-chip
Temperatursensor
Beschleunigte Fließkomma-Bibliotheken auf dem Chip
8x programmierbare E/A-Zustandsautomaten (PIO) für kundenspezifische Peripherieunterstützung


Sorry Jürgen, du siehst auch nur das was du sehen willst....

Zitat von GerdR im Beitrag #10542

---

Sorry Jürgen, du siehst auch nur das was du sehen willst....

---

Zitat von Jueff im Beitrag #10543

---

…

Es fehlt aber eine Adapterplatine, und jemanden, der die Lösung fertig macht.

---

Hallo MLL Kollegen
da habe ich ja ein Faß aufgemacht, das wollte ich eigentlich nicht.
Aber besten Dank an alle die mir weitere Anregungen geliefert haben.
Ich teste weiter und wenn ich für mein Thema eine Lösung gefunden habe berichte ich darüber.
Besten Dank und schöne Feiertage
Grüße
Wolfgang

P.S Viele Grüße und Danke auch an "Jürgen von der Baustelle". Hoffe die Baustelle findet bald ein erfolgreiches Ende

Hallo zusammen,
also ich bin ja derjenige der sich hier ja nur ab und zu äußert.
Aber mir reicht das was ich an MLL habe Beleuchtung, Servo Steuerung, Signal Steuerung. Und ich brauch auch noch sehr viel Hilfe die ich hier zuvelässig bekomme (Und Schnell).
Da die kollegen hier sich für mehr Knowhow usw. einbringen sollen Sie machen. Ich finde es gut.
Ich habe schon lange den Faden verloren was das Entwickeln von MLL angeht.
Darum meine Meinung macht einfach weiter so. ich meine auch das die Kritik nicht angebracht ist, der wo mehr will muß sich halt mehr in MLL einbringen, und wenn man neue Hard oder Software will, muß auch mitarbeiten hier im MLL Forum,
Oder selber Lösungsvorschläge machen.
Gruß
Rolf

Leute Leute
Was soll diese Diskussion ob mit raspi oder arduibo Aka esp32 !
Wer will kann wie mein Vorredner (rammwolt)
Sagt eine Mehrheit ist aus der Entwicklung raus.
Ich auch ( ich bin da raus ich bin jetzt User und freue mich in alles was hardi Jürgen und co so machen. Wer mehr will soll mit helfen Punkt.
So das ich die Meinung von mir nach 3 Flaschen Bier 🍺
Ortwin

Hallo Zusammen,

ich finde diese Diskussion führt nur ins Leere.

Jürgen (jueff) hat schon so viele Dinge in die MLL implementiert und hunderte Stunden vor dem Rechner für dieses Projekt aufgewendet,
da sollte man einfach mal Danke sagen und sich an den verfügbaren Dingen erfreuen.

Klar geht immer mehr, aber dann sollen doch bitte auch die Leute, die das fordern schauen das es verwirklicht werden kann.
Ich selber bin auch nicht in der Lager solche Dinge zu programmieren, aber ich habe versucht zumindest verschiedene Dinge mit zu entwickeln und Denkanstöße zu geben.

Die Idee das sich ein paar zusammen tun und eine Adapterplatine für den Raspi entwerfen und "serienreif" bekommen würde sich meiner Meinung nach anbieten, wenn dieses Feature doch
schon in der MLL programmiert ist. Jürgen (jueff) hat ja schon einen Prototypen gebaut, daher denke ich gibt es auch schon so was wie einen Schaltplan, welchen man "nur "noch verfeinern und
ausklügeln muss.

Also Freiwillige vor, denke wenn es Fragen gibt, bekommt man auch Unterstützung. Was denkt Ihr wie ganzen Platinen entstanden sind?

Hier soll niemand gedisst oder ausgeschlossen werden. Das Projekt kann nur mit Ideen und Umsetzungen leben (siehe z.B. die Word-Uhr an der Hardi und ich seit geraumer Zeit arbeiten).
Wir sind auf die Hilfe ALLER angewiesen, nur so kann das Projekt am Leben gehalten werden.

Also ran an die Breadboards, die Kabel, Bauteile und Eagle und schon haben wir wieder was Neues.

Schöne Pfingsten

Jürgen

Hallo Jürgen, hallo Martin!

Zitat von fromue im Beitrag #10548

---

Wir sind auf die Hilfe ALLER angewiesen, nur so kann das Projekt am Leben gehalten werden.

---

Zitat von Domapi im Beitrag #10544

---

Nicht herumnölen, sondern aktiv zur MLL-Gemeinschaft etwas beitragen!

---

Wer sich Mal den Spaß macht und den gesamten Threads der MLL durchliest wird feststellen dass es bereits etliche neue Platinen und Erweiterungen für die MLL gab, bzw. noch gibt. Diese Platinen wurden von der MLL Community nicht angenommen, da sie erstens nicht aus dem harten Kern kamen (Hardi, Jürgen aka Jueff, Dominik, u.a) und zum anderen Alf sich geweigert hat die Platinen in seine Auflistung und "Verteilung" aufzunehmen. Die Leute die damals an der Entwicklung beteiligt waren haben sich frustriert zurückgezogen.
Warum soll etwas für die MLL entwickelt werden (von dritten), wenn die Community nur etwas akzeptiert wenn es vom "harten Kern" kommt, so etwa wie - "Nur wo Hardi draufsteht ist auch MLL drin".

Tatsache scheint aber auch zu sein dass die MLL nur einen sehr eng begrenzten Nutzerkreis hat, sonst hätte bestimmt schon jemand die ganze Sache auf GitHub geforkt und hätte eine andere Schiene versucht.

GerdR