Hallo Philipp,

daran hatte ich auch gedacht und das im Telefonat angefragt - leider nein ...

Hallo Frank,

tja, in den Holzabteilungen der Baumärkte stößt man überall auf diese magische Sicherheitsgrenze. Die Alternative ist der Gang zum Tischler, um die Zuschnitte anfertigen zu lassen. Die Präzision dürfte gegenüber den üblichen Plattensägen in den Holzabteilungen noch höher sein.
Mit meiner eigenen Kreissäge bin ich da fein raus ... obwohl, ein Ausbund an Präzision ist meine uralte Hobbysäge sicher nicht. Aber sie hat nix gegen Abschnitte im Millimeterbereich. Und ich lebe noch und die Finger sind alle dran. Vorsicht bleibt dabei die Mutter der Pozellankiste.

Ich will es zwar nicht verallgemeinern, aber ss gibt so manche "Sicherheitsvorschriften", die gerne als moralisch wirksamer Totschlaghammer eingesetzt werden. Der örtliche Baumarktmitarbeiter ist tatsächlich Tischlermeister. Der hat mir mal seine Ansichten anvertraut. Und aktuell habe ich gerade mein Projekt zum Aufbau einer Photovoltaikanlage auf unserem Reihenhausdach aufgegeben, da die so genannte Brandschutzverordnug offenbar als Steuerungsinstrument eingesetzt wird, um den Ausbau privater Energiegewinnung zu begrenzen. Da brennt sogar Glas ... das ist der Unterschied zwischen Sonntagsreden der grünen Politik und der behördlichen Realität. Es gibt noch mehr so Dinger, aber ich will Deinen Thread nicht mit meinem Frust über das gewollte Ausbremsen privater Initiative zuspammen.

Zurück zum Thema: Ein Zwischenaufenthalt des Zuges auf dem Tableau, um auf das Anfahren eines gegenüberliegenden Übergangs zu warten, ist sicher ein gangbarer Weg. Ich denke allerdings gerade an einen Fahrregler in den Händen meiner Enkelchen. Da wäre ich mir nicht sicher, ob sie eine Fuhre nicht einfach durchbrettern lassen. In dem Fall sollte man m.E. also einen programmierten Zwangsaufenthalt vorsehen, um die Modelle zu schützen.
Eine mechanisch betätigte Klappe an einem Ende als Ausgleich ist da nicht viel besser. Man kann darauf warten bis ein unvorsichtiger Lokführer seinen Zug in den Abgrund schickt. Mir will aber keine sinnvolle Mechanik einfallen, die in beiden Fahrrichtungen automatisch und ohne Versatz der Trassen an das jeweilige Tableauende andockt. Darüber brüte ich schon eine ganze Weile ...

LG
Hubert

Hallo,

nun habe ich lange nichts mehr von mir hören lassen - Lebt denn dr alte Holzmichl noch? Ja, und auch sein Projekt! Neue Bilder und ein Video hier https://photos.app.goo.gl/SnKLDL9YuwSaVQkt5, im folgenden nehme ich darauf Bezug.

Zum einen gab es noch ein paar andere häusliche Projekte, zum anderen quälte mich der Bau der Vitrine gedanklich - eben das magische Maß 50mm. Dazu habe ich erst einmal die verfügbare Tiefe aufgeteilt. Im ersten Bild des Albums seht ihr von rechts (Wand) nach links (auf 90° aufgeklappte Tür) das Maß 150mm, wirklich nicht viel. Apropos viel: viel Tiefe geht durch die Trägerplatte und die Linearführung drauf. Der folgende Höhenausgleich ist zwar durchaus optional, aber notwendig, um einen Teil der Vitrine über den Motor schieben zu können (sonst hätte es vertikal Platz = Ebenen gekostet - zumindest bei meiner Länge der Spindel; mit einer längeren Spindel hätte der Motor weiter oben = außerhalb der hochgefahrenen Vitrine liegen können).

Das nächste Bild zeigt den Probeaufbau. Die "Rückwand" ist ein Probierstück mit 3mm MDF. Hier kam es mir nur auf das Maß der vier Blockwagen an - 400mm Höhe entsprechen nicht der Zielhöhe 13*50+6,5 = 656,5mm. Die Breite ist aber genau die Zielbreite von 1000mm. Mit auf selbstklebendem Papier ausgedruckten Schablonen habe ich mir das Messen und Bohren erleichtert. Unten die senkrechte Stoppleiste (nur durch 1 von 4 Schrauben gesichert). Man ahnt, dass ich zu späterem Ein-/Ausbau der kompletten Vitrine (z.B. Wartung/Reparatur) nur zwei Möglichkeiten habe: Entweder komplett von unten einfädeln (vorher diese Leiste entfernen). Oder die unteren beiden Blockwagen vorher abmontieren und von oben auffädeln, dann die Blockwagen hinter der aufgefädelten Vitrine von vorn einschrauben. Aufgehängt ist die Vitrine durch Verschraubung mit der Kugelmutter, weil das am einfachsten ging. Bedenken, dass die Präzision der Parallelität von Linearschienen und Spindel nicht im erforderlichen Maße gegeben sind, waren unbegründet.

ABER. Ich erwäge immer noch Huberts Vorschlag, diese Verschraubung nicht zu machen, sondern eine Leiste hinter die Vitrine zu schrauben, die die Kugelmutter nach oben schieben kann und bei der auch auf dem Weg nach unten eine Mitnahme mithilfe des Kollegen Schwerkraft erfolgt - beides aber horizontal gegeneinander gleiten kann. Dumm nur: damit kann ich nicht von unten einfädeln und habe noch keine Idee, wie ich ohne diese Mitnahmeleiste von unten einfädeln und mit durch die Vitrine verdecktem Arbeitsbereich die Leiste von vorn anschrauben kann, vielleicht auch nicht so problematisch, wie es scheint - ggf. könnten Magnete helfen (die wiederum dem freien Spiel entgegenwirken). Hätte ich oben ausreichend Platz, könnte ich die gesamte Vitrine von oben einfädeln.

