Zitat von hlinke im Beitrag #250Der 2. Fehler: Beim Import schreibt pyMLL in die Tabelle mit dem Namen, aus der Export geschrieben wurde. Dummerweise, springt es danach zu einer anderen Tabelle. Das muß ich noch überprüfen. Die importierten zeile sollten aber in der Ursprungstabelle angehängt sein. Kannst Du das bitte nochmal nachschauen. Sonnst wäre es gut, wenn ich eine genauere Anleitung hätte, was Du gemacht hast. Und evtl, Deine Export-Datei als Beispiel.
Mein Export ist im Anhang von Post#236 Die Tabelle hieß pyMLL3DMS. Diese Tabelle wird auch angelegt und dort die Einträge gemacht, bevor sie verschwinden. Auf dem Testnotebook hier war noch eine Tabelle DCC_1. Und dort finde ich den Import!
Die Funktion "Tabelle löschen" geht bei mir nicht, oder ich verstehe etwas anderes darunter. Es wird nur der Tabelleninhalt gelöscht (außer der Heartbeat-LED).
Gruss Frank --------------------------------------------------------------------------------------------------------------------- MobaLedLib Forum und Wiki Mein Hauptfred Projekt "Bahnpark Augsburg" Stummitreff BB: jeden 3. Freitag im Monat im Haus Sommerhof in Sindelfingen
Zitat von fbstr im Beitrag #233Der Export von MLL und Import in pyMLL funktioniert noch nicht. pyMLL zeigt zwar den Import an, aber wenn dieser fertig ist, dann ist die neue Tabelle leer (außer der Heart-Beat LED).
danke für den Hinweis. Ich werde mir das anschauen. Beides sollte richtig funktionieren. Ich werde aber wahrscheinlich erst ab Dienstag dazu kommen.
Stelle gerade fest dass der Export aus pyMLL und Import in pyMLL das gleiche Fehlerbild zeigt. Im Hintergrund sieht man wie Zeile für Zeile importiert wird. Sobald sich das Optionen-Fenster schließt ist zwar eine neue Tabelle angelegt, aber jungfräulich. Im Anhang mein logfile.log.txt
@Frank_TT Ich habe das gerade mal bei mir getestet. Ich habe 5 Zeilen in der DCC-Tabelle Exportiert, und dann wieder importiert.
Man sieht, daß die zeilen importiert werden. Danach spüringt das Programm zu einer anderen Tabelle - warum muß ich noch schauen. Wenn man dann aber zurück zur DCC Tabelle geht, sind dort die zusätzlichen Zeilen eingetragen.
Ist das bei dir auch so?
Kannst Du bitte genau die Schritte angeben, die Du gemacht hast, damit ich es nachvollziehen kann? Danke
Zitat von Eckhart im Beitrag #243Ich wundere mich nämlich, dass die LEDs der 511er nicht blinken?
Habe die Attinys nun mit der LED-Variante programmiert. Aber die zeigen immernoch permanent blau an. Egal was ich mache (z.B. ServoTest2, Makro programmieren)
Gruss Frank --------------------------------------------------------------------------------------------------------------------- MobaLedLib Forum und Wiki Mein Hauptfred Projekt "Bahnpark Augsburg" Stummitreff BB: jeden 3. Freitag im Monat im Haus Sommerhof in Sindelfingen
Zitat von hlinke im Beitrag #250Der 2. Fehler: Beim Import schreibt pyMLL in die Tabelle mit dem Namen, aus der Export geschrieben wurde. Dummerweise, springt es danach zu einer anderen Tabelle. Das muß ich noch überprüfen. Die importierten zeile sollten aber in der Ursprungstabelle angehängt sein. Kannst Du das bitte nochmal nachschauen. Sonnst wäre es gut, wenn ich eine genauere Anleitung hätte, was Du gemacht hast. Und evtl, Deine Export-Datei als Beispiel.
Mein Export ist im Anhang von Post#236 Die Tabelle hieß pyMLL3DMS. Diese Tabelle wird auch angelegt und dort die Einträge gemacht, bevor sie verschwinden. Auf dem Testnotebook hier war noch eine Tabelle DCC_1. Und dort finde ich den Import!
Die Funktion "Tabelle löschen" geht bei mir nicht, oder ich verstehe etwas anderes darunter. Es wird nur der Tabelleninhalt gelöscht (außer der Heartbeat-LED).
danke, habe die Datei bei den vielen Bildern übersehen. Der Fehler scheint zu sein, daß die pyMLL den Import IMMER in die DCC-Seite schreibt, anstatt in die angegebene Seite. Das muß ich mir morgen mal genauer anschauen. Danke für den Hinweis.
Das Löschen einer Seite löscht immer nur den Inhalt, nicht die Seite. Das ist genauso wie in der Excel-Version. Eine Funktion eine komplette Tabelle herauszulöschen, wäre aber wirklich nicht schlecht. Ich habe jetzt durch die Tests zwei neue Datenblätter mit "komischen" Namen, die ich nicht mehr los werde.
Schaue ich mir morgen auch an.
Zum Thema Kopieren: Kopieren einer Zeile funktioniert mit dem "Kopieren"-Button bei mir. Es geht nicht mit CTRL-C und Ctrl-V. da werden die LED-Nummern nicht übernommen.
Zitat von Eckhart im Beitrag #243Ich wundere mich nämlich, dass die LEDs der 511er nicht blinken?
Habe die Attinys nun mit der LED-Variante programmiert. Aber die zeigen immernoch permanent blau an. Egal was ich mache (z.B. ServoTest2, Makro programmieren)
Wenn du den ATTIny85 in der Tina, mit dem pyPG, programmiert hast, leuchtet dann auf der 400er Tina am Ende die blaue LED? (beschriftet mit "Reset as I/O Pin") Das sollte sie tun! Wenn sie es nicht tut, dann kannst du es manuell machen, indem du auf der 400er Tina den Taster "Chg Reset Pin" drückst, bis die blaue LED anfängt zu blinken und dann los lässt. Danach sollte die blaue LED dauerhaft leuchten.
Zitat von Eckhart im Beitrag #256Wenn du den ATTIny85 in der Tina, mit dem pyPG, programmiert hast, leuchtet dann auf der 400er Tina am Ende die blaue LED? (beschriftet mit "Reset as I/O Pin")
Nein, die blaue LED an der Tina bleibt aus.
Zitat von Eckhart im Beitrag #256Das sollte sie tun! Wenn sie es nicht tut, dann kannst du es manuell machen, indem du auf der 400er Tina den Taster "Chg Reset Pin" drückst, bis die blaue LED anfängt zu blinken und dann los lässt. Danach sollte die blaue LED dauerhaft leuchten.
Habe das gemacht. Hier im Video zu sehen:
Dann blinken die LED's an der 511er munter. Aber die Servos machen keinen Mucks.
Wenn ich den Attiny nochmals programmiere (mit der LED-Variante), danach aber NICHT per Taste die blaue Tina-LED zum leuchten bringe, dann funktionieren die Servos wieder, die 511er LED ist aber wieder permanent an.
Gruss Frank --------------------------------------------------------------------------------------------------------------------- MobaLedLib Forum und Wiki Mein Hauptfred Projekt "Bahnpark Augsburg" Stummitreff BB: jeden 3. Freitag im Monat im Haus Sommerhof in Sindelfingen
Zitat von Eckhart im Beitrag #256Wenn du den ATTIny85 in der Tina, mit dem pyPG, programmiert hast, leuchtet dann auf der 400er Tina am Ende die blaue LED? (beschriftet mit "Reset as I/O Pin")
Nein, die blaue LED an der Tina bleibt aus.
Dann blinken die LED's an der 511er munter. Aber die Servos machen keinen Mucks.
Wenn ich den Attiny nochmals programmiere (mit der LED-Variante), danach aber NICHT per Taste die blaue Tina-LED zum leuchten bringe, dann funktionieren die Servos wieder, die 511er LED ist aber wieder permanent an.
Das muss sich Harold mal angucken (wenn er seine 400er Tina zum Laufen gebracht hat) Da wird was falsch gefused sein.
Eigentlich nutzen wir alle, die Arduinao IDE, die Excel MLL und der pyPG, das selbe Tool avrdude, aber wir rufen es unterschiedlich auf. Wenn ich arvdude von der Kommandozeile oder aus einem eigenen Skript aufrufe, dann geht es.
ich nutze im Augenblick die RailMail-TinyServo_20240815.hex
Wenn ich den ATTINY mit der Tina flashen will (mit dem Script upload_hex.cmd)sollte die blaue LED auf der TINA aus sein, ist sie an, kurz Reset drücken, dann ist sie aus. Ist der ATTINY dann geflashed und der ATTINY in der Servo Platine, leuchtet die blaue LED auf der Servo Platine still vor sich hin und die Servo reagieren so wie sie sollen.
Wenn ich nun den ATTINY wieder in die TINA stecke, lange auf Reset drücke blinkt die blaue LED auf der TINA kurz auf und bleibt dann an. Wenn ich den ATTINY jetzt in die Servo Platine stecke, blinkt die blaue Kontroll LED auf dder Servo Platine etwa im 0.5 Hz Takt und die Servos arbeiten völlig normal.
Das gleiche Passiert auch wenn ich den geflashten chip nicht mit der Reset Taste in den IO Mode bringe, sondern das Script Set_Fuses.cmd aufrufe. Hat bei mir den gleichen Effekt wie langes Drücken auf den Reset Switch auf der Tina.
Was ich noch nicht verstehe, ab und zu fängt die blaue LED auf der Servo Platine wie "wild" an zu blinken, als ob sie mir etwas zumorsen will, aber nach einem Reset ist der Effekt weg und die LEDs blinken normal und die Servo machen was sie sollen, sich entsprechend der Programmierung bewegen.
Zitat von GerdR im Beitrag #259Was ich noch nicht verstehe, ab und zu fängt die blaue LED auf der Servo Platine wie "wild" an zu blinken, als ob sie mir etwas zumorsen will, aber nach einem Reset ist der Effekt weg und die LEDs blinken normal und die Servo machen was sie sollen, sich entsprechend der Programmierung bewegen.
Passiert das auf der/einer ERSTEN 511er Servo Platine, also der, die sich hinter einer WS2811 LED (z.B. Heartbeat, außer ESP32 102er) befindet, oder auf einer folgenden?
Die "wilden" Blinkcodes sollen eigentlich zeigen, dass man sich im Einstellmodus der Endlagen etc. befindet, aber bei einer FOLGENDEN 511er Platine ist es derzeit wohl eher eine Bit Fehlerkennung durch die Taktungenauigkeiten der hintereinandergehängten quarzlosen Tinys.
ich nutze im Augenblick die RailMail-TinyServo_20240815.hex
Ich verwende DM-TinyServo_20240815.hex was bei mir die neueste Version ist.
Gruss Frank --------------------------------------------------------------------------------------------------------------------- MobaLedLib Forum und Wiki Mein Hauptfred Projekt "Bahnpark Augsburg" Stummitreff BB: jeden 3. Freitag im Monat im Haus Sommerhof in Sindelfingen
ZitatNamen sind ja Schall und Rauch, aber die Version vom 15.08.2024 (....20240815.hex) ist die aktuelle und richtig!
Da gibts aber zwei Versionen,
einmal die DM-TinyServo_20240815.hex und einmal die RailMail-TinyServo_20240815.hex
Sind beide 12 kB groß, aber das hat nix zu bedeuten, nur ist die eine Datei in hex-files und die andere in hex-files_test. Welches ist den nun die richtige. Können wir uns da mal einigen wo die aktuelle Datei nun ist - von mir aus auch auf Git-Hub, aber dann bitte mit Ansage wo.
ZitatDie "wilden" Blinkcodes sollen eigentlich zeigen, dass man sich im Einstellmodus der Endlagen etc. befindet, aber bei einer FOLGENDEN 511er Platine ist es derzeit wohl eher eine Bit Fehlerkennung durch die Taktungenauigkeiten der hintereinandergehängten quarzlosen Tinys.
Stelle ich bei Servo 1-3 die Endlagen ein, blink die LED hektisch auf der ersten Servo Platine, die anderen blinken im 0,5 Hz Takt. Stelle ich Servo 4-6 ein, blinkt die Led auf der zweiten Platine hektisch und die anderen blinken still im 0,5 Hz Takt vor sich hin.
Hektisches blinken Nur beim Einstellen der Endlagen (End Pos und End Pos Spec), nicht bei Geschwindigkeit oder normalem Betrieb.
Schliesse ich die Servo Platinen an einem andern Anschluß als 1 am Verteiler an, erhöht sich die Nummer des Servos entsprechedn der Anzahl der vorher angeschlossenen LEDs. ( Ich hoffe das war klar ausgedrückt)
Nach dem "hektischen Blinken" dauert es einen kurzen Augenblick, so etwa 1 bis max 2 Sekunden bis sich der Blinkrhythmus wieder normalisiert hat.
ZitatNamen sind ja Schall und Rauch, aber die Version vom 15.08.2024 (....20240815.hex) ist die aktuelle und richtig!
Da gibts aber zwei Versionen,
einmal die DM-TinyServo_20240815.hex und einmal die RailMail-TinyServo_20240815.hex
Sind beide 12 kB groß, aber das hat nix zu bedeuten, nur ist die eine Datei in hex-files und die andere in hex-files_test. Welches ist den nun die richtige. Können wir uns da mal einigen wo die aktuelle Datei nun ist - von mir aus auch auf Git-Hub, aber dann bitte mit Ansage wo.
GerdR
Die beiden Dateien sind identiscxh. Für die "normalen" user, sind NUR die Dateien in hex-files nutzbar. Die Datein in hex-files_test sind test hex codes, die ich und Eckhart gerade testen und sollten NICHT von anderen benutzt werden.
@Eckhart: Das Datum hinter dem Namen ist das Datum, an dem ich die Datei von Dir bekommen habe. Die aktuelle Version, die Gerd benutzt ist also die, die Du mir am 14.8. Abends geschickt hast. Enthält also noch nicht die neuesten Änderungen, die wir gerade testen.
Das funktioniert alles wunderbar mit den Servos 1-3 und 4-6, ab Servo 7 blinkt die LED hektisch, Mal ja, Mal nicht, Die Endlagen lassen sich auch nicht sauber einstellen.
Der "Effekt" ändert sich wenn man einen anderen attiny85 benutzt, aber es wird nie so wie bei Servos 1 bis 6. Die Dinger haben anscheinend unterschiedliche Toleranzen, mal am oberen, Mal um unteren Ende und irgendwann addiert sich alles oder subtrahiert sich alles und der Attiny85 ist voll außerhalb der Toleranz.
Zitat von GerdR im Beitrag #265Kleines Update zu meinem obigen Versuch
Das funktioniert alles wunderbar mit den Servos 1-3 und 4-6, ab Servo 7 blinkt die LED hektisch, Mal ja, Mal nicht, Die Endlagen lassen sich auch nicht sauber einstellen.
Der "Effekt" ändert sich wenn man einen anderen attiny85 benutzt, aber es wird nie so wie bei Servos 1 bis 6. Die Dinger haben anscheinend unterschiedliche Toleranzen, mal am oberen, Mal um unteren Ende und irgendwann addiert sich alles oder subtrahiert sich alles und der Attiny85 ist voll außerhalb der Toleranz.
GerdR
Du könntest mal probieren die Tinys, nach Geschwindigkeit, zu "sortieren". Neben einer quarzgenauen Gleichtaktung ist nämlich auch das Prinzip der "Wasserfall-Kaskade" förderlich. Wenn du die Tinys mit funktionierender LED geflash hast, dann bleibt ja die LED beim Start für 5 Sekunden dauerhaft an und fängt dann an zu blinken. Versuch doch mal den Tiny, der als erstes aus geht und zu blinken anfängt ganz nach vorne zu machen (das ist der "schnellste"). Dann den, der als folgender anfängt zu blinken und den langsamsten an's Ende. Man kann das danach ganz gut sehen, dass das Blinken alles Tinys eine kaskadierte Form einnimmt.
So etwas werde ich auch künstlich implementieren, nur eben vom pyPG einstellbar. Genaue Gleichtaktung werden wir ohne Quarz nicht hinbekommen, aber durch das Markieren als 1, 2, 3. Chip kommen wir von einem "unbestimmten System" zu einem "bestimmten informatischen System".
Korrektur - load pgf-file: Die Programmzeilen werden jetzt in die neue Tabelle geschrieben - ESP32: Neue Firmware, Verbesserung beim direct mode interface New: - Servo-Anim markiert jetzt Ein/Ausschaltsequenzen und deren Ende mit einem speziellen Code, den der Attiny erkennen kann. Wenn der Attiny eine abgeschlossene Einschaltsequenz erkannt hat, werden ab da alle Pattern, die den Einschaltsequenzcode enthalten ignoriert. Dasselbe gilt für die Ausschaltsequenzen. Damit wollen wir verhindern, daß eine Sequenz, die z.B. nach einen Reset des Arduinos, wiederholt wird, ein zweites Mal abgespielt wird und zu ungewollten Sprüngen des Servos führt. Für diese Funktion ist die pyMLL ab V5.3.2c notwendig und die neue Firmware DM-TinyServo_20240831.hex. Diese Funktion benötigt eine saubere Datenübertragung. Deshalb bitte noch nicht mit 2 Attinys hintereinander ausprobieren.
Die "alte" Firmware DM-TinyServo_20240815.hex ist deshalb auch noch weiterhin verfügbar.
Korrektur - load pgf-file: Die Programmzeilen werden jetzt in die neue Tabelle geschrieben - ESP32: Neue Firmware, Verbesserung beim direct mode interface New: - Servo-Anim markiert jetzt Ein/Ausschaltsequenzen und deren Ende mit einem speziellen Code, den der Attiny erkennen kann. Wenn der Attiny eine abgeschlossene Einschaltsequenz erkannt hat, werden ab da alle Pattern, die den Einschaltsequenzcode enthalten ignoriert. Dasselbe gilt für die Ausschaltsequenzen. Damit wollen wir verhindern, daß eine Sequenz, die z.B. nach einen Reset des Arduinos, wiederholt wird, ein zweites Mal abgespielt wird und zu ungewollten Sprüngen des Servos führt. Für diese Funktion ist die pyMLL ab V5.3.2c notwendig und die neue Firmware DM-TinyServo_20240831.hex. Diese Funktion benötigt eine saubere Datenübertragung. Deshalb bitte noch nicht mit 2 Attinys hintereinander ausprobieren.
Die "alte" Firmware DM-TinyServo_20240815.hex ist deshalb auch noch weiterhin verfügbar.
Viele Grüße Harold
Noch eine kleine Ergänzung: Bitte führt, da sich die EEPROM Datenstruktur, zum zusätzlichen Speichern der Sequenz-Nummer, etwas geändert hat, einen kompletten "factory defaults" Reset aus, damit die alten Konfigurationsdaten nicht fehlinterpretiert werden!
Im Augenblick versuche ich rauszukriegen was da geändert sein soll( im Verhalten des Servos)
Was ich festgestellt habe ist das (bei mir) der Schalter 17 sich nicht mehr OFF (rot) schalten lässt, zwar auf ON (grün) schaltet, aber keine Funktion ON / Off hat, Über das DCC Keyboard lässt sich alles schalten.
Das irgendeine Sequenz / Bewegung gespeichert wurde, kann ich nicht sagen, der Servo muckt / zuckt genauso rum wie bei der xxx-20240815.hex. Nach einem Nano Reset kann es sogar passieren das man manuell den Nano verbinden muss, da er den USB Port nicht mehr findet.
Kleine Ergänzung: Ist es möglich in der Simulation / grafischen Darstellung nicht nur die Ortskurve zu speichern sondern auch die dazugehörige Servonummer /Servozahl.
Mit ein bisschen Ausprobieren bekommt man es tatsächlich hin das alle 3 LEDs blinken, nicht hektisch sondern ruhig und "gelassen". Es scheint da tatsächlich eine ganz schöne Streuung bei den ATTINYS zu geben. Mal sollte sich die dann tatsächlich markieren welcher Chip an welcher Position sitzt.
Zitat von hlinke im Beitrag #267 es gibt eine neue Version der pyMLL:
Korrektur - load pgf-file: Die Programmzeilen werden jetzt in die neue Tabelle geschrieben - ESP32: Neue Firmware, Verbesserung beim direct mode interface New: - Servo-Anim markiert jetzt Ein/Ausschaltsequenzen und deren Ende mit einem speziellen Code, den der Attiny erkennen kann. Wenn der Attiny eine abgeschlossene Einschaltsequenz erkannt hat, werden ab da alle Pattern, die den Einschaltsequenzcode enthalten ignoriert. Dasselbe gilt für die Ausschaltsequenzen. Damit wollen wir verhindern, daß eine Sequenz, die z.B. nach einen Reset des Arduinos, wiederholt wird, ein zweites Mal abgespielt wird und zu ungewollten Sprüngen des Servos führt. Für diese Funktion ist die pyMLL ab V5.3.2c notwendig und die neue Firmware DM-TinyServo_20240831.hex. Diese Funktion benötigt eine saubere Datenübertragung. Deshalb bitte noch nicht mit 2 Attinys hintereinander ausprobieren.
Habe gerade meinen Attiny85 die neue Firmware gespendet. Ich mußte bei allen 3 dann noch mit dem Taster der Tina die blaue LED zum leuchten bringen. Dann ein Factory Reset und zum ersten Mal reagieren die 3 Servos auf die Normalposition und die Endlagenprogrammierung wie man es erwartet!
Momentan nur 1 Attiny85 aktiv. Mit 2 oder 3 Platinen bekomme ich kein ruhiges Blinken wie Gerd hin.
Gruss Frank --------------------------------------------------------------------------------------------------------------------- MobaLedLib Forum und Wiki Mein Hauptfred Projekt "Bahnpark Augsburg" Stummitreff BB: jeden 3. Freitag im Monat im Haus Sommerhof in Sindelfingen
Gerd, was hast Du denn da für Elkos eingebaut? Die sind so niedrig. Ich habe 100µF 25V drin.
Gruss Frank --------------------------------------------------------------------------------------------------------------------- MobaLedLib Forum und Wiki Mein Hauptfred Projekt "Bahnpark Augsburg" Stummitreff BB: jeden 3. Freitag im Monat im Haus Sommerhof in Sindelfingen
ZitatGerd, was hast Du denn da für Elkos eingebaut? Die sind so niedrig. Ich habe 100µF 25V drin.
Das sind auch 100µF 25V Elkos. Die hab ich vor einiger Zeit Mal bei Reichelt bestellt.
Mit der neuen Firmware Krieg ich das auch ,(noch) nicht hin. Das Blinken funktioniert aber mit der xxx20240815 .hex Datei.
Statt der Resettaste auf der Tina kannst du auch das setfuse.cmd Script nehmen. Wenn das Script sauber durchläuft schaltet sich die blaue LED auf der Tina von alleine ein.
@GerdR Das ist einfach: Das sind die original Daten, die vom Excel Programmgenratorcode erzeugt werden. Im Excel sind sie durch die Buttons verdeckt. In pyMLL sind sie sichtbar - eigentlich auch um Fehler zu entdecken.
Der linke Eintrag bezieht sich auf den LED-ARDUINO und der rechte auf den DCC-ARDUINO. Die Daten werden intern für die Herstellung der Verbindung zum ARDUINO benötigt und in diesen Feldern zwischen gespeichert.
Wenn die Daten eher verwirren, sollte ich die auch unsichbar machen.
Im Augenblick versuche ich rauszukriegen was da geändert sein soll( im Verhalten des Servos)
Was ich festgestellt habe ist das (bei mir) der Schalter 17 sich nicht mehr OFF (rot) schalten lässt, zwar auf ON (grün) schaltet, aber keine Funktion ON / Off hat, Über das DCC Keyboard lässt sich alles schalten.
Das irgendeine Sequenz / Bewegung gespeichert wurde, kann ich nicht sagen, der Servo muckt / zuckt genauso rum wie bei der xxx-20240815.hex. Nach einem Nano Reset kann es sogar passieren das man manuell den Nano verbinden muss, da er den USB Port nicht mehr findet.
Kleine Ergänzung: Ist es möglich in der Simulation / grafischen Darstellung nicht nur die Ortskurve zu speichern sondern auch die dazugehörige Servonummer /Servozahl.
@Eckhart
Mit ein bisschen Ausprobieren bekommt man es tatsächlich hin das alle 3 LEDs blinken, nicht hektisch sondern ruhig und "gelassen". Es scheint da tatsächlich eine ganz schöne Streuung bei den ATTINYS zu geben. Mal sollte sich die dann tatsächlich markieren welcher Chip an welcher Position sitzt.
GerdR
Hallo Gerd,
so ganz helfen mir Deine Aussagen leider nicht weiter. Was ist "Schalter 17"? Was hast Du genau gemacht, damit ich das Problem reproduzieren kann? Am besten auch die log-Datei und evtl ein Export des benutzen Programms mit anhängen.
Hast Du folgendes gemacht: 1. die neue Hex-datei auf den Attiny übertragen 2. den Servo-Animator-Makro geöffnet und durch speichern den Pattern-Macro neuerstellen lassen (nur dadurch werden die neuen Funktionen aktiv) 3. Dann die neuen Macros zum ARDUINO hochgeladen
Punkt 1 hast Du gemacht. Hast Du auch Punkt 2 und 3 durchgeführt?
Zitat von GerdR im Beitrag #269@hlinke Kleine Ergänzung: Ist es möglich in der Simulation / grafischen Darstellung nicht nur die Ortskurve zu speichern sondern auch die dazugehörige Servonummer /Servozahl.
Gute Idee, das sollte möglich sein. Werde ich mir mal anschauen.
