Forum

Der Teufel steckt im Detail! Mir ist ein Dreher bei den Vergleichsoperatoren passiert. Ersetze mal alle (falschen) "=!" durch (korrekte) "!=". Eigentlich hätte der Kompiler da eine Fehlermeldung auswerfen müssen.

--
Es ist unter der Würde eines Technikers, die Gebrauchsanweisung zu lesen!

» Der Teufel steckt im Detail! Mir ist ein Dreher bei den
» Vergleichsoperatoren passiert. Ersetze mal alle (falschen) "=!" durch
» (korrekte) "!=". Eigentlich hätte der Kompiler da eine Fehlermeldung
» auswerfen müssen.
Ha! Ist mir auch nicht aufgefallen. Jetzt sieht es schon etwas besser aus.
Der MCP... wird im Automatik-Modus abgefragt, es erfolgt aber keine Impulsausgabe, nur das Quittierungs-Signal wird ausgegeben.
Auf CLK und DIR ist keine Aktivität (laut Oszilloskop auch nichts hochfrequentes).

Du setzt CLK sofort von LOW auf HIGH, kann das stimmen?

» impulslaenge = millis() + schrittmotortakt; // für schrittmotor handmodus
» digitalWrite(clkPin, HIGH); // taktimpuls
» digitalWrite(clkPin, LOW);
» while (impulslaenge > millis()) {} // warten

Ich habe dann
» digitalWrite(clkPin, LOW);
mal unter die while-Schleife gesetzt, das bringt leider auch nichts.

» Der MCP... wird im Automatik-Modus abgefragt, es erfolgt aber keine
» Impulsausgabe, nur das Quittierungs-Signal wird ausgegeben.
» Auf CLK und DIR ist keine Aktivität (laut Oszilloskop auch nichts
» hochfrequentes).
Wenn das Quittierungssignal ausgegeben wird, heißt das, dass im Automatikbetrieb die Variable "motorschritte" den Wert 0 hat und im Handbetrieb der Eingangspin LOW ist.
Hast du denn die Kodierschalter samt der dazugehörigen Elektronik überhaupt angeschlossen? Falls ja, haben die Digits die richtige Wertigkeit? Und hast du die Vergleichsoperatoren in den anderen beiden Verzögerungsschleifen ebenfalls korrigiert (es sind insgesamt 3) ?
Eventuell kannst du testweise für "motorschritte" im Programm einen festen Wert vorgeben.

»
» Du setzt CLK sofort von LOW auf HIGH, kann das stimmen?
»
Bei den Schrittmotor-Treibermodulen, die ich benutze (DAYCOM ST-A4988), funktioniert das, auch mit dem RPi pico, der deutlich kürzere Impulse ausgibt als der Arduino. Du kannst ja testweise zwischen
digitalWrite(clkPin, HIGH);
und
digitalWrite(clkPin, LOW);
ein delay(...) von 1 oder 2 Millisekunden setzen. Dann ist das Signal auch auf dem Oszi besser zu sehen.

» » impulslaenge = millis() + schrittmotortakt; // für schrittmotor
» handmodus
» » digitalWrite(clkPin, HIGH); // taktimpuls
» » digitalWrite(clkPin, LOW);
» » while (impulslaenge > millis()) {} // warten
»
» Ich habe dann
» » digitalWrite(clkPin, LOW);
» mal unter die while-Schleife gesetzt, das bringt leider auch nichts.
Natürlich nicht. Die Schleife wird nur so lange durchlaufen, wie das Eingangssignal (an Pin 9) HIGH ist.

EDIT: DIR wird nur HIGH, wenn während der Torzeit genau 2 fallende Flanken gezählt wurden.

--
Es ist unter der Würde eines Technikers, die Gebrauchsanweisung zu lesen!

» ausgibt als der Arduino. Du kannst ja testweise zwischen
» digitalWrite(clkPin, HIGH);
» und
» digitalWrite(clkPin, LOW);
» ein delay(...) von 1 oder 2 Millisekunden setzen. Dann ist das Signal auch
» auf dem Oszi besser zu sehen.
DANKE.
Habe überall ein delay(1); eingefügt.
Das war der Trick, jetzt gibt es auch Impulse.
Bezüglich der Oszillogramme:
1. gelb=PULS
2. cyan=DIR
3. magenta=Triggerimpuls

Da DIR immer auf HIGH geblieben ist, habe ich diesen Ausgang am Ende der jeweiligen Impuls-Unterprogramme auf LOW gesetzt.
Allerdings ist die Pausenzeit nur beim Ersten PULS 1ms, alle weiteren haben 2ms.


Ansonsten funktioniert der Automatik-Modus wie gewünscht. Die Anzahl der Impulse entsprechend BCD-Schalter stimmt auch auffallend.