Der komische Balken rechts soll zur Prüfung der Einhaltung des späteren Spaltmaßes im Übergang zur Anlage (rechts) dienen. Ich habe ihn absichtlich sehr eng angelegt und - siehe Video - bin sehr zufrieden mit der (Nicht-)Veränderung des Spaltmaßes beim Hoch- und Runterfahren. Er wird im Regelbetrieb auf ein sinnvolles Maß erweitert (z.B. 0,5mm).

Nun zum Video: Der kleine ESP32 (Atom Matrix) leuchtet beim Einschalten mit einem stilisierten WLAN-Symbol rot und wechselt auf grün, wenn er sich mit meinem WLAN verbunden hat. Das geht so schnell (<0,5s), dass ich das gar nicht zeigen kann. +/- auf der Fernbedienung wechseln um eine Ebene hoch/runter. Das Geräusch der Lineartechnik ist sehr erträglich. Das manuelle schnelle Hoch-/Runterschieben der Konstruktion ist viel lauter, da hatte ich schon Bedenken bekommen. Die Spitzengeschwindigkeit werde ich vielleicht noch absenken, weil doch ein Heulen zu hören ist. Abwägung: Geräusch gegen Geschwindigkeit. Da ich die AccelStepper-Library benutze, die selbst ein Beschleunigen/Abbremsen realisiert, hört man im Video auch das Hin- und Herschalten der Anforderung der Ebenen: teilweise habe ich, während der Lift die Zieletage ansteuert, schon wieder eine in Gegenrichtung befindliche angewählt. Dann fährt er brav zur nächsten Ebene und beschleunigt rückzu zur nun neuen Zielebene. Sehr schön! Im Video seht ihr das schön gleich bleibende Spaltmaß. Wird doch immer das Karosseriespaltmaß bei deutschen Autos gelobt - ich bin noch einen Tick besser

Die Präzision der Ansteuerung (Bleistiftstrich) war bei Hin- und Herfahren sehr gut. Aber ... irgendwann gab es doch Abweichungen. These 1) Die AccelStepper-Library rechnet ganz leicht falsch und das macht sich bemerkbar. These 2) Ich arbeite ohne ENA(ble)-Signal im Sinne: Ich schalte es ab, nachdem die Bewegung erfolgt ist. Ich muss noch testen, inwieweit die nun nicht mehr 100% bestehende Haltekraft hier ein sehr kleines, sich aufsummierendes Nachgeben bewirkt (allerdings liegen die Ebenen im Vollschritt). These 2 ist für mich wahrscheinlicher - deren Lösung schiebe ich aber noch auf.

Ja, habe ich so viel über das Material und die Mindestbreite von 100mm gejammert. Nun habe ich mit Modulor (einem Architekturmaterialbedarfsladen in Berlin, versendet auch) jemand gefunden, der auf 50mm sägt (sofern die Breite mind. 500mm ist - ha! der Arbeitsschutz sagt offenbar nicht statisch >100mm, sondern bezieht die Anfassbarkeit des gesamten Werkstückes mit ein, liebe sonstige Säger!) Nun war ich weiterhin bei Forex. Und darauf fixiert. Dann fielen mir die Schuppen von den Augen - die 50mm gehen doch auch in Sperrholz! Damit habe ich Stabilität, ausreichende Formstabilität (Feuchtigkeit im Keller schwankt ohnehin nicht groß über die Jahreszeit) und kein Klebeproblem (Holzleim hält bombenfest). Einzig sieht natürlich eine weiße Vitrine eleganter aus. Vielleicht lackiere ich doch noch? Hielte auch die Feuchtigkeit im Zaume (Versiegelung) - mal sehen. Überdies plane ich nicht mehr mit 10mm Forex, sondern 6.5mm Sperrholz - die 3,5mm Höhengewinn kommen jeder Ebene zugute (und nicht einer zusätzlichen Ebene ).

Jedenfalls geht es so laaaangsam vorwärts, zumindest ab Juli, wenn der Urlaub vorbei ist, der und dessen Vorbereitung dazwischen kommt

Hallo,

inzwischen ist die Rückwand montiert und eine Probefahrt wurde gemacht:

Hallo,

Frustration macht sich breit. Von Jetzt auf Gleich spinnt der Lift. Anders als im Video zu hören, steigt mit der Beschleunigung nicht mehr der Ton bzw. fällt beim Bremsen ab. Der Lift läuft langsamer und auch gefühlt "kratziger".

Was ist passiert? Durch eine Unachtsamkeit schlug die Kugelmutter am Festlager an. Ich habe sofort ausgeschaltet. Danach lief alles normal. Habe zwei Hallsensoren für die Endlagenerkennung angeschlossen. Danach das Problem.

Fehlersuche konzentriert sich auf die drei geänderten Dinge: a) Mechanischer Anschlag, b) Hallsensoranschluss, c) Softwareänderung wegen Hallsensoren.

