Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03234.jsonl.gz/2447

Im Rahmen der Diplomarbeit der Techniker Schule an der IBZ in Brugg erstellte ich eine Software, mit dessen Hilfe drei Schrittmotoren angesteuert werden konnten.
Um dieser extrem genauen Ansteuerung von drei Schrittmotoren einen Sinn zu geben, erstellte ich einen 50cm x 50cm grossen Plotter.
Wie immer bei grösseren Projekten, wurden die wahren Probleme erst sichtbar wenn das Ende der Arbeit in Sichtweite ist.
Die Programmiersprache (C#) und die Entwicklungsumgebung (Visual Studio 2005) waren gesetzt, doch wie lässt sich damit eine Echtzeit-Anwendung und eine Kommunikation mit den Schrittmotoren realisieren? Eine Anforderung, die ich als Web-Entwickler noch nie begegnet bin!
Man muss ja nicht alles selber machen… Und im Zeitalter von Internet und Google findet man viele Lösungsansätze. Ich habe mich für die NTPort.dll von zealsoftware.com entschieden. Damit lässt sich die Drucker-Schnittstelle (USB war damals noch kein Thema) ansteuern.
Es musste also nur noch festgelegt werden, welcher Code, welchen Schnittstellen-Pin ansteuert und wie dieses Signal auf der Gegenseite von den Schrittmotoren interpretiert werden musste, damit diese sich in die richtige Richtung bewegten. Ein gesendeter Impuls entspricht somit einem Schritt im Schrittmotor. Je nach verwendeten Schrittmotoren mussten somit für eine volle Drehung 360 oder 400 Impulse gesendet werden.
Ein anderes Problem war die Geschwindigkeit: Werden die Signale 1:1 vom PC an die Schrittmotoren gesendet, können die Schrittmotoren nicht reagieren, weil sie die einzelnen Signale nicht erkennen können (= Erfahrungsbericht )
Der erste Lösungsansatz für dieses Problem war der Falsche: Sende ein Signal, zähle von Eins bis Tausend, sende ein weiteres Signal, zähle wieder von Eins bis Tausend….
Die Schrittmotoren erkennen zwar die Signale, der Computer-Prozessor ist jedoch zu 100% ausgelastet und somit blockiert: In diesem Zustand kann kein anderes Programm geöffnet werden.
Den gewünschten Erfolg brachte das Threading: Das funktioniert so: Sende ein Signal, schlafe für 500 Millisekunden, sende ein weiteres Signal, schlafe dann wieder für 500 Millisekunden….
Die Schrittmotoren erkennen die Signale und die Prozessorauslastung ist bei ca. 2%. Somit können auch andere Programme gleichzeitig weiterarbeiten.
Die Verwendung von Threads bringt noch zwei weitere Vorteile mit sich:
- Die Ausführungsgeschwindigkeit ist nicht abhängig von der Leistungsfähigkeit des Computers. (Die 500 Millisekunden bleiben immer 500 Millisekunden)
- Es können Anfahr- und Bremskurven programmiert werden: Die Motoren starten langsam, erreichen dann die maximale Geschwindigkeit und werden zum Schluss wieder langsamer.
Das grösste Problem erkannte ich erst bei den ersten Praxistests! Also sehr spät und was noch viel schlimmer war: Keine Ahnung wie man es lösen könnte!
Das laufende Programm konnte nicht unterbrochen oder gestoppt werden! Und es kam noch viel schlimmer: Das Programm stoppe auch nicht, wenn der Plotter versuchte ausserhalb des druckbaren Bereiches zu zeichnen!
Es mussten somit zwei Lösungen gefunden werden:
- Das Programm muss erkennen, wenn der Benutzer das Programm abbricht.
- Das Programm muss erkennen, wenn der Plotter den druckbaren Bereich verlassen will.
Als Erstes mussten an den Enden des druckbaren Bereiches Kontakte angebracht werden: Wenn sich die Kontakte berühren, wird ein Signal vom Plotter an die Schnittstelle gesendet. (Anstelle von mechanischen Kontakten würde ich heute Lichtschranken einsetzen) Die Schnittstellen-Steuerung musste erweitert werden: Signale werden nun nicht nur gesendet sondern müssen auch empfangen und korrekt weitergeleitet werden.
Der Programmcode mit Plotteranweisungen mussten in einen separaten Plotter-Thread ‚verpackt‘ werden, welcher vom Haupt-Thread gestartet wurde. Bei einem Unterbruch (Durch Benutzer oder ein empfangenes Signal von der Schnittstelle) musste der Haupt-Thread wieder die Kontrolle übernehmen und den Plotter-Thread abbrechen.