Raspberry Pi 2b Java Stepper Schrittverlust

[Marinus O. (marinus_o)]

Guten Tag,
Ich arbeite derzeit an einer Lineareinheit, bei welcher ich zwei 
Positionslaser unabhängig von einander verstellen möchte. Die 
Soll-Positionen und Geschwindigkeit soll über Ethernet übertragen 
werden. Die verstellung erfolgt über 2 Schrittmotoren. Für meinen 
Prototypen verwende ich derzeit einen Raspberry Pi 2b. Ein Arduino 
scheidet aus, weil dieser keine mehreren Threads gleichzeitig abarbeiten 
kann.(Thread1: Datenübertragung Ethernet. Thread 2: Steuerung Motor1. 
Thread 3: Steuerung Motor2.) Die Programmierung des Pi erfolgt über 
Java, weil ich mir dort am besten auskenne(vielleicht liegt hier schon 
der Fehler). Die Schrittmotoren werden über Treiber angetrieben, welche 
bei jedem Puls einen Schritt machen. Erste Testläufer funktionierten 
ohne Probleme, mit einer ausnahme! Alle 2 sek gibt es eine kleine 
unterbrechung, welche meine Schrittmotoren zucken lässt und somit einen 
Schrittverlust verurschacht. Leider hab ich es nicht geschaft den Fehler 
zu lokalisieren. Im Programm selbst liegt er meines erachtens nicht, 
sondern eher am Pi, bzw an der JavaVm. Ich würde jetzt nur gerne wissen, 
ob von euch jemand weiß was diese unterbrechung verursacht und ob es 
eine möglichkeit gibt diese zu beheben.
Java version
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)

Video von Probelauf:
https://youtu.be/O2YVv54Shoo
Die Schrittverluste sind nicht zu sehen, sondern nur zu hören.
Es sind diese leisen Schläge, die man ab und zu hört. Nach 10 min 
Probefahrt sind die Schrittverluste auch deutlich zu sehen.

Imports:
PI4J

[my2ct (Gast)]

Marinus O. schrieb:
> Ein Arduino scheidet aus, weil dieser keine mehreren Threads gleichzeitig
> abarbeiten kann.(Thread1: Datenübertragung Ethernet. Thread 2: Steuerung
> Motor1. Thread 3: Steuerung Motor2.)

Kein Prozessor, sofern er nicht mehrere Kerne besitzt, kann mehrere 
Dinge gleichzeitig abarbeiten. Der Rest ist eine Frage der 
Programmierung.

p.s. Längeren Programm-Code kannst du als Anhang in einer Datei 
hochladen. Ansonsten empfiehlt sich für vernünftige Formatierung die 
Verwendung von passenden Tags (C bzw. Code)

[Marinus O. (marinus_o)]

@my2ct
Der Pi besitzt 4 Kerne.
Das Problem beim Arduino war, dass der befehl um Udp pakete zu lesen 3ms 
dauert und mir in der Zwischenzeit das Programm block.Dies ist bei der 
ansteuerung von Schrittmotoren fatal. Selbst Protothreading kann dieses 
Problem nicht lösen.

[Markus F. (mfro)]

Marinus O. schrieb:
> der befehl um Udp pakete zu lesen

Bist Du sicher, daß deine Steuerbefehle nicht schon da verloren gehen?

[Marinus O. (marinus_o)]

Markus F. schrieb:
> Marinus O. schrieb:
>> der befehl um Udp pakete zu lesen
>
> Bist Du sicher, daß deine Steuerbefehle nicht schon da verloren gehen?

Im derzeitigen Projekt ist noch gar keine Übertragung realisiert, nur 
ein kleines Testprogramm, welches Fixe positionen abfährt(Siehe 
Quellcode). Zudem wird ja nicht der Stuerbefehl gesend, sondern nur die 
nächste Position, und die Geschwindigkeit mit welcher gefahren werden 
soll.

[Mikro 7. (mikro77)]

Dein Quelltext lädt nicht gerade zum Lesen ein...

Versuche doch das Problem auf ein paar Zeilen zu isolieren.

Wie sieht deine Schnittstelle eigentlich aus (Ansteuerung, Timing, 
Pegel) und wie dein Use-Case?

