Hi,
Zitat von
urbanbruhin:
Dann zum Protokoll, ich glaub das hab ich noch nicht ganz verstanden:
Startbyte --> Darum muss ich mich nicht kümmern oder (Nur beim Initialisieren des Ports angeben)?
Message_Size --> Das gibt einfach die Länge (Anzahl Bits, Bytes?) der Message an?
Command_Byte --> Ist das der Befehl? also im G-Code wäre das z.B. M0 oder G01?
Payload --> Hier sind z.B. die X/Y/Z Koordinaten drin?
Command_Byte --> hmm nochmal das... ich lag glaub doch falsch^^
Checksumme --> Einfach zur Sicherheit nehme ich mal an...
Stopbyte --> Ähnlich wie das Startbyte...
Naja, nicht wirklich: Die Übertragung erfolgt über die serielle Schnittstelle, alles was ich angegeben habe, ist für dich von Relevanz.
Startbyte --> 0x0F, dient zum Erkennen eines Telegramms vom PC.
Message_Size --> Anzahl der Bytes des KOMPLETTEN Telegramms.
Command_Byte --> Kommando des PCs an den µC. KEIN G-Code, da es neben G-Codes noch andere Anweisungen (Kalibrierparameter etc.) an den PC gibt. Wenn ein G-Code übetragen wird, enthält das Command_Byte z.Bsp. die Anweisung cmd_code_gcode_transfer.
Payload --> Die Payload enthält die Informationen, die zur Ausführung des Commands benötigt werden. Bei cmd_code_gcode_transfer z.Bsp. würde die Payload den vereinfachten G-Code beinhalten. Anhand des Commands kann dann ein Unterprogramm aufgerufen werden, das sich dann um die Auswertung der Payload kümmert.
Command_Byte --> Zur Sicherheit wird das Command_Byte doppelt übertragen. Stimmt es nicht überein, wird das Telegramm verworfen.
Checksumme --> Zweierkomplement der Summe ALLER Bytes bis hierher. Stimmt sie nicht überein, wird das Telegramm verworfen.
Stopbyte --> 0xF0, dient zum Erkennen eines Telegrammendes.
Die komplette Dekodierung erfolgt in einer State-Machine, die den Eingangs-Fifo nach dem Startbyte durchsucht und dann Schritt für Schritt die einzelnen Überprüfungen durchführt.
Befindet sich das Stopbyte nicht an der von der Messaage_Size angegeben Position schaltet die State-Machine ebenso auf Durchzug wie bei allen anderen Telegramm-Fehlern.
Erst wenn ein Stopbyte auftaucht, "hört" die State-Machine wieder zu.
Zitat von
urbanbruhin:
Benutzt du Threads für die Übertragung? Bei meinem Programm warte ich einfach auf ein "Signal" von der seriellen Schnittstelle, wenn da keines kommt bleibt das Programm an dieser Stelle hängen...also so lange bis ein Signal kommt.
Normalerweise kann ein AVR keine Threads. Eine Multithreading-Implementation würde kostbare Rechenzeit und andere Ressourcen fressen.
Stattdessen verwende ich ein ausgeklügeltes (?) *hust* Programmdesign damit alle Module ihren Job erldigen können:
Main-Schleife:
- State-Machine zur Auswertung der Telegramme
- G-Code-Interpreter & Preprozessor
- G-Code-Main-Prozessor (sofern nötig)
RS232-Receive-Interrupt:
- Schaufelt empfangene Bytes in den Receive-Fifo (der dann in der Main-Schleife ausgewertet wird)
Timer-Interrupt:
- Steuert die angeschlossenen Motoren je nach aktuellem Steuerbefehl an. (Pinwackeln
)
+X andere Kleinigkeiten am Rande (ADC für die manuelle Kontrolle, blinkende LEDs, Endschalter etc.)
Solange kein Interrupt in die Ausführung der Main-Schleife springt, wartet diese auf Benutzereingaben und berechnet Anweisungen für den Motor-Timer-Interrupt vor.
Zitat von
urbanbruhin:
Ach ja, für was brauchst du den Bresenham-Kreisalgorithmus? Ich kenn den zwar nicht, aber wird wohl für Kreise benötigt (laut Wikipedia^^)
Doch im G-Code sind die Kreise doch irgendwie schon in einzelne Geraden umgewandelt oder?!
Nope, schau dir mal G02 und G03 an, das sind die Befehle für eine Kreisbewegung im/gegen den Uhrzeigersinn.
Der Main-Prozessor wird hauptsächlich diese Berechnungen übernehmen, für eine klassische Gerade wird das ganze hoffentlich direkt in der Motor-ISR erledigt werden können.
Zitat von
urbanbruhin:
Ja das ist mir schon klar, doch ich bin absoluter Anfänger (wie du bestimmt gemerkt hast xD) auf diesem Gebiet, und da ist meine grösste Schwierigkeit im Moment noch der "Gesamtaufbau" des Programms. Dieser ist ja unabhängig von der Programmiersprache und von den einzelnen Befehlen ja grundsätzlich immer ziemlich ähnlich.
Falls du mal im Roboternetz schreibst, kannst mir vielleicht bescheid geben, damit ich das Thema dann auch mitverfolgen kann?
Kein Problem, es gibt im RN ein/zwei _richtig_ große Threads zum Thema CNC, ich bin dort unter dem selben Nick unterwegs und hab auch schon ein paar Beiträge hinterlassen.
Ich habe allerdings _keine_ Ahnung von der C-Control, nach dem was ich mir gerade ergoogelt habe, wirst du vermutlich von "meiner" Lösung Abstand nehmen müssen.
Bei der C-Control hast du eine Zwischenschicht/eine Art Betriebssystem zwischen dir und der Hardware, die Folge daraus ist vermutlich automatisch, dass du Echtzeitanwendungen eher schwierig umsetzen kannst, vor allem wenn du dich schon hart am Limit dessen bewegst, was der µC an Leistung hat.
Hast du schon einmal versucht, einen Schrittmotor "von null auf hundert" und zurück zu regeln? Kommst du bis in den Bereich, in dem Schrittverluste auftreten?
Im Moment verwende ich für meine Umsetzung Zeitscheiben von 0,1ms. Da mein µC mit 20Mhz taktet und die Ansteuerfrequenz 10kHz beträgt, habe ich je Schritt 2000 Instruktionen zur Berechnung der nächsten Bewegung zur Verfügung.
Je nach dem, wie performant meine Umsetzung ist, kann ich später sogar einen noch kleineren Grundtakt für die Motoransteuerung wählen.
Jedes Mhz weniger reduziert die Reserve, die du für deine Berechnungen hast, immerhin berechnet der µC nebenher wo die Reise hingeht, die Interrupts sind höher priorisiert und wollen nur noch den Schrittmotortreiber ansteuern, das nächste Kommando hat also da zu sein!
Die C-Control Pro scheint mit 14,irgendwas Mhz zu Takten, die Tatsache dass der Code auch noch durch einen Interpreter läuft, verschlechtert deine Chancen nur noch mehr.
mfG
Markus