Da ich wesentliche Teile exakt doppelt da hatte (Treiber, Motor, ESP32), habe ich diese jeweils getauscht. Fehler unverändert. Software zurückgebaut auf den Stand vor Hallsensoranschluss. Fehler unverändert. Netzteil hatte ich nicht doppelt. Hat der Stromanstieg beim Anschlag es beschädigt (hätte eher eine Beschädigung des Treibers vermutet)? Gemessen: liefert auch unter Last 24V. Trotzdem einfach mal nachbestellt. Eben ausgetauscht: Fehler unverändert. Falls jemand auf einen mechanischen Schaden der Kugelmutter (der Kugelläufe) tippt: den ausgetauschten Motor hatte ich gar nicht mit der Spindel verbunden, er lief belastungsfrei.

Von der Kette Netzteil -> Treiber -> Motor und ESP32 -> Treiber ist alles bei der Fehlersuche berücksichtigt und eben ausgetauscht. Die Hallsensorkabel habe ich auch alle abgelötet. Habe ich auf der Platine mit Pfostensteckern, auf die der ESP32 aufgesteckt wird, etwas gebrückt? Durchmessen hat keine Kurzschlüsse zwischen den Pfostenpins ergeben.

Ich bin ratlos und frustriert. Gedanklich habe ich alle Fehlerquellen durchgespielt. Nun werde ich wohl mit den redundanten Teilen alles wieder auf einer Probierplatte neu aufbauen. Ich erhoffe mir nicht wirklich eine Ferndiagnose von euch - der Frust muss einmal raus. Mal sehen, wie es nach dem Urlaub weitergeht.

Hallo Frank,

das ist ja eine sch... (öne Bescherung).
Ich kann deine Frustration verstehen.

Dabei hat das im letzten Video alles so gut ausgesehen.
Ich war eher überrascht, dass der Lift sich recht langsam bewegt, hätte mit einer höheren Geschwindigkeit gerechnet.

Was mich echt wundert ist, dass der Fehler bleibt, auch wenn du alle relevanten Komponenten schon getauscht hast.
Das Netzteil würde ich auch ausschließen, zumal es auch unter Last 24V liefert.

Zitat von Lio im Beitrag #80

---

Falls jemand auf einen mechanischen Schaden der Kugelmutter (der Kugelläufe) tippt: den ausgetauschten Motor hatte ich gar nicht mit der Spindel verbunden, er lief belastungsfrei.

---

Hallo Frank,

gut, Stephans Vorschlag, dem Fehler die Chance zu geben, sich selbst zu reparieren, mag dem Defekt gefallen, da er so dem Schimpf und der Schande entgehen könnte. Mir wäre bei einer solchen Wunderheilung allerdings nicht recht wohl, da die Ursache verborgen bliebe.

Ich denke, wenn der systematische Austausch keine Veränderung bewirkt hat, bleibt nur das systematische Messen vor allem der elektrischen Größen. In dem Falle wären für mich zunächst die Strangströme des Schrittmotors spannend. Da der Stromverlauf reichlich wild sein dürfte, wäre ein Oszilloskop recht hilfreich.

Wenn dicke Ströme fließen, kommt es auch gerne zu Rückkoppelungen vom Energie- auf den Steuerteil. Gibt es eigentlich einen Optokoppler zur galvanischen Trennung zwischen ESP32 und dem Leistungstreiber? Falls nein ... hm ... dieser Umstand wäre ein Kandidat für die Fehlerursache..

Die Verdrahtung ist geprüft und durchgeklingelt? Keine Brüche, Querschittsminderugen oder so etwas? Elektronen sind ziemlich eigensinnig und nutzen jede Gelegenheit zur Arbeitsverweigerung. Gibt es nur ein kleine, winzige Brücke ... schwups ... schon läuft das arbeitsscheue Gesindel über den Weg mit dem geringsten Widerstand. Immerhin, darauf kann man sich verlassen. Und somit besteht eine reelle Chance, Kupferwürmer und Fehlerteufel zu finden bzw. zu vertreiben. Ich drücke die Daumen und bleibe zuversichtlich ...

LG
Hubert

Hallo Hubert,

sagen wir mal so, mein Vorschlag mit der "abwartenden Behandlung" und der Hoffnung auf "Selbstreparatur" war nicht ernst gemeint. (Ich hatte den vergessen.)

Zitat von hubedi im Beitrag #82

---

Mir wäre bei einer solchen Wunderheilung allerdings nicht recht wohl, da die Ursache verborgen bliebe.

---

Zitat von Lio im Beitrag #80

---

...., steigt mit der Beschleunigung nicht mehr der Ton bzw. fällt beim Bremsen ab. Der Lift läuft langsamer und auch gefühlt "kratziger".
....

---

Antwort auf die Schnelle ich hoffe darauf.

Nur habe ich den Stand vor den Änderungen wieder draufgespielt - mal nach dem Urlaub sehen, ob ich was übersehen habe. Habe auch die Libraryversion (AccelStepper) geprüft, denn die könnte ohne mein Zutun aktualisiert worden sein (Plattformio holt sich die neueste selbst, wenn man es im platformio.ini nicht ausschließt) - aber da hat sich seit längerem nichts geändert.

WIr werden sehen...

Viele Grüße
Frank

Hallo Frank,

ich würde mal auch auf ein Softwareproblem tippen. Wenn der Motor nicht mehr richtig angesteuert wird.... oder kann es sein das etwas Staub vom Sägen in die Mechanik geraten ist und an einer Stelle es schwergängiger läuft

Bin mal gespannt was du raus findest.

Hallo,

leider immer noch nichts Neues. Immerhin habe ich heute bemerkt, dass ein Ebeneninkrement statt 50mm sich 25mm bewegt. Aber die Parameter: Hub/Umdrehung = 5mm, Microsteps = 1600, mithin 16000 für 50mm sind gleich geblieben.
Ich habe nochmal die Software verglichen, nichts gefunden. Weitere Ratlosigkeit.