Was sagt dein Logicanalyzer? Stimmt die Ausgabe mit dem überein wie du 
dir das vorgestellt hast?

[Patrick J. (ho-bit-hun-ter)]

Hi

Regelmäßiges Zucken deutet doch auf einen Überlauf oder ein sich 
'aufbauendes' Problem hin.

Lassen sich die Problemstellen reproduzieren?
Wandern Diese mit, wenn Du schneller/langsamer fährst?
Bei längeren Rampen auch?

Oder kommt alle 2 Sekunden ein 'bist Du noch wach' vom PC und der µC 
wartet auf Daten, Die nicht kommen und bis zum TimeOut haben die Stepper 
sich bereits verhaspelt?

MfG

[Kaj G. (Firma: RUB) (bloody)]

Marinus O. schrieb:
> Im Programm selbst liegt er meines erachtens nicht
Am Sprit kanns nicht liegen, is naemlich keiner drin...

[c-hater (Gast)]

Marinus O. schrieb:

> Der Pi besitzt 4 Kerne.

Ja, und?

> Das Problem beim Arduino war, dass der befehl um Udp pakete zu lesen 3ms
> dauert und mir in der Zwischenzeit das Programm block.

Dann hätte man eben keinen blockierenden Ansatz verwenden dürfen, wenn 
einen die Blockierzeit stört.

> Dies ist bei der
> ansteuerung von Schrittmotoren fatal.

Ja klar, 3ms sind eine kleine Ewigkeit für schnell bewegte 
Schrittmotore.

> Selbst Protothreading kann dieses
> Problem nicht lösen.

Keine Ahnung.

Fakt ist: Es geht sogar noch eine Ebene unter diesem Overhead-belasteten 
Gerümpel (sehr praktisch, wenn man eben nur EINEN Core hat und/oder 
keine praktikable Möglichkeit für schnelle Kontextwechsel): man nutzt 
für alles und jedes Interrupt- und/oder DMA-basierte Lösungen. So wie 
Gott (bzw. kompetente Hardware-Entwickler) es gewollt haben, als sie µP 
und µC mit Interrupts/DMA ausgestattet haben, und wie es kompetente 
Programmierer auch umzusetzen in der Lage sind...

Dieser ganze Threading-Kram ist doch im Kern kaum mehr als ein 
Workaround um die Inkompetenz der meisten Software-Entwickler. Einen 
Sinn ergibt er sowieso erst, wenn tatsächlich mehrere Kerne verfügbar 
sind. Und auch dann ist er eher nicht dazu geeignet, kurze Antwortzeiten 
für IO sicherzustellen, sondern vor allem dazu, hohe Rechenlast auf die 
vorhandenen Kerne zu verteilen. Nur mit vielen, vielen Tricks im 
Scheduler kann Multithreading  inzwischen auch (wenigstens einigermaßen 
gut) mit IO umgehen, zumindest bei manchen OS.

Je kleiner das Metall, desto eher kann es das nicht.

[RP6conrad (Gast)]

Auf den Pi lauft doch Linux, und damit wird regelmassig ihre Java 
Program unterbrochen für andere Sachen. Wenn und Wie hasst du nicht in 
Griff, das entscheidet das Betriebssystem. Ich habe auch so etwas 
bemerkt by ein Python Sketch.

[Marinus O. (marinus_o)]

c-hater schrieb:


> Fakt ist: Es geht sogar noch eine Ebene unter diesem Overhead-belasteten
> Gerümpel (sehr praktisch, wenn man eben nur EINEN Core hat und/oder
> keine praktikable Möglichkeit für schnelle Kontextwechsel): man nutzt
> für alles und jedes Interrupt- und/oder DMA-basierte Lösungen. So wie
> Gott (bzw. kompetente Hardware-Entwickler) es gewollt haben, als sie µP
> und µC mit Interrupts/DMA ausgestattet haben, und wie es kompetente
> Programmierer auch umzusetzen in der Lage sind...
>
> Dieser ganze Threading-Kram ist doch im Kern kaum mehr als ein
> Workaround um die Inkompetenz der meisten Software-Entwickler. Einen
> Sinn ergibt er sowieso erst, wenn tatsächlich mehrere Kerne verfügbar
> sind. Und auch dann ist er eher nicht dazu geeignet, kurze Antwortzeiten
> für IO sicherzustellen, sondern vor allem dazu, hohe Rechenlast auf die
> vorhandenen Kerne zu verteilen. Nur mit vielen, vielen Tricks im
> Scheduler kann Multithreading  inzwischen auch (wenigstens einigermaßen
> gut) mit IO umgehen, zumindest bei manchen OS.
>
> Je kleiner das Metall, desto eher kann es das nicht.

