Druckbare Version
So, hab jetzt an einen DC-Motor eine Encoderscheibe mit IR-Diode und Fotoransistor angebracht und es funktioniert bisher scheinbar ganz gut. Nun muss ich nurnoch den Ausgangspegel etwas anpassen, damit auch klare High-Low-Signale erkannt werden können, und dann kann eigentlich schon die Programmierung losgehen. Nagut erstmal muss ich noch endlich mein µC-Board zusammenlöten, aber das sollte eigentlich weniger das Problem sein.
Ich habe heute mal die Möglichkeit getestet, über das Pololu Mini Maestro Board über den TTL-Port mit der UART des ATmega zu kommunizieren. Lief erst auch gut und ich konnte die Position auf meinem Bildschirm visualisieren. Nachdem ich dann ein Kabel gebastelt hatte, um das Pololu-Board und mein Controller-Board besser miteinander verbinden zu können, und dieses anschloss, funktionierte die Kommunikation nicht mehr. Auch mit den Kabeln, die ich vorher verwendet hatte, geht es nicht mehr. Zwischendurch hatte ich auch diesen typischen Geruch vernommen, der nichts Gutes verheißt. Ich befürchte, dass das Pololu-Board etwas abbekommen hat :(
Zu sehen ist nichts, aber das muss ja nichts heißen. Kann man denn so viel falsch machen, wenn man da die Kabel falsch anschließt?
Wenn man einen Kurzschluss verursacht kann es schon sein. Ich würde alles abschließen was möglich ist und jeden Teil (sofern möglich) einzeln testen. Was hast du genau für ein Pololu Board? Könntest du einen Link posten?
MfG Hannes
Ich hab dieses Board:
http://www.watterott.com/de/Mini-Mae...ller-Assembled
An sich funktioniert es noch, eigentlich hatte ich auch drauf geachtet, die Kabel richtig anzuschließen. Hab dem Händler auch schon eine Mail geschrieben, schließlich bieten sie Support an. Mal sehen, wann die antworten.
Funktioniert der Atmega auch noch? Hat der Atmega noch einen Pegelwandler (TTL-Pegel auf normale RS232 Pegel)?
MfG Hannes
Ich hatte den ATmega schon ausgewechselt und es hat nichts gebracht, an dem liegt es also nicht. Pegelwandler brauch ich nicht, da das Pololu-Board ja schon mit TTL-Pegel arbeitet. RS232 hab ich hier auch gar nicht zur Verfügung, außerdem hatte es ja schon funktioniert. Hab gerade nochmal ausprobiert, es kommen kommen keine Befehle an und es können auch keine gesendet werden. Irgendwo versickern die unterwegs, im Prinzip kann es nur am Pololu-Board liegen :(
Ganz schön ungünstig...
Wegen den Pegeln habe ich nur sicherheitshalber nachgefragt. Das wäre sehr ungünstig gewesen. Über USB kannst du das Board ansteuern? Geht das Signal vom USB und vom UART Signal auf den gleichen Eingang des µC (beim Pololu Board)?
MfG Hannes
Da versteh ich jetzt nicht, was du meinst. Das pololu Board hat eine Mini-USB-Buchse, die an den PC angeschlossen wird. Darüber lässt sich dann der TTL-Port des Pololu Boards als virtueller COM-Port verwenden. Ich hab halt den Rx-Pin des Boards mit dem Tx-Pin des µC verbunden und den Tx mit dem Rx.
Komischerweise funktioniert es jetzt wieder... keine Ahnung, was das Problem ist...
Edit: Nachdem sich das Board sich jetzt ja wieder eingekriegt hat habe ich mal versucht, ein paar Verläufe vom Motor aufzunehmen.
Anhang 20546
Im Diagramm steht die weiße Linie für den Winkel, die rote Linie für die Winkelgeschwindigkeit und die grüne Linie für die Winkelbeschleunigung. Anscheinend ruckelt die Drehzahl ein wenig, mal sehen, was sich daran machen lässt. Man sieht aber schonmal, dass der Motor ziemlich fix hochbeschleunigt. Was ich beim Regler wohl noch Bedenken muss: der Motor läuft erst ab einer Spannung von 1,5 bis 2V an, das müsste ich dann wohl noch irgendwie abfangen.
Hier noch ein paar Bilder vom hingefrickelten Encoder :D
Anhang 20545Anhang 20544
Schön wenn es jetzt funktioniert.
Es gibt 2 Möglichkeiten wie das UART Signal bzw USB Signal an den µC des Pololu Boards angeschlossen ist.
Hier sind Skizzen wie ich es meine:
Die Skizze ist aber nur zur Erklärung. Wenn es nicht funktioniert hätte, hätte ich es über den USB Port versucht, wenn es auf den gleichen Pin des Pololu µC geht. So kannst du ausschließen dass das Programm am Atmega oder die Verbindung fehlerhaft ist oder nicht.Code:entweder:
USB---USB/UART Wandler (z.B. FT232)---Pin des Pololu µC
UART--------------------------------|
oder:
USB--- USB/UART Wandler---Pin des Pololu µC
UART----------------------anderer Pin des Pololu µC
Aber das brauchst du jetzt ja nicht mehr (zumindest vorerst).
MfG Hannes
So, wenn ich jetzt in die Routine den PWM-Ausgang setze, dann verzählt sich dar µC komischerweise ständig, besonders, wenn ich nur lagsam drehe. Wenn ich das weglasse, zählt er wieder jeden Schritt genau. Hier der Code, den ich bisher zum Testen geschrieben hab:
Kann es sein, dass dadurch die Sub zu lange dauert und daher das Programm blockiert? Ich weiß irgendwie nicht, woran das liegen kann...Code:regfile = "m32def.dat"
$framesize = 32
$swstack = 32
$hwstack = 32
$crystal = 16000000
$baud = 9600
Declare Sub Serial0charmatch()
Config Serialin = Buffered , Size = 30 , Bytematch = 13
Config Porta = Output
Config Pinc.0 = Input
Config Portc.1 = Output
Config Portb.3 = Output
Config Timer1 = Counter , Edge = Rising
Config Timer0 = Pwm , Compare Pwm = Clear Down , Prescale = 8
On Timer1 Count
Enable Timer1
Enable Interrupts
Dim T As Long
Dim Preset As Byte
T = 0
Preset = 1
Waitms 500
Load Timer1 , Preset
Do
!nop
Loop
Count:
Load Timer1 , Preset
If Pinc.0 = 1 Then
T = T + 1
Else
T = T - 1
End If
Return
Sub Serial0charmatch()
Local Incoming_data As String * 30
Local Soll As Long
Local E As Long
Input Incoming_data Noecho
Print T
Soll = Val(incoming_data)
E = Soll - T
E = 10 * E
'Compare0 = 127 - E <---hier ist der kritische Term, auskommentiert bereitet er Probleme
End Sub