Oder gab es doch eine mechanische Beschädigung? Aber wie kann es sein, dass diese verursachen könnte, dass weniger Hub pro Umdrehung entsteht, und zwar in beide Drehrichtungen; die Kugelmutter macht keine absonderlichen Geräusche. Ich muss doch nochmal mit freiem Ersatzmotor ("frei" = nicht mit Spindel verbunden) und angeklebtem Fähnchen die Umdrehungen zählen (10 pro Ebenenhub erwartet). Wenn dieser Motor sich zehnmal dreht, liegt es an der Kugelmutter.

--- 5min später zurück aus dem Keller ---

Nein, auch der freilaufende andere Motor macht keine 10 Umdrehungen, etwa 4 1/2 (habe ich mich bei den 25mm etwas vertan -> 4,5 Umdrehungen ergeben 22,5mm).
Die Spindel ist also nicht schuld, aber eben der Fehler nicht gefunden. Ich werde wahnsinnig.

Nüchtern zusammengefasst: Das beobachtete Resultat im Vergleich zum Video, dass der Motor nicht mehr hörbar beschleunigt liegt daran, dass er gar nicht erst auf den Speed kommt, weil die Hubhöhe mit ~22,5mm zu klein ist. Ich messe jetzt ca. 8s für den Hub, während ich im Video (zum Glück hatte ich das gemacht, ich hätte sonst an mir gezweifelt) etwa 4s sehen kann. Welche nicht existierende SW-Änderung soll da dazwischengekommen sein ...

Hallo Frank,

ja, Deine Frustration ist mehr als verständlich. Da stimmt offensichtlich etwas nicht.

Hm ... für mich ist mein ursprünglicher geäußerter Verdacht noch nicht ausgeräumt. Wo dicke Ströme fließen, gibt es auf der Steuerseite gerne unangenehme Rückwirkung. Ich denke, Du kommst nicht weiter, wenn Du Deinen Aufbau bzw. die Software nicht auf das Allernotwendigste reduzierst und dann systematisch die potentiellen Fehlerquellen betrachtest. Sorry, wenn ich das so direkt sage, aber Deine bisherigen Versuche scheinen mir - zumindest Deiner Beschreibung nach - mehr dem Zufallsprinzip zu folgen. Das kann funktionieren ... oder auch nicht.

Ich weiß natürlich nicht, ob meine Methode tatsächlich den Erfolg bedeutet. Ich würde es so machen ... alles abklemmen, was nicht unmittelbar der Motoransteuerung dient. Dann eine Software einspielen, die nichts weiter macht, als den Motor ein paarmal langsam zu drehen. Wenn das klappt, wird die Komplexität Stück für Stück hinzugefügt ... Drehzahl schrittweise erhöhen, Beschleunigungs- und Abbremsalgorithmen hinzufügen ... usw.. Wenn es nicht funktioniert, steckt das Problem bereits im Simpelaufbau. Aber so zwingst Du den Fehler, sich irgendwann zu zeigen und dann, ja dann ... macht Du ihn platt. ... nee, wie brutal ... der arme Fehler ...

Das mag sich langweilig anhören, ungefähr so, als würde man einem Labyrinth dadurch entkommen, als würde man immer mit der rechten Hand an der Mauer entlanglaufen, egal wohin der Weg führt. Aber so ist früher oder später das Finden des Ausgangs unvermeidlich.

LG
Hubert

Hallo Hubert,

der Fehler hat wohl einen Stahlhelm auf und konnte noch nicht plattgemacht werden.

Ich denke schon, ich gehe systematisch vor. Ich habe zwei Verdachtsmomente anhand der letzten Änderungen, nachdem es lief, nämlich

• Das mechanische Auflaufen der Kugelmutter auf das Festlager
• Das Hinzufügen der Verkabelung der Endlagensensoren und diese selbst

  digitalWrite(driverENA, HIGH); 
 
  for (long i=0; i<16000L; i++) {
    digitalWrite(driverPUL, HIGH);
    delayMicroseconds(100);
    digitalWrite(driverPUL, LOW);
    delayMicroseconds(100);
  }
 
 

war er machtlos, ist dieser doch so minimalst (ich weiß, Herr Müller - mein letzter Deutschlehrer - das sagt man so nicht), dass nichts mehr geleugnet werden konnte. Der Stepper fährt anstandslos 5cm wie erwartet, 3s für diese Distanz ist hinreichend schnell und könnte durch kleinere Delays beschleunigt werden.

Was nur ist mit der Library los, dass sie bei gleichem Code nicht mehr funktioniert. Ich schrieb oben schon, PlattformIO komplett deinstalliert zu haben. Das stimmt, stimmt aber gleichzeitig auch nicht: ich bemerkte, dass die Deinstallation nicht restlos war; irgendwo in meinem Verzeichnis waren noch Reste - denn schließlich erinnerte sich VSCOde bei der Neuinstallation daran, dass ich doch das Platformio-Plugin benutze, und aktivierte es gleich. Da sollte es mich nicht wundern, wenn von einer - warum auch immer - korrumpierten Library die Reste stehen geblieben sein sollten. Dass ich die Library für korrumpiert und nicht für fehlerhaft halte, liegt an ihrer breiten Nutzerbasis - warum sollte ausgerechnet ich einen bisher unbemerkten Fehler finden, der durch seine kapitale Auswirkung doch jedem beim zweiten oder dritten Blick auffällt? Und es doch vorher auch bei mir funktionierte?