Nur der Hand-Modus schaltet sich nicht ab...


Mit diesem Zwischenergebnis bin ich aber schon sehr zufrieden

» Da DIR immer auf HIGH geblieben ist, habe ich diesen Ausgang am Ende der
» jeweiligen Impuls-Unterprogramme auf LOW gesetzt.
Das kannst du machen, notwendig ist es aber nicht. DIR wird jeweils vor Beginn der Bewegung auf den richtigen Wert gesetzt. Solange keine Taktimpulse ausgegeben werden, ist der Pegel von DIR nicht von Belang.

» Allerdings ist die Pausenzeit nur beim Ersten PULS 1ms, alle weiteren haben
» 2ms.
Eigentlich sollte die Pause zwischen zwei Taktimpulsen um die 100ms liegen, entsprechend der Konstante "schrittmotortakt" im Header. Irgendwas läuft da noch nicht so, wie es soll. Hast du den Vergleichsoperator in der markierten Zeile korrigiert?

while (motorschritte > 0) { // vorgewählte anzahl von schritten ausgeben
impulslaenge = schrittmotortakt; // wartezeit zwischen zwei motorschritten
digitalWrite(clkPin, HIGH); // taktimpuls
digitalWrite(clkPin, LOW);
motorschritte--; // schritte herunterzählen
while (impulslaenge > 0) { // impulslänge abwarten
if (zeitmerken != millis()) { // timer hat weitergezählt <<<<<<<<< so ist es korrekt <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
------------------- ^^^
impulslaenge--; // wartezeit herunterzählen
zeitmerken = millis(); //neuen timerwert merken
}
}
}

»
» Ansonsten funktioniert der Automatik-Modus wie gewünscht. Die Anzahl der
» Impulse entsprechend BCD-Schalter stimmt auch auffallend.
Dann habe ich ja scheinbar richtig geraten.

»
» Nur der Hand-Modus schaltet sich nicht ab...
Die Zeile