Danke c-hater für diese hilfreiche Kritik. Ich habe mich ehrlichgesagt 
wirklich von dieser ganzen Thread-Geschichte verwöhnen lassen. Ich werde 
mich mal nochmal auf meinen Arduino stürzen und schauen, ob ich es nicht 
doch hinbekomm, mit Interrupts.

[Stefan F. (Gast)]

> Ein Arduino scheidet aus, weil dieser keine mehreren Threads
> gleichzeitig abarbeiten kann

Das kann er sehr wohl. Man muss es nur programmieren können. Es ist kein 
Hexenwerk.

> Die Programmierung des Pi erfolgt über Java

Für solche Anwendungen ist das nicht die richtige Sprache. Java 
Programme haben keine vorhersagbare Reaktionszeit. Der Garbage Collector 
wird dir jedes schöne Timing versauen.

> Im Programm selbst liegt er meines erachtens nicht,
> sondern eher... an der JavaVm

Richtig erkannt. Mit Java wirst du das nicht sauber gelöst bekommen. 
Auch das Betriebssystem wird dich am Erfolg hindern, da es dein Programm 
nach Belieben pausiert.

Für solche zeitkritischen Sachen nimmt man immer einen Mikrocontroller, 
der seine Befehle vom "großen" Computer erhält. Diese Befehle sagen dann 
zum Beispiel:

- Fahre 2cm nach vorne, dann stopp.
- Drehe bis auf Widerruf mit n Umdrehungen pro Sekunde links herum.
- Fahre den Aufzug bis zur 3. Etage.

Solche Befehle kann der Mikrocontroller dann umsetzen, unabhängig davon 
ob das steuernde Hauptprogramm mal ein par Millisekunden lang pausiert.

Was die Multi-Threading Programmierung angeht, informiere Dich zum Thema 
"Zustandsautomaten". Einen passenden Aufsatz im Kontext eines Embedded 
Webservers habe ich hier hinterlassen: 
http://stefanfrings.de/net_io/protosockets.html

[Mikro 7. (mikro77)]

Ich kann in der Aufgabenstellung keine Echtzeitanforderung sehen:

Marinus O. schrieb:
> Ich arbeite derzeit an einer Lineareinheit, bei welcher ich zwei
> Positionslaser unabhängig von einander verstellen möchte. Die
> Soll-Positionen und Geschwindigkeit soll über Ethernet übertragen
> werden.

Interessant wird es wenn eine Flankensteuerung nicht ausreicht, also 
Timings beachtet werden müssen (bspw. Pulse, die der TS ansprach) oder 
es tatsächlich (andere) RT Anforderungen gibt.

Aus dem Userland kann man ggf. Trial/Error-Detection/Fallback/Retry 
implementieren (das klappt bis einige 100kHz).

Glücklicherweise bietet der Pi aber auch einiges an Peripherie 
(generische Serializer/FIFO/DMA), womit sich RT Probleme lösen lassen. 
Ggf. bietet sich auch ein (Interrupt-gesteuerten) Kernel Modul an.

[Stefan F. (Gast)]

Ab einer gewissen Masse und Drehzahl kann der Schrittmotor nicht mehr 
mit beliebigen Schritten gesteuert werden. Er ist nicht stark genug, die 
Masse abrupt anzuhalten, dreht sich also weiter als gewollt.

Der Motor muss sanft beschleunigen und sanft abbremsen. Wenn das 
steuernde Programm, dass die Impulse erzeugt, zwischendurch mal 
pausiert, ist das Timing versaut.