Ich habe jetzt zwei Möglichkeiten: den Ring um den Fehler so eng schnüren, bis ihm endgültig die Luft ausgeht, er den Unsichtbarmach-Zaubertrunk erbricht und mir schlotternd in die Augen schaut. Oder das Programm so verschlanken, dass es gänzlich auf die AccelStepper-Library verzichtet und das wenige, was ich brauche, doch selbst programmiere. Richtig ist, dass der Autor einiges Gehirnschmal in die Beschleunigungsberechnung gesteckt hat.

Jedoch dient diese nur zwei Zwecken bei mir: den Motor zu schonen (er hat ja keinen dynamischen Auslauf wie ein normaler Motor; genau das ist ja unerwünscht) und nicht abrupt von 0 auf 100 und umgekehrt zu gehen. Und die Züge beim Liften nicht hüpfen zu lassen. Bei letzterem ist zu bemerken, dass die Beschleunigung in z-Achse sich kaum auswirkt - längs (davonrollend) und quer (kippend) wäre die Größe der sich bemerkbar machenden Beschleunigung deutlich anders. Und: die Geschwindigkeit der Bewegung ist niedrig genug. Aber ich werde in die Motorschonung investieren, was als Nebeneffekt auch das Lifthüpfen der Züge beseitigt.