while(digitalRead(handPin == 1)) { // impulse ausgeben, solange taste gedrückt ist

ist auch nicht ganz korrekt. Richtig muss es heißen

while(digitalRead(handPin == HIGH)) { // impulse ausgeben, solange taste gedrückt ist

Die "0" für "LOW" bei den anderen "digitalRead"-Abfragen ist ebenfalls nicht korrekt, die scheint der Arduino allerdings richtig auszuwerten.

EDIT: Hier eine bereinigte und korrigierte Version des Programms. Die Zeitschleifen habe ich auch etwas vereinfacht.

https://www.elektronik-kompendium.de/forum/upload/20260214202307.ino

--
Es ist unter der Würde eines Technikers, die Gebrauchsanweisung zu lesen!

» EDIT: Hier eine bereinigte und korrigierte Version des Programms. Die
» Zeitschleifen habe ich auch etwas vereinfacht.
Ich sag's nur ungern, aber jetzt funktioniert es nicht mehr.
Ein Durchlauf geht noch korrekt. Ein zweiter Durchlauf erzeugt noch CLK Impulse, aber ein QUIT mehr. Alle folgenden Eingangssignale lösen dann überhaupt keine Aktion mehr aus

Der HAND-Eingang wurde ja wegoptimiert. Den kannst du in deiner Version des Programms auch entfernen/durch den SIGNAL-Eingang ersetzen.

P.S.: Danke für eine unermüdliche Arbeit, und dass du "noch nich in Sack jehauen hast"

» Ich sag's nur ungern, aber jetzt funktioniert es nicht mehr.
Diesmal wegen einer falsch gesetzten Klammer. Statt

else { // handmodus
while(digitalRead(handPin == HIGH)) { // impulse ausgeben, solange taste gedrückt ist

muss es richtig heißen:

else { // handmodus
while(digitalRead(handPin) == HIGH) { // impulse ausgeben, solange taste gedrückt ist

Der Einfachheit halber hier noch einmal der komplette korrigierte Quelltext:
https://www.elektronik-kompendium.de/forum/upload/20260216233319.ino

»
» Der HAND-Eingang wurde ja wegoptimiert. Den kannst du in deiner Version des
» Programms auch entfernen/durch den SIGNAL-Eingang ersetzen.
Kann, muss aber nicht. "signalPin" und "handPin" haben den gleichen Wert, sie sprechen also den selben Pin an. Falls du -warum auch immer- irgendwann beschließen solltest, das Ganze wieder zurückzubauen, brauchst du dann zur Anpassung des Programms einfach nur den Wert von "handPin" im Header zu ändern.

»
» P.S.: Danke für eine unermüdliche Arbeit, und dass du "noch nich in Sack
» jehauen hast"
Na ja, wenn ich sowas anfange, habe ich schon den Ehrgeiz, es zum Laufen zu bringen. Das ist ja auch für mich ein Erfolgserlebnis.

--
Es ist unter der Würde eines Technikers, die Gebrauchsanweisung zu lesen!

» » Programms auch entfernen/durch den SIGNAL-Eingang ersetzen.
» Kann, muss aber nicht. "signalPin" und "handPin" haben den gleichen Wert,
» sie sprechen also den selben Pin an.
Wusste gar nicht, dass das geht. Dann lasse ich es so.

Leider ist immer noch irgendwo der Wurm drin.
Nach zwei Programmdurchläufen geht nichts mehr, und beim zweiten wird der Wert vom BCD-Schalter sogar falsch zurückgegeben.

» Leider ist immer noch irgendwo der Wurm drin.
» Nach zwei Programmdurchläufen geht nichts mehr, und beim zweiten wird der
» Wert vom BCD-Schalter sogar falsch zurückgegeben.
So ein Verhalten deutet im Allgemeinen darauf hin, dass entweder irgend ein Wert nicht korrekt zurückgesetzt wurde oder sich das Programm irgendwo "verlaufen" hat. Ich kann beim Durchsehen aber nichts derartiges entdecken. Dann werde ich wohl doch mal meinen Arduino mit dem Programm füttern und sehen, was der dazu sagt.

Spiel mal das hier auf

https://www.elektronik-kompendium.de/forum/upload/20260218123446.ino

und sag mir, ob die eingebaute LED angeht oder nicht.

Außerdem bekomme ich hier beim Kompilieren eine Warnmeldung, die die Bibliothek "wire" betrifft. Kommentiere mal probeweise den ganzen Block aus, der die Kodierschalter ausliest und setz "motorschritte" auf einen festen Wert.

--
Es ist unter der Würde eines Technikers, die Gebrauchsanweisung zu lesen!

» So ein Verhalten deutet im Allgemeinen darauf hin, dass entweder irgend ein
» Wert nicht korrekt zurückgesetzt wurde oder sich das Programm irgendwo
» "verlaufen" hat.
Offenbar.

» werde ich wohl doch mal meinen Arduino mit dem Programm füttern und sehen, was der dazu sagt.
Das wäre klasse. Dann sparen wir uns das ganze hin und her.

» Spiel mal das hier auf
»
» https://www.elektronik-kompendium.de/forum/upload/20260218123446.ino
»
» und sag mir, ob die eingebaute LED angeht oder nicht.
Geht im Normalbetrieb nicht an.
Wenn ich mehr als zwei Eingangsimpulse generiere aber schon, und so ist es ja wohl auch gedacht.

» Außerdem bekomme ich hier beim Kompilieren eine Warnmeldung, die die
» Bibliothek "wire" betrifft. Kommentiere mal probeweise den ganzen Block
» aus, der die Kodierschalter ausliest und setz "motorschritte" auf einen
» festen Wert.
Da ist das Fehlerbild gleich.

So, ich denke, jetzt hab ich's.

https://www.elektronik-kompendium.de/forum/upload/20260222205112.ino

Das Timing der Portpins ist etwas eigen. Offenbar braucht der Arduino (zumindest der UNO) eine gewisse Zeit, um die Pegel an den Pins zu setzen oder auszulesen, während das Programm schon weiterläuft. Sehr seltsam. Der Programmablauf scheint auch sonst nicht ganz gleichmäßig zu sein, die Finessen bei den Zeitschleifen habe ich mir daher gespart. Wenn du den Arduino also länger als 49 Tage am Stück laufen lässt, könnte es zu einem Programmabsturz kommen. Mit diesem Damoklesschwert über deinem Haupt musst du jetzt halt leben.

Die eingebaute LED leuchtet jetzt während der Torzeit und wenn ein Fehler auftritt. Zum Testen habe ich die Torzeit um eine Sekunde verlängert. Dreimal den Taster drücken in einer Viertelsekunde habe ich auch mit viel Üben nicht geschafft.

EDIT: Nachdem das Programm beim Testen zwischendurch immer mal wieder "abgeschmiert" ist, habe ich das Timing etwas geändert. Jetzt scheint es stabil zu laufen, und ich habe den neuen Quelltext noch einmal hochgeladen (oben, neuer Link).

--
Es ist unter der Würde eines Technikers, die Gebrauchsanweisung zu lesen!

» EDIT: Nachdem das Programm beim Testen zwischendurch immer mal wieder
» "abgeschmiert" ist, habe ich das Timing etwas geändert. Jetzt scheint es
» stabil zu laufen, und ich habe den neuen Quelltext noch einmal hochgeladen
» (oben, neuer Link).
Danke nochmals
Bei mir funktioniert es auch.
Die Taktfrequenz habe ich für die gedachte Anwendung wesentlich vergrößert (schrittmotortakt=1ms). Diese Variable habe ich auch in die delay() Funktionen für die Takterzeugung eingebaut, sodass sich jetzt gleichmäßige Rechtecke mit 1ms Puls- und Pausenzeiten und damit eine maximale Frequenz von 500Hz ergibt. Bei 400 Impulsen (maximale Einstellung der Endstufe) pro Umdrehung ergeben sich 75U/min an der Motorwelle. Schneller muss es wohl nicht sein, und langsamer geht ja eh immer.
Die Inbetriebnahme an der Maschine steht aber noch aus...

» » EDIT: Nachdem das Programm beim Testen zwischendurch immer mal wieder
» » "abgeschmiert" ist, habe ich das Timing etwas geändert. Jetzt scheint
» es
» » stabil zu laufen, und ich habe den neuen Quelltext noch einmal
» hochgeladen
» » (oben, neuer Link).
» Danke nochmals
» Bei mir funktioniert es auch.
» Die Taktfrequenz habe ich für die gedachte Anwendung wesentlich
» vergrößert (schrittmotortakt=1ms). Diese Variable habe ich auch in die
» delay() Funktionen für die Takterzeugung eingebaut, sodass sich jetzt
» gleichmäßige Rechtecke mit 1ms Puls- und Pausenzeiten und damit eine
» maximale Frequenz von 500Hz ergibt. Bei 400 Impulsen (maximale Einstellung
» der Endstufe) pro Umdrehung ergeben sich 75U/min an der Motorwelle.
» Schneller muss es wohl nicht sein, und langsamer geht ja eh immer.
» Die Inbetriebnahme an der Maschine steht aber noch aus...

Na ja, dann besteht ja noch Hoffnung...
Dass du das Timing noch an deine Erfordernisse anpassen musst, war ja von vornherein klar, meine Werte waren nur eine Arbeitshypothese, um das Ganze überhaupt ans Laufen zu kriegen. Da wirst du erfahrungsgemäß auch noch einige Feinarbeit reinstecken müssen, bevor alles zufriedenstellend läuft, z.B. unterschiediche Taktraten für Hand- und Automatikbetrieb, oder eine ansteigende Taktrate beim Handbetrieb, je länger die Taste gedrückt wird.

Das seltsam träge Verhalten der IO-Pins ist wohl Absicht und der Tatsache geschuldet, dass der Arduino (UNO) hauptsächlich für Lehr- und Ausbildungszwecke entwickelt wurde. Das Ansprechen einzelner Portpins sollte wohl "idiotensicher" gemacht werden, um z.B. Kontaktprellen von Schaltern hardwaremäßig abzufangen. In den Programmbeispielen der verschiedenen Tutorials steht auch nach einem "digitalWrite(..." meistens noch ein "delay(10)", der Grund dafür wird aber nirgendwo genannt.
Der Zugriff geht allerdings auch schneller, indem man die Portregister direkt anspricht, das wirkt dann aber immer auf 8 Pins gleichzeitig (Portregister = 1 Byte), man muss sich also um das korrekte Setzen oder Löschen einzelner Bits selber kümmern.

--
Es ist unter der Würde eines Technikers, die Gebrauchsanweisung zu lesen!

» Na ja, dann besteht ja noch Hoffnung...
Zurecht, dadd Progrämm'sche funktioniert ausgezeichnet

Jetzt gehen natürlich die Sonderwünsche nach einer Drehzahlsteuerung los

Mit der Taktrate von 500Hz ist der Motor zu langsam, bzw. als Minimalfrequenz noch akzeptabel. Ein Stellbereich von 500Hz bis 5kHz über ein Potentiometer wäre schön.
Das sollte ja generell mit delaymircoseconds("skalierter Potiwert" anstatt delay("Festwert" in den 'Takt-Schleifen' machbar sein...Ooooder? Auf absolute Präzision kommt es ja wieder nicht an.

» » Na ja, dann besteht ja noch Hoffnung...
» Zurecht, dadd Progrämm'sche funktioniert ausgezeichnet
Das freut mich.
»
» Jetzt gehen natürlich die Sonderwünsche nach einer Drehzahlsteuerung los
»
»
» Mit der Taktrate von 500Hz ist der Motor zu langsam, bzw. als
» Minimalfrequenz noch akzeptabel. Ein Stellbereich von 500Hz bis 5kHz über
» ein Potentiometer wäre schön.
» Das sollte ja generell mit delaymircoseconds("skalierter Potiwert" anstatt
» delay("Festwert" in den 'Takt-Schleifen' machbar sein...Ooooder? Auf
» absolute Präzision kommt es ja wieder nicht an.
Kein Problem. Hast du noch einen Analogkanal frei?

--
Es ist unter der Würde eines Technikers, die Gebrauchsanweisung zu lesen!