Andyh hat geschrieben:Ich will diesmal gleich alles in eine GUI bauen.
Das hat Vor- und Nachteile. Ein Vorteil wäre, dass du dir die Kommunikation mit einem anderen Programm sparen kannst. Vielleicht wird dadurch das Programm weniger komplex.
Ein Nachteil ist, dass du die wichtigen Dinge nicht mehr von den unwichtigen trennen kannst.
Was ist oft wichtig? Z.B. die Ansteuerung der Schrittmotoren im richtigen Takt. Das sofortige Unterbrechen, falls ein Kommando von einem Taster kommt. (obwohl ich bei einem Notfalltaster eher zu einer kompletten Stromabschaltung des Gerätes tendieren würde)
Was ist oft unwichtig? Viele Teile der GUI. Die Anzeige des Fensterhintergrundes. Die schnelle Aktualisierung der Anzeige von Messdaten. Die Anzeige einer Statuszeile oder eines kleinen Bildchens zum Auflockern der Arbeitsoberfläche.
Wenn du ein Programm hast, welches die Steuerung der Fräse über hat, dann kannst du dieses Programm mit einer höheren Priorität laufen lassen, damit z.B. das Aufpoppen einer unwichtigen Update-Meldung das Programm nicht so sehr verlangsamt.
Das ist ja der wichtigste Teil des Programms. Dieser bekommt auf jeden fall einen eigenen Thread. Vielleicht ist es sogar ratsam, diesen Teil in ein eigenes Programm auszulagern.Andyh hat geschrieben:- Schrittmotor anzeuern
Die Schrittmotoransteuerung hat ja immer die aktuellen Werte parat. Diese musst du vom GUI-Programm aus nur alle (sagen wir mal) 80 Millisekunden abrufen und anzeigen. Wenn die Schrittmotorsteuerung ein eigener Prozess ist, dann rufst du die aktuelle Position z.B. per XMLRPC ab. Das setzt voraus, dass in der Schrittmotorsteuerung, ein kleiner XMLRPC-Server eingebaut ist. Aber das bedeutet ja kaum 100 Zeilen mehr Code -- ist also leicht verwirklichbar.Andyh hat geschrieben:- Maschinenposition mitrechen und anzeigen (in Labels)
Lass in der GUI einen Timer laufen, der alle 80 ms die Schrittmotorsteuerung anruft um die aktuelle Position zu ermitteln. Diese neue Position kann dann im selben Schritt angezeigt werden.Andyh hat geschrieben:- die drei Labels in der GUI mit der aktuellen Pos. aktualisieren
Notschalter sollten unabhängig von irgendeinem Computer funktionieren und einfach alles abschalten.Andyh hat geschrieben:- Endschalter überwachen (wenn ein signal über den LPT kommt muss die maschine anhalten)
Unabhängig davon. Falls du noch einen der Kanäle "Error", "PaperOut" oder "Selected" frei hast, dann kannst du das eventuell darüber erledigen. Das habe ich noch nie ausprobiert.
Das sicher nicht. Ein Thread für die Schrittmotorsteuerung. Ein Thread für den XMLRPC-Server. In der GUI kannst du recht viel mit Timer machen.Andyh hat geschrieben:Wenn ich weiter mache braue ich irgendwann mal 20 threads.
Wenn du glaubst (da hast ja jetzt Erfahrung mit der Schrittmotorsteuerung sammeln können), dass die Schrittmotorsteuerung ohne Probleme auch in das GUI-Programm inkludiert werden kann, dann sparst du dir natürlich die Kommunikation zwischen den Prozessen.
Das hat zur Folge, dass du vom Schrittmotorsteuerungs-Thread aus in irgend eine Variable die SOLL-Position und in eine andere Variable die IST-Position schreiben kannst. Diese Variablen kannst du dann vom GUI-Programm aus direkt abfragen. Dafür lässt du einen Timer laufen, der z.B. alle 80 ms die Label aktualisiert.
Wichtig ist nur, dass du von eine Thread aus nie direkt etwas an einem GUI-Element veränderst. Das muss immer indirekt z.B. in wxPython über ``wx.CallAfter`` erledigt werden. Aber eines solltest du dir im Klaren sein. Die GUI kann niemals so schnell die Werte anzeigen wie sie vom Schrittmotorsteuerungs-Thread geliefert werden können. Also ist es fast besser, die Anzeigegeschwindigkeit von der GUI aus zu regeln und nicht von der Schrittmotorsteuerung aus.
Mehr fällt mir im Moment nicht ein.
mfg
Gerold