Bei eigenem Code habe ich auch die Performance im Griff: Der Autor der AccelLibrary spricht selbst von teuren Berechnungen. Ich habe - siehe oben - zweimal 100 Mikrosekunden Reserve für den Prozessor (das sind bei 16.000 Umdrehungen 3.200.000 Mikrosekunden = 3,2 Sekunden. Man sieht, dass die Fahrzeit so gut wie ausschließlich durch die Delays bestimmt wird. Diese Riesenreserve wird später noch durch die permanenten Abfrageloops des Buttons (Programmiermodus), der IR-Fernbedienung (eignetliche Ebenenwahl) und des WLANs (einmal für den Webserver für die entfernte Konfiguration, einmal für UDP, um remote Befehle entgegen nehmen zu können und einmal für OTA, um drahtlos Updates zu machen) teilweise wieder aufgefressen, mal sehen bis zu welchem Grad.

Ihr könnte euch vorstellen, dass ich jetzt VOLLKOMMEN ERLEICHTERT bin. Klar, den letzten Weg der Fehlerermittlung zu gehen wäre ganz nett, aber die Zeit investiere ich jetzt in die Beschleunigungsrechnung. Note to myself: delayMicroseconds() blockiert und lässt den anderen loops keine Luft - also eine nichtblockierende Variante codieren!

PS. Einige hatten "schon immer" auf die Software als Ursache getippt, aber sagt selbst: bei unverändertem Code meinerseits eine korrupte LIbrary (Arbeitshypothese) zu vermuten, die anfangs, aber nicht später, und in Teilen doch, funktionierte - wer kommt denn darauf ...

Hallo Frank,

ich sehe, Du bist bei Deiner Suche nicht weit von meiner Methode entfernt.

Hm ... die AccelStepper-Libary ist ja durchaus ein gewisser Standard und da sollten einfache Fehler eigentlich auszuschließen sein. Dynamische Effekte, gerade bei einem hochbelasteten Prozessor sind zwar nicht auszuschließen aber wenn alles andere abgeklemmt ist sollte Deine Steuerung mit einfachen Beschleunigungen bzw. dem Abbremsen des Motors nicht überfordert sein.

Hm ... sollte Deine IDE PlatformIO beim Compilieren doch etwas in den Code hineingetüddelt haben? Jage Dein Projekt doch mal z.B. durch die originale Arduino-IDE. Einen Versuch wäre es wert ...

LG
Hubert

Hallo,

es gibt ein Update zum softwareseitigen Stand des Projektes.

Zunächst noch zu Huberts Vorschlag, temporär auf die Arduino-IDE umzusteigen. Das wäre eine Möglichkeit, aber der Erkenntnisgewinn doch begrenzt. Wenn es funktioniert, wäre die Ursache dann in der PlatformIO-Installation zu suchen. Da ich mit der Arduino-IDE überhaupt nicht zufrieden bin (ich will nicht undankbar sein: sie bildete meine Einstieg in die Arduino-Welt, aber sie ist so mangelhaft, dass sie nicht für größere Projekte taugt), lasse ich das.

Nun aber zu meinen neuen Erkenntnissen. Zunächst habe ich also selbst ohne Library programmiert. Und es lief. Dann merkte ich aber - welch Überraschung - dass da noch ein "wenig" Gehirnschmalz fehlt. Nur ein Beispiel: Wenn während des Laufes eine Richtungsumkehr angefordert wird, weil sich der Bediener umentschieden hat, ist auch das zu berücksichtigen. Und zwar neben Bremsen, Richtungsumkehr und Wiederbeschleunigen so, dass kein einziger Schritt durch die Software ausgelassen oder hinzugefügt wird durch Ungenauigkeiten wie Runden: schließlich ist Kern des Stepper-Konzeptes, durch Schrittpositionen genau zu halten ohne Zusatzhardware für den Positionsabgleich.

Also dachte ich mir, nimmste mal die FastAccelStepper-Library. Diese funktionierte auf Anhieb. Also habe ich allen Code reaktiviert für die Steuerung, bspw. die IR-Fernbedienung. Und dann kam die Überraschung: Ich habe ja eine FB, welche minimalistisch ist. Ich habe nicht für jede Ebene eine Taste, sondern verwende + und -. Wenn ich also in Ebene n bin, führt +++ zum Zielwunsch Ebene n+3. Da beim ersten + der Lift losfährt, bedeuten die weiteren ++ also eine Zielveränderung während des Motorlaufes.

In meiner Testumgebung klappt das wunderbar, und der inzwischen hinzugefügte Code, der bei jedem + (oder -) gleich die neue Zielebene im Matrixdisplay anzeigt, gab auch gleich die visuelle Rückkopplung. Flugs umgesteckt in den Liftbetrieb. Und siehe da: Ich konnte wiederholt + drücken wie ich wollte, es wurde ignoriert. Erst, wenn der Stepper zum Stillstand (also nach einer Etage) kam, war er bereit, weitere + zu akzeptieren. Wie das, bitte? Ich programmierte den Taster der LED-Fläche um, so dass er die + - Funktion übernahm. Damit ging es. Wieso zum Kuckuck wird der IR-Befehl ignoriert? Die LED am Empfänger flackerte doch beim Drücken?

Da die FastAccelStepper-Library über einen Parameter blockierend oder nicht blockierend arbeiten kann, zweifelte ich ein wenig an ihr - sie wirkte, als ob sie blockierend wäre (nun, dagegen sprach allerdings die Reaktion auf Tasterdrücke). Jedenfalls kontaktierte ich den Entwickler. Mein Verdacht war, dass die Multi-Purpose-Ausgänge des ESP32 mit anderen Signalen überlagert wären. Er konnte mir nicht so recht helfen, verwies mich aber auf mögliche Inferenzen zwischen dem Motorlauf und dem IR-Signal.

Hah - konnte er mir also doch helfen! Die Spur wurde heiß, als ich nun genauer hinsah: das Flackermuster mit laufendem Stepper und ohne schien anders, und tatsächlich: die LED flackerte während des Stepper-Beschleunigens noch, als ich längst aufgehört hatte zu drücken.

Nun begann ich, einem Denkfehler hinterherzulaufen. Die Kabel für den Stepper und für den IR-Empfängers verlaufen parallel im kleinen Kabelkanal. Ich legte die des IR-Empfängers soweit es ging aus dem Kabelkanal heraus. Das Übersprechen blieb. Mein Denkfehler bestand darin, das ausgehende Signalkabel des IR-Empfängers (welches also codiert die Taste liefert) als Ursache auszumachen und daher von den Stepperkabeln zu separieren, aber Flackern tut der Empfänger, wenn er (vermeintlich) ein IR-Signal empfängt (nicht, wenn er das Ergebnis sendet), die Signalleitung liegt also schon hinter der Ursache.

Das bedeutet, dass die Leitungen zum Stepper tatsächlich ein Signal aussenden, welches der IR-Empfänger als IR-Signal auswertet. Erfolg wird wohl mehr darin liegen, diese Leitung zu schirmen. Die Pulsleitung führt derzeit Pulse im 4kHz-Takt (HIGH für wenige Mikrosekunden, Low den Rest des Taktes).

Ich bin noch nicht bei der Lösung, aber in diese Richtung müsste sie gehen. Können das besser Elektronik-Affine als ich bitte mal kommentieren? Wie kann ein elektromagnetisches Signal einen IR-Impuls auslösen - oder ist vielmehr das elektromagnetische Signal für die IR-Empfänger-Platine schon hinter dem eigentlichen Sensor angesprochen? Darauf gibt es allerdings keine Elektronik, nur die LED und einen Widerstand: https://www.conrad.de/de/p/iduino-148532...oUaAiYJEALw_wcB

Wie würdet ihr eine ordentliche Schirmung ausführen?

Hallo Frank,

Deine Beschreibung hört sich durchaus plausibel an. Weiter oben hatte ich ja schon den Verdacht geäußert, die schnöde Hardware könnte für diese Probleme verantwortlich sein. Deine Frage am Ende Deines Beitrags kann ich mit einem klaren ja beantworten. Eine solche Übertragung von Signalen geschieht bereits bei weitaus kleineren Strömen, als sie bei einem Stepper fließen. Die Eingänge eines Mikrocontrollers sind potentiell empfindlich genug, um die übertragenen rechteckförmigen Schaltsignale des Steppers aufzunehmen und das Programm zu verwirren. Gerade Rechtecksignale weisen hohe Frequenzanteile auf, die eine solche Signalübertragung stark begünstigten.

Was kannst Du nun machen, um ein solches "Übersprechen" zu minimieren? Zunächst gibt es zwei Ansätze. Erst einmal hilft ein räumlicher Abstand zwischen potentiellen Störquellen und dem IR-Empfangsteil. Dazu zählen ich u.a. eine getrennte Leitungsführung. Schön parallel geführte und möglicherweise noch zu einem Strang verbundene Leitungen mögen zwar nett aussehen, sind aber aus elektrischer Sicht kontraproduktiv und potentiell störanfällig.
Nicht selten hilft es zweitens, die Leitungen zu verdrillen. Etwas vereinfacht ausgedrückt erreicht man mit dieser Maßnahme eine abschnittsweise Vertauschung der elektromagnetischen Polarität und damit ein gewisses gegeseitiges Auslöschen der Störungen. Diesen "Trick" wendet man bei eigentlich allen Signalübertragungsleitungen z.B. in Netzwerken oder im Telefonbereich an.
Wenn der Infrarotempfänger (oder z.B. ein anderer Sensor) über eine längere Strecke angeschlossen werden muss, ist hier zusätzlich eine abgeschirmte Leitung sicher empfehlenswert. Es gibt dazu spezielle Steuerleitungen aber Du kannst auch eine gewöhnliche 8-pol. Leitung nehmen, wie sie zum Anschluss eines Rechners an das LAN überall für kleines Geld zu bekommen ist. Im einfachsten Fall schneidest Du die vorhandenen Stecker ab und entfernst zum Anschluss die äußere Ummantelung. Der Schirm in Form eines Drahtgeflechtes oder der Folienumwicklung rund um den Kern aus verdrillten Adernpaaren wird nun sichtbar. Der Schirm wird an einem Ende elektrisch mit Masse verbunden. Für die Signalübertragung nimmst Du ein verdrilltes Adernpaar. Bitte achte darauf, dass die Verdrillung bis unmittelbar vor den Anschlusstellen erhalten bleibt. Bereits wenige Zentimeter ohne Verdrillung können sich mit Störungen bemerkbar machen.

Da fällt mir gerade noch etwas ein ... wie ist der IR-Empfänger mit dem Eingang des Mikrocontrollers verbunden? Liegen dort Widerstände, die für klare Potentialverhältnisse sorgen, wenn gerade kein Signal ansteht?

LG
Hubert

Hallo Frank,

immerhin hast du jetzt einen Ansatz, der zur Lösung des Problems führen könnte.

die 4 kHz auf der Leitung zum Stepper-Treiber sind schon ordentlich.
Das gibt schöne steile Flanken, und damit "ganz tolle" Oberwellen mit vielfachen von 4 kHz. (Stichwort: Fourieranalyse )
Es kommt dann zu einer Induktiven Kopplung zwischen den Leitungen (Übersprechen).
Das wird zwar bei höheren Spannungen und Strömen immer schlimmer, aber es kann auch bei kleinen Spannungen / Strömen vorkommen (hast du ja bei dir).
Gerade da die Eingänge des µC ja recht hochohmig sind funktioniert dieses Einkoppeln super.

Gegenmaßnahmen:
Räumliche Trennung - verdrillen - schirmen - filtern - niederohmige Datenübertragung
(von links nach rechts steigt der Aufwand der Maßnahmen )

Mit der Idee von Hubert ein LAN-Kabel zur Übertragung, und zusätzlich noch den Abstand der Leitungen möglichst groß zu halten, erschlägst du schon mal die ersten 3 Punkte mit relativ geringem Aufwand (und Kosten). Auf den Rest solltest du dann verzichten können.
Ob man den Schirm nun nur auf einer Seite oder auf beiden Seiten der Leitung auf Masse legt ... das scheint eher eine Glaubensfrage zu sein. Da gehen auch bei uns in der Firma die Meinungen auseinander (der Eine sagt so, der Andere so )

Zusätzlich noch am Eingang des µC, an dem der IR-Empfänger angeschlossen ist, ein Pullup- (oder Pulldown-)Widerstand (gerne genommen 10 kOhm), je nach dem ob dein Signal aktiv-high oder aktiv-low ist. Pullup-Widerstände sind ja manchmal schon im µC integriert und können im Programm aktiviert werden.
Was auch nicht schaden kann, wäre direkt am IR-Empfänger zwischen der 5V-Versorgung und GND einen kleinen Kondensator (100nF wären da so eine Hausnummer) einlöten, der filtert / stabilisiert die Versorgung es Moduls etwas.

Grüße,
Stephan

Hallo Frank,
meine Erfahrungen mit Schrittmotoren sind:
Leitungen zwischen Steppertreiber und Steppermotor sollen
1. so kurz wie möglich sein
2. müssen ab einer gewissen Länge je Kanal verdrillt und in Gesamtheit geschirmt sein.
3. Der Schirm muss am Treibermodul und am Motor aufgelegt sein, darf dabei aber nur einmalig geerdet werden. Wird 2x geerdet entstehen Schleifen die zur Abstrahlung von Störungen führen können.
4. Power-Zuleitung von Netzteil zu Steppertreiber verdrillt ausführen.
5. ein Low-ESR-Elko // 100nF Keramikkondensator am PowerIn des Treiber kann nicht schaden.
6. Die Stepper-Treiber haben üblicherweise Optokoppler als Eingänge. Niemals aus Sparsamkeitsgründen + oder - der Eingänge zusammenfassen. Immer getrennte, verdrillte Aderpaare zur Steuerkarte führen.
Software notfalls auf einem zweiten Rechner installieren, nur so kannst du sicher sein dass von gelöschten Programmen eventuell Reste dazwischenfunken.
Volker

Hallo Volker, Stephan, Hubert,

besten Dank für eure Hinweise. In die Richtung wird es dann gehen (räumliche Trennung und ggf. noch Schirmung).

Zitat von hubedi im Beitrag #92

---

Da fällt mir gerade noch etwas ein ... wie ist der IR-Empfänger mit dem Eingang des Mikrocontrollers verbunden? Liegen dort Widerstände, die für klare Potentialverhältnisse sorgen, wenn gerade kein Signal ansteht?

---

Zitat von E16-06 im Beitrag #93

---

Zusätzlich noch am Eingang des µC, an dem der IR-Empfänger angeschlossen ist, ein Pullup- (oder Pulldown-)Widerstand (gerne genommen 10 kOhm), je nach dem ob dein Signal aktiv-high oder aktiv-low ist. Pullup-Widerstände sind ja manchmal schon im µC integriert und können im Programm aktiviert werden.

---

Zitat von volkerS im Beitrag #94

---

6. Die Stepper-Treiber haben üblicherweise Optokoppler als Eingänge. Niemals aus Sparsamkeitsgründen + oder - der Eingänge zusammenfassen. Immer getrennte, verdrillte Aderpaare zur Steuerkarte führen.

---

Hallo Frank,

die Abstandslehren sind eine prima Idee.

Was hindert Dich daran, die Mitte des nächsten Trassenbretts z.B. mit einer Lehre anzuzeichnen, die Rückwand auf dieser Linie zu durchbohren und von hinten Schrauben in die Trassenbretter zu drehen?

Das Anzeichnen der Mittellinie könnte auch ein Bleistift erledigen, den Du in die Nut des nächsten Brettes klemmst. Wenn Du die Lehre auf dem letzten Brett hin- und herschiebst, ist die Mitte des nächsten Brettes bereits markiert. Natürlich musst Du in diesem Fall auch die Trassenbretter für die Schrauben vorbohren, damit das Brett beim Eindringen der Schrauben nicht aufgespalten wird. Das ist aber auch kein Hexenwerk, wenn Du einfach durch die Löcher der Rückwand hindurch mit einem entsprechend dünneren Bohrer in das von den Lehren gehaltene Trassenbrett bohrst.

Diese kleine Zusatzarbeit würde m.E. das Aufleimen enorm erleichtern und auch in der Mitte der Trassenbretter für den notwendigen Anpressdruck beim Anziehen des Leims sorgen.

Ich hoffe, ich habe mich einigermaßen verständlich ausgedrückt ...

LG
Hubert

Hallo,

ich habe mich lang nicht mehr gemeldet und möchte daher mal einen Zwischenbericht geben.

Zunächst noch die Antwort auf

Zitat von hubedi im Beitrag #96

---

Was hindert Dich daran, die Mitte des nächsten Trassenbretts z.B. mit einer Lehre anzuzeichnen, die Rückwand auf dieser Linie zu durchbohren und von hinten Schrauben in die Trassenbretter zu drehen?

---

Hallo Frank,

schön das du noch dabei bist und nicht aufgegeben hast. Hast du schon eine Lösung wie du die Gleisspannung auf die einzelnen Ebenen bekommst?

Gruß Olli

Hallo Olli,

viele planen (bei Digital) Gleisbelegtmelder, damit die Mobasteuerung dann auch auf Block einfahren kann. Obwohl meine Anlage digital ist, mache ich das nicht - mir reicht ein Auf-Sicht-Fahren in den Lift bzw. das einfache Herausfahren. Außerdem habe ich einige Kurzzüge, von denen mehrere auf ein Gleis sollen. (Ja, mit zusätlichen Meldern ginge auch das, aber ich bin nicht Krösus.)

Bis hierhin hätte es genügt, einfach alle Gleise ständig mit Digitalspannung zu versorgen - d.h. ein zweipoliges Schleppkabel an die Rückseite des Lifts und von dort auf alle Gleise verteilen.

Aber von meinen ~100 Loks sind etwa die Hälfte noch nicht digitalisiert, so dass ich einen Mischbetrieb plane: Umschalter an der Anlage: auf "digital" - volle Flexibilität beim Fahren, doch darf sich kein Analogfahrzeug auf der Anlage befinden. Auf "analog" - Digitalfahrzeuge dürfen auf der Anlage bleiben, jede CV29 ist so eingestellt, dass sie auf Analogsteuersignale nicht reagieren. Im Modus "analog" kommt die Gleisversorgung nicht mehr von der Zentrale, sondern einem Analogregler (d.h. zweipoliger Umschalter). Jetzt darf nur ein analoges Fahrzeug auf die Anlage - nachdem es durch ist (wieder im Zuglift) dann ein anderes. Eine Abwandlung wird sein, dass ich vielleicht doch ein paar Bf-Abschnitte abschaltbar mache, so dass dann mehrere Analogfahrzeuge da sein dürfen. Das ist so lang temporär, bis 100% des Fuhrparks umgestellt ist, danach bleiben die Schalter ständig auf EIN.

Daraus folgt, dass ich mindestens die Gleise des Zuglifts, die Analogfahrzeuge beherbergen sollen, abschaltbar machen muss. Der Einfachheit halber werden ALLE Gleise des Zuglifts abschaltbar gemacht, um die volle Flexibilität zu behalten. Ich wandele daher die oben geschilderte ständige Versorgung um: die Rückwand des Liftes erhält drei parallele streifenförmige, senkrecht angebrachte Leiter. Diese werden zwischen den Ebenen unterbrochen (praktisch eine strichlierte Linie), jeder Abschnitt wird mit den zwei Gleisen der Ebene verbunden: 1 gemeinesamer Rückleiter und je 1 Schiene. Von der Rückwandebene V schleifen nun drei Schleifer auf ebendiesen Leitern. Die Schleifer erhalten ständige Versorgung von digital/analog (ja umschaltbar). Dadurch erhält immer nur die Ebene das Analog- oder Digitalsignal, die auf Höhe der Zufahrt steht. Warum drei Schleifer? Weil in jedem der beiden Stromkreise ein Schalter eingefügt wird - nur für den Analogmodus benötigt - so dass ich beide stromerhaltende Gleise der Ebene separat abschalten kann - eben genau für den Analogbetrieb.

Bei 100% Digitalbetrieb könnte ich dann wieder beide Schalter auf EIN stellen. Ein Nebeneffekt dieser selektiven Ebenenversorgung ist, dass nicht alle Gleise, auch nicht später, gleichzeitig Digitalspannung erhalten und somit nicht alle Digitalfahrzeuge ihren Ruhestrom gleichzeitig abrufen (Boosterdimensionierung, wozu einen eigenen für den Zuglift?). Und ebenso ist nebenbei verhindert, dass ein falscher Zug angewählt wird und losfährt. Nein, nicht gegen den Abgrund - da wird es noch eine seitliche Blende zur Sicherheit geben, aber auch gegen diese muss ja nicht versehentlich gefahren werden.

Ich hoffe, ich konnte mich einigermaßen verständlich ausdrücken.

PS. Macht den Sekt auf - mein 200. Beitrag (ok - macht sich gegen die meisten anderen etwas kümmerlich ...)

Hallo Frank,

Zitat von Lio im Beitrag #99

---

PS. Macht den Sekt auf - mein 200. Beitrag

---