Ich habe eine Frage zur Schrittmotorsteuerung bei Verwendung des TCP/IP-Stacks.
In der Vergangenheit habe ich einen Timer für meine Schrittmotorsteuerung verwendet. Ich stelle die Periode eines Timers auf die erforderliche Zeit zwischen Impulsen ein und ändere dann die Motorphasenausgänge nach Bedarf im Timer-Tick ISR. In den Fällen, in denen ich dies getan habe, bewegte sich mein Stepper mit einer maximalen Geschwindigkeit von etwa 400 Impulsen pro Sekunde, was bedeutet, dass der Interrupt alle 2,5 Millisekunden auftrat. Und ich habe USB für die Kommunikation mit dem Host verwendet.
Ich arbeite jetzt an einem neuen Produkt, das den TCP/IP-Stack verwendet, um mit einem PC über Ethernet zu kommunizieren. Es kommuniziert auch mit anderen Geräten über SPI- und UART-Module. Dieses neue Gerät muss in der Lage sein, einen Stepper mit bis zu 2000 Impulsen pro Sekunde zu betreiben, was bedeutet, dass der Interrupt alle 0,5 Millisekunden ausgelöst werden kann, wenn ich den gleichen Timer/ISR-Ansatz verwende, um den Stepper anzutreiben. Der Stepper wird basierend auf vom Host empfangenen Befehlen ein- und ausgeschaltet, sodass die Kommunikation mit dem Host und der Betrieb des Motors harmonisch und gleichzeitig erfolgen müssen. Wenn die Schrittgeschwindigkeit leicht variiert, wäre das kein Problem, aber es ist nicht ideal. Auch wenn der Stepper in der Mitte seiner Bewegung etwa 30 ms pausieren würde, wäre das nicht akzeptabel.
Ich überlege, für dieses Projekt einen PIC24F mit einer Befehlstaktgeschwindigkeit von 16 MHz (32 MHz/2 unter Verwendung des internen FRC + PLL) zu verwenden. Glauben Sie, dass die Interrupts für den Stepper die Ethernet-Kommunikation stören oder umgekehrt? Gibt es einen besseren Weg, dies zu tun?
Ich habe überlegt, einen separaten PIC für die Schrittsteuerung zu verwenden, und dann könnte ich diesem Bild Zielpositionsbefehle oder Stoppbefehle senden, um die Bewegung zu starten und zu stoppen, aber das würde dem Mix eine weitere Firmware hinzufügen und die Dinge rundherum komplizieren.
Wie Nick T erwähnt hat, ist TCP/IP ungefiltert und nicht deterministisch. Sie sagten, Sie möchten auch eine Schnittstelle mit SPI- und UART-Geräten herstellen, und frühere Versionen verwendeten USB. Dies ist in Echtzeit schwierig durchzuführen und erfordert wahrscheinlich erheblichen Coderaum.
Andererseits möchten Sie eine Echtzeitsteuerung Ihrer Schrittmotoren, die eine deterministische Ausführung und schnelle Interrupts erfordert, aber nicht viel Programmspeicherplatz.
Während Sie sagten, Sie wollten die Verwendung eines separaten Mikrocontrollers vermeiden, weil dies die Dinge verkomplizieren würde, ist dies ein perfektes Beispiel dafür, wann Sie einen Co-Prozessor benötigen, und ich glaube, dass dies die Dinge am Ende einfacher machen würde.
Sie können eine einfache Schrittmotor-Controller-Firmware entwickeln, die auf kleinen, billigen Mikrocontrollern läuft. Entwerfen (oder entdecken) Sie ein Protokoll, das einen Kommunikationsbus verwenden kann, der in Hardware auf dem von Ihnen gewählten Controller verfügbar ist. Ich würde dafür SPI empfehlen (auf einem anderen Kanal als dem Gerät, das Sie in Ihrer Frage erwähnt haben; Ihr Master sollte zwei SPI-Peripheriegeräte haben), Sie möchten angesichts der geringen Anzahl von Controllern, die Sie haben werden, nicht mit Adresskonflikten herumspielen . Machen Sie nichts mit diesem Controller, sondern führen Sie den Stepper gemäß den Daten aus, die er über das Protokoll erhält. Sie können wahrscheinlich etwas kaufen, das dies bereits tut. Ziel ist es, dies als Hardwareperipherie behandeln zu können.
Anschließend können Sie USB- oder Ethernet-Controller entwickeln, die an diese Geräte angeschlossen werden. Sie haben Flexibilität bei den Host-Protokollen (Müssen Sie dieses Mal RS485 verwenden? Kein Problem!), Sie können eine unterschiedliche Anzahl von Motoren verwenden und Sie haben eine größere Modularität beim Entwerfen, Testen, Debuggen, Reparieren und Ersetzen. Die einzigen Gründe, warum ich versuchen würde, so etwas in einem einzelnen Controller zu implementieren, wären extreme Kosten-/Größenbeschränkungen und/oder ein Mangel an Hardwaremodulen (wie PWM? Habe ich etwas verpasst?), die dies tun könnten, ohne den Host zu unterbrechen Prozessor.
Die Hauptfrage ist, was eigentlich mit den Daten umgehen wird, die über die Leitung kommen. Die Menge an Mist (Zeug, der nicht an Sie adressiert ist), den Ethernet liefern kann, ist überwältigend. Wenn Sie eine Low-End-MCU (PIC24F) verwenden, benötigen Sie eine Art Co-Prozessor, z. B. einen ENC28J60 , um zumindest die MAC-Adressfilterung bereitzustellen.
Jemand im Chat hat erwähnt, dass der PIC24F Interrupt-Prioritäten hat. Wenn also die Aufrechterhaltung der Isochronizität kritisch ist, können Sie die Timer-Priorität einfach höher einstellen.
Eine Kleinigkeit beiseite: Beachten Sie, dass TCP/IP und Ethernet nicht deterministisch (unabhängig) sind. Erwarten Sie beispielsweise nicht, dass Sie einen Befehl über Ethernet senden können, um Ihren Schrittmotor "jetzt" zu stoppen, wenn Sie sich direkt an Position X befinden, und dass er wiederholt reagiert.
Sie müssen wahrscheinlich ein PWM-Modul verwenden, um Ihre Impulse zu erzeugen. Es ist mir schwer gefallen, Impulse in Software mit Frequenzen> 1 kHz in PICs zu erzeugen. Suchen Sie einfach nach einem PIC mit der richtigen Anzahl an CCP/ECCP-Modulen und PWM-Ausgängen für Ihre Anwendung.
Nick T
PICyourBrain
Nick T