Hallo! Ich bastel zur Zeit an einem Holzmodell eines Schaufelraddampfers. Jede der beiden Schaufeln soll am Ende durch einen eigenen Motor betrieben werden und Schrittmotoren halte ich wegen den Dauerbelastung für nicht sonderlich gut dafür geeignet?! Wenn ich normale Elektromotoren mit einem Getriebe davor nehme, will ich die beiden aber unbedingt synchronisieren. Meine Idee wäre folgende: Eingang 1: Servosignal für die Geschwindigkeit und Richtung der Sensoren Eingang 2: Servosignal das angibt, ob die Motoren miteinander oder gegeneinander drehen sollen Eingang 3 und 4: Inkrementalgeber an den Achsen zur Synchronisation Das Ausgangssignal für zwei Fahrtenregler müsste also entsprechent berechnet werden. Meine Frage: Ist das direkt so mit einem Microcontroller möglich? Und wenn ja, welchen könnte mir dafür jemand empfehlen? Ich hab auch keine Vorstellung, was für eine Leistung man dafür bereitstellen müsste... Wir das Signal dann mit einer Art Stop-Uhr ausgewertet oder gibt es Bausteine, die das Signal messen und schon den Wert an sich weitergeben? Was das generieren vom Servosignal angeht, so habe ich schon einen Servotreiber gefunden der RS232 TTL schluckt. Ich hatte bisher noch nichts mit Microcontrollern zu tun, dafür aber einige Programmiererfahrung in anderen Sprachen wie Java, VB, VB.Net, C++, Ada... Danke schonmal für die Hilfe! Manuel
Ja, das ist möglich, µC's haben Hardware Interrupts, Timer und Input Capture Units, welche Encoder auswerten, die Signallängen von RC Signalen messen und auch wieder ausgeben können. Würd' mich mal nach einem ATMega32 umschauen, wobei ich es für möglich halte, daß ein kleinerer Atmel Baustein auch reichen könnte, wie z.B. ein Tiny2313. Du müsstest Dich zuallererst mit dem internen Aufbau dieser Bausteine vertraut machen, und dann eine passende Sprache raussuchen, entweder C oder Basic in Deinem Fall. Könnte je nach Deiner Lernkurve recht anspruchsvoll sein. Geh' mal auf die Atmel Seite, lad' Dir ein Datenblatt für den Mega32 runter und wirf' 'nen Blick rein, damit Du eine Vorstellung davon bekommst, was Dich erwartet :D
Eventuell kannst du auch brushless Motoren aus dem Modelbau verwenden, das sind ja Synchronmotoren und du kann die Drehzahl einfach vorgeben. Dann braucht du überhaupt nicht messen.
Gut, dass es eine Einarbeitezeit geben wird ist mir klar und dass es kein Spaziergang wird auch. Aber da ich erst in 1 bis 2 Jahren mit der Fertigstellung vom Modell rechne, habe ich ja Zeit! :-) Hm, arbeiten die Bürstenlosen Motoren wirklich so genau? Gibt es Empfehlungen für ein Einsteigerboard für die Atmega32? Hier im Shop habe ich das gefunden: http://shop.embedded-projects.net/product_info.php/info/p78_AVR-Entwicklungsplatine-fuer-40-polige-AVRs--AVR-P40-853.html Reicht es um so etwas zu entwickeln?
Ok, wenn das Zeit hat, dann kann das klappen. Da Du ein dynamisches System mit mehreren Timern erzeugen willst (musst), könnte übrigens die Anschaffung eines Oszilloskopes oder Logiganalyzers Sinn machen, wenn nicht schon vorhanden. Zu dem Teil auf dem Link brauchst Du noch einen ISP Programmer, denn der ist da nicht drauf. Vorteil den ich sehe, auf der freien Fläche könnte noch Zusatzschaltung untergebracht werde. Ansonsten schau' Dich nach STK500 von Atmel um, ist ein Standard Development Board, hat gleich einen ISP Programmer drauf, den man später auch für andere Boards, oder eben auch für das Verlinkte, nehmen kann. Braucht aber eine serielle Schnittstelle, oder einen USB/Ser Adapter, falls Betrieb am Notbook ohne serielle Schnittstelle erforderlich ist. Das Problem bei denn bürstenlosen Motoren sehe ich darin, daß RC Regler zwar intern mit absoluten Werten arbeitet, aber dennoch per Pulsweitensignal des RC Empfängers angesprochen werden, und da könnte die Interpretation welche Drehzahl welcher Pulslänge entspricht, doch auseinandergehen. Schau Dir mal das hier an: http://www.mikrocontroller.com/de/KopterBL.php Das ist ein Regler für bürstenloser Motoren, der per I2C gesteuert werden kann. I2C ist ein seriellles Protokoll, heist nur bei Atmel TWI, wird vom Mega32 unterstützt, und es gibt auch Soft I2C. Mit solchen Reglern könnt' ich mir vorstellen, daß ein Gleichlauf möglich wird. Es spricht im Prinzip wegen Dauerbelastung nichts gegen Schrittmmotorenn, wie kommst Du darauf ? Wenn die gut gekühlt werden, dann laufen die ewig, könnt' nur sein, daß der Wirkungsgrad unbefriedigend ist.
Super, vielen Dank schon mal für die ganzen Ratschläge. Naja, ich hab ne kleine CNC Fräse und da werden die Schrittmotoren, vor allem die Z-Achse (relativ kleiner Motor) sehr warm. Außerdem dachte ich immer, dass Schrittmotoren eben für ein genaues Verfahren ausgelegt sind und nicht um quasi als normaler Elektromotor genutzt zu werden. Hatte ich mir selber zusammen gereimt. :-) Aber wenn das kein Problem ist, könnte ich mir auch die Regler und Inkrementalgeber sparen und als Ausgang eben Schrittmotortreiber (nennt sich das so?) verwenden.
Wie gesagt, die Schrittmotoren haben nur einen nicht sooo günstigen Wirkungsgrad, ist ja für die Standardanwendung meist egal. Evtl. begrenzt das aber die Betriebszeit Deines Bootes. Auch die Maximaldrehzahl ist nicht hoch, das lässt sich aber durch die Getriebewahl ausgleichen. Bei der CNC muss ggf. auch der Haltestrom höher sein, was zu zusätzlicher Erwärmung führt. Den Betriebsstrom kannst Du dann per Choppereinstellung entsprechend der benötigten Antriebskraft wählen. Auf eines solltest Du auch achten, Stepper baruchen oft mal mehr als 12V Betriebsspannung um entsprechend Kraft zu entwickeln. Ansonsten sind Stepper äußerst dauerhaft, haben Kugellager, und da nur Spulen auf dem Stator sind, auch keine Stromabnehmer / Bürsten, die abnutzen können. Da kommst Du bis auf den Amazonas mit Deinem Boot :D
Naja, das Boot wird ca. 1 Meter lang und ist komplett aus Holz. Ich sehe also kein Problem darin, 2 Bleiakkus reinzusetzen, die für ausreichend Strom sorgen. Und nach ner Stunde wird man auch spätestens die Schnauze voll haben... Demnach wären Stepper wohl die einfachste Lösung. Gibt es schon fertige Bauteile, die Stepper durch PWM Signale steuern oder ist das jetzt mein neues Projekt? :-)
> Naja, das Boot wird ca. 1 Meter lang und ist komplett aus Holz. Ich sehe > also kein Problem darin, 2 Bleiakkus reinzusetzen, die für ausreichend > Strom sorgen. Und nach ner Stunde wird man auch spätestens die Schnauze > voll haben... Cooles Projekt :) Auf Bleiakkus würde ich allerdings verzichten, für ein Modell (Auch wenn es ein Boot ist), haben die ein viel zu hohes Leistungsgewicht. Es müssen ja nicht gleich LiPo-Zellen sein, aber wenigstens zu NiMH würde ich da schon greifen. > Demnach wären Stepper wohl die einfachste Lösung. > Gibt es schon fertige Bauteile, die Stepper durch PWM Signale steuern > oder ist das jetzt mein neues Projekt? :-) Ich weiss nicht, ob du mit Steppern wirklich glücklich werden wirst. Mit einer synchronen Drehzahl der Schaufelräder fährt das Schiff ja noch nicht zwingend geradeaus (Geometrie der Schaufelräder muss genau übereinstimmen, evtl. Schräglage, Strömungen, ...). An deiner Stelle würde ich einfache Gleichstrommotoren mit H-Brücken-Steuerung verwenden und die Richtung mit einem Kompass-IC nachregeln. Oder gleich GPS wenn es ganz feudal sein darf ;) Zu den Schrittmotoren findest hier noch was: Schrittmotoren
Also bisher sieht es eher so aus, als ob ich Aufbalastieren müsste, damit ein einigermaßen originalgetreues Fahrbild entsteht. Dann kann ich auch Bleiakkus nehmen. Wenn ich mit meiner Rechnung daneben liege, werde ich auf andere Wechseln. Gleich wie, ich denke der Wirkungsgrad würde kein Problem sein. Wenn man es ambitioniert sieht ist der Gedanke hinter der ganzen Fräserei schon, dass bei synchroner Drehzahl auch zumindest fast der Geradeauslauf erreicht wird. Klar, gegen Strömung und Co kann man dann immer noch nichts machen. Vielleicht wäre das mit dem Kompass ne ganz nette Erweiterung, die sich ja auch rein an das Ruder koppeln lassen würde. GPS kommt dann erst für die Fahrt zum Amazonas rein... ;-)
> Gibt es schon fertige Bauteile, die Stepper durch PWM Signale steuern > oder ist das jetzt mein neues Projekt? :-) Das könnte Dein neues Projekt werden :D Du kannst auf normale Steppertreiber, evtl. mit Microstep ausweichen. Da musst Du dann nur Takt und Richtung reingeben, hast aber den Nachteil des Geräusches, das Du von der CNC her kennst. Es ist prinzipiell möglich Schrittmotore mit 2 versetzten gechoppten Sinusschwingungen anzusteuern, da hörst Du dann gar nix mehr steppen, das läuft rund wie ein normaler Elektromotor. Kannst dafür Tiny25/45 nehmen, die haben "2 High Frequency PWM Outputs", die mit einem Takt bis zu 64MHz laufen. So etwas hat der Mega32 nicht, den kannst Du aber falls notwendig als Zentralrechner nehmen. Für diese Lösung müsstest Du wahrscheinlich die Treiberstufen für die Mosfets selbst entwickeln/aufbauen, weis nicht wie fit Du da bist.
Wenn Stepper gewählt werden, nimm Welche mit möglichst kleiner Spannung bei möglichst großem Drehmoment. Durch den Chopper wird der Spulenstrom ja eh begrenzt und die Spannung 'regelt' sich schon passend ein. Je höher die Differenz zwischen Versorgungsspannung und Motorspannung ist, desto schneller kannst Du den Stepper ohne Schrittverluste fahren lassen. Allerdings denke ich, daß man bei einem Schaufelraddampfer es nicht wirklich auf Drehzahl ankommt - nen starker 12V Stepper (bei 12V Versorgung) sollte sich auch gut machen. Ach ja, früher, so zur Zeit der Dampfschiffe, hat der Käpt'n auch entsprechend am Rad gekurbelt, damit die Kiste auch geradeaus läuft ;)
Gut, da kommt dann das Problem: bisher hatte ich mit Elektronik eigentlich nichts zu tun. Ne Treiberstufe selbst zu entwickeln würde ich also mal schön hinten anstellen. Meine CNC Fräse ist glücklicher Weise relativ leise im Verfahren. Die Schrittmotoren daran hören sich für mich schon fast an wie elektromotoren, außer wenn man sie langsam fahren lässt. Aber da es eh ein längeres Projekt wird, werde ich mich wohl mal durchtesten. Bin noch nicht so sicher, ob ich Schrittmotoren (was ich momentan für einfach halte) oder normale Gleichstrommotoren nehmen soll. Ich geh auch davon aus, dass ein Schrittmotor selbst im Direktantrieb genug Kraft entwickeln kann, um den Dampfer fahren zu lassen. Und sonderlich schnell darf sich die kleine Schaufel auch nicht drehen, weil sonst nur die Strömung abreißt. Eines noch: Das STK500 sieht ja recht... breit gefächert aus. Kann ich damit dann auch die Tinys beschreiben bzw. nennt sich ja brennen, oder? Gibt's eigentlich ein online Shop bei dem die Masse vom Forum hier einkauft? Vielen Dank nochmal an alle Ratschläge! Werde mich hier bei Gelegenheit wieder verewigen, wenn ich ein wenig weiter bin. :-)
Wollte nur zur Sicherheit darauf hinweisen, denn die Fräse wird einigermaßen massiv aus Metall sein und so ein Boot könnte wie ein Klangkörper wirken, da hast Du keinen Spass, wenn so eine Kreissäge durchs Wasser rauscht. Beim Direktantrieb könnte man auf den Raddurchmesser gesehen evtl. ein Ruckeln bemerken, wenn's nicht Microstep ist. Aber viel Spass beim ausprobieren. Ja, man kann damit auch Tinys beschreiben, neben einem ISP Programmer ist da eine einstellbare Versorgungsspannung und ein einstellbarer Oszillator drauf. Wenn man mal die Fuses versehentlich auf externen Takt gestellt hat, jedoch kein Quarz dran ist, und man somit einen nicht mehr ansprechbaren µC hat, weis man das zu schätzen. Geh mal auf atmel.com gib STK500 in die Suche ein, erster Link verweist auf Pdf's zum STK500. Schau' Dir die mal an. Wo hier das Forum einkauft, kann ich Dir leider nicht sagen. Den embedded shop hast Du ja bereits gefunden, da gibt's aber keinen STK500, nur den 600, der ist teurer. Auf E... STK500 eingeben fördert im Moment nur einen zutage, da waren immer mehr Angebote drin, ansonsten google benutzen. Nur zu... ;-)
Hi, habe auch einen Schaufelraddampfer - allerdings die beiden "Paddel" mit einer Welle verbunden - die ggf. minimalen Unterschiede werden durch das Seitenruder ausgeglichen - klar wenden auf der Stelle etc. geht natürlich nicht ;)) Gruß Tim
Ich würde auch noch raten das Prinzip der zweirädrigen Roboter anzuschauen, denn dort wird absolut Ähnliches gemacht. Die sind sogar noch instabiler als ein Schiff was den Geradeauslauf betrifft.
So, ich bin grad auf Atmel's Hochschul Programm gestoßen, wo Studenten (da fall ich ja ein Glück darunter) die Atmel Produkte bis zu 50% billiger bekommen. Demnach ist ein STK600 direkt erschwinglich. Ob nun für den Dampfer oder ein anderes Ding, ich hab Lust bekommen mich damit zu beschäftigen. Verstehe ich das richtig, dass ich zusätzlich zum STK600 auch das Zusatzmodel STK600-DIP brauche, damit ich ATMega32 und die Tiny25 oder 45 verwenden kann? Und versteh ich das auch richtig, dass man zusammen mit AVR Studio das Board recht leicht integrieren und wenn man fertig ist direkt von dort den Quellcode auf den Prozessor brennen kann?
Schau' dir doch mal das Getriebe von den etwas teureren Panzermodellen an. Dort ist ein starker Motor für den Vortrieb und ein schwächerer um das Differenzial dosiert zu Sperren. Damit wird ein Sauberer Gleichlauf bei maximaler Antriebsleistung erzielt. Mit dem Differenzial (unterschiedliche Drehzahlen links und rechts) wird der Panzer gelenkt, wie im Original.
Angehängte Dateien:
-
Programmers.png
14 KB
Manuael, das STK600 ist für die größeren AVR's geeignet, das 500er reicht für viele der kleinen AVR's aus. Du brauchst beim 600 den STK600-DIP Adapter, das würd' mich stören, außerdem finde ich das Adapterboard für den eigentlichen Einbau zu groß. Such' mal hier: www.elecont.de nach Carrierboards, hab' selbst ein paar davon gekauft, fand ich preiswert und gut. Diese Boards kannst Du dann sowohl mit dem 500, als auch mit dem 600 programmieren, natürlich auch mit jedem anderen vernünftigen ISP Programmer. Persönlich bevorzuge ich mittlerweile ein Breadboard/Steckbrett zum Aufbau und testen, hab' aber nie bereut einen STK500 gekauft zu haben. Das AVR Studio arbeitet mit verschiedenen Programmern zusammen, siehe Screenshot, deswegen wirst Du auch bei den Nachbauten auch immer wieder den Hinweis: "STK500-kompatibel" finden, wenn er kompatibel ist, akzeptiert ihn das AVR Studio. Im AVR Studio selbst kannst Du in Assembler programmieren. Um in C zu schreiben, benötigst Du einen C-Compiler, z.B. den AVR GCC, ein freier Compiler. Damit erzeugst Du das letzendes benötigte compilierte Hex-File, daß Du dann mit dem AVR Studio in den µC brennen kannst. AVR Studio eignet sich aber auch um das C-Programm zu simulieren und zu debuggen. Ich persönlich mag Bascom, einen Basic Compiler, der auch das benötigte Hex-File erzeugt. Programmieren des Chips ist dort aus der Anwendung raus möglich falls ein unterstützter Programmer existiert. Ich persönlich schätze in Bascom das einfache Mischen von Basic und Assemblercode. Du wirst hier im Forum einige Mitglieder finden, die sich abschätzig über Bascom äußern. Nimm die Sprache, in der Du lieber programmierst. Sobald Du einen AVR Studio kompatiblen Programmer hast, kannst Du über ISP auch obige Carrierboards beschreiben. Es reichen im Prinzip ein paar Stückchen Draht, einen Programmer und ein AVR-IC und los geht's :-) Wobei ich mir am Anfang eine gut funktionierende Basis wie den STK500 oder 600 zulegen würde.
Hallo Manuel ich habe die Lorelei von Hegi, sehr einfach gehalten mit festen Schaufeln. Die Lorelei (ca. 80 cm lang) fährt mit zwei normalen Getriebemotoren Mabuchi 280, einzeln steuerbar (die Technik ist 20 Jahre alt). Um den Geradeauslauf mit der Schaufelgeschwindigkeit zu ändern muß schon einiges passieren - die Seitenwindeinflüsse sind größer. Zur Steuerung aus heutiger Sicht würde ich einen AVR nehmen (ATmega8), zur Programmierung BASCOM. Externe Fahrtregler sind nicht nötig, da der Prozessor alles regeln kann: Relais für die Umpolung und PWM-Ansteuerung für die Motordrehzahl ist mit wenigen Bauteilen realisierbar. Licht und Nebelhorn erfordern je nur einen Schalttransistor. Infos zum Einlesen der PPM-Daten findest Du unter roboternetz.de > wissen > quellcode bascom. Thema Akku: Ich nehme nur noch 7,2V Racing Packs mit Tamiya Steckern, habe alle Schiffe und Autos darauf umgerüstet, jetzt benötige ich nicht mehr für jedes Modell einen eigenen Akku und ein eigenes Ladegerät. Du wirst nicht mehr als 6V bei 2A brauchen, nimm einen Akku den Du auch für andere Modelle brauchst, er hält länger wenn er öfter als zweimal im Jahr geladen wird. Gruß Andreas
Naja, ich war auch nicht davon ausgegangen, dass der Dampfer wilde Kreise fährt und dass man das durch zwei Regler und zwei Motoren mit entsprechender Programmierung des Senders schon sehr synchron laufen lassen kann, ist mir auch klar. Ich möchte es eben ein bisschen perfekter machen... nicht aus Notwendigkeit, sondern aus Interesse. Ok, ich glaub es wird Zeit, dass ich mich etwas einlese in die ganze Materie. Ich war bisher davon ausgegangen, dass z.B. ein ATmega32 schon einen Taktgeber etc. hat und nach der Programmierung eigentlich um zu Laufen nur mit Strom versorgt werden muss. Ich konnte sogar am Lehrstuhl ein STK600 ausgraben und werde mir mal so ein Carrier Board zulegen, um bisschen rumprobieren zu können. Eines noch: ich hab ein Carrier Board mit einem ATmega32-16AU gefunden. Kann ich davon ausgehen, dass alle ATmega32 gleich sind und -16AU nur die Bauform bestimmt, folglich also was für ein ATMega32 programmiert wurde auch auf dem -16AU läuft? Oder steckt da doch mehr dahinter? Danke nochmal für die ganzen Ratschläge!
Hi, bezüglich "-16AU". Das "AU" steht für die Bauform, die "16" für die maximale Taktfrequenz. Bestimmte Bauformen haben unter Umständen weniger Anschlüsse als andere und damit nicht alle Pins extern verfügbar. Ansonsten sind alle ATmega32 gleich. Kannst Dir ja mal den folgenden Link an anschauen: http://www.heise.de/ct/c-t-Bot-und-c-t-Sim--/projekte/133987 Ist zwar ein Roboter, aber die Ansteuerung der Motoren dürfte Deinen Bedürfnissen doch recht nahe kommen. Die benutzen übrigens 6V Faulhaber Motore (2619-006SR) mit 33:1 Untersetzungsgetriebe und einen ATmega32 zur Steuerung. CU
@Manuel: > Ich war bisher davon ausgegangen, dass z.B. ein ATmega32 schon > einen Taktgeber etc. Da bist Du auch richtig davon ausgegangen, das hat er, einen internen RC Oszillator, nicht sehr genau, aber immerhin er läuft frisch aus der Packung. Das Problem, daß sich dem Einen oder Anderen schon mal gestellt hat, ist wenn aus Versehen die Fuse per Programmer auf externen Quarz verstellt wurde, aber kein externer Quarz angeschlossen ist, und auch keiner gerade in der Schublade liegt. In diesem Fall lässt sich der AVR, da er keinen Takt mehr hat, auch nicht mehr per ISP programmieren. Da ist man dann froh ein STK500 zu haben, das den Takt liefern kann. Gibt noch mehr so Fallstricke, es gibt ein paar AVR's, wo man den Resetpins wegprogrammieren kann, dann ist er für ISP nicht mehr ansprechbar. Manche AVR's haben einen internen Oszillator mit 128kHz, den eingestellt und Clockdiv 8 eingeschaltet, dann läuft der AVR mit nur 18kHz. Ein Problem für manche Programmer den noch irgendwie anzusprechen. Aber in's STK500 rein, auf High Voltage Programming gestellt und schon ist der Tag gerettet. ;-) Wenn er ATMega32 heißt, ist der innere Aufbau, damit auch die Programmierung gleich.
Auf der Intermodell 1993 (oder so) war ein UBoot-Bauer, der seine Uboote mit einem Optomagnet-Kompass ausgerüstet hat. Das sa so aus, dass er mit einer Kompassnadel eine (Gabel-)Lichtschranke abgedeckt hat. Die Lichtschranke konnte er noch mechanisch verfahren, so dass er einen bestimmten Kurs vorgeben konnte. Ein Regelkreis hat dafür gesorgt, dass die Lichtschranke (eigentlich waren es zwei, um auch noch die Drehrichtung festzustellen) immer von der Kompassnadel abgedeckt wurde, indem er das Seitenruder entsprechend ansteuerte. Um für einen Geradeauslauf zu sorgen, dürfte aber ein Kreiselsystem, wie man es bei den Modellfliegern benutzt, reichen. Eine der Schaufelradsteuerung ähnliche Anwendung habe ich auch vor: Ein Ruderboot...
Ok, langsam kommt Licht ins Dunkle! Dann kann ich entweder ein STK500 und ganz normale ATmega32 verwenden. Die kann man ja wie ich gelesen hab auch auf dem Board testen mit paar LED's und Tastern oder eben dann auf dem Steckbrett. Oder ich kann ein STK600 nehmen, brauche dann aber entweder das STK600-DIP oder ein Carrier Board dazu wie das hier (http://www.elecont.de/shop/product_info.php?info=p40_CB32ad.html). Oder ist es grundsätzlich einfacher / sinnvoller, auch mit dem STK500 ein Carrier Board zu verwenden? Und zu den verschiedenen Programmierarten: Da ich mit C++ schon Erfahrung habe, werde ich mich zumindest zum Einstieg wohl an C halten. @MWS Du hast oben geschrieben, dass du BASCOM bevorzugst, weil man Basic und Assemlber Code einfach mischen kann. Macht es das in vielen Bereichen für dich "nur" einfacher, oder sind alleine mit C sonst Funktionen nicht erreichbar? Ich hab mir mal WinAVR und das AVR Studio runtergladen und installiert - damit ist ja das Programmieren der Atmels in C möglich. Wenn ich mich auch an Bascom versuchen will, muss ich den Compiler kaufen? Den scheint es nicht kostenlos zu geben? Und nach dem installieren taucht er dann auch im AVR Studio als Auswahl für neue Projekte auf?
>Du hast oben geschrieben, dass du BASCOM bevorzugst, weil man Basic und >Assemlber Code einfach mischen kann. Lass Bascom Bascom sein, und bleib bei C. Es gibt wirklich nichts, was damit nicht geht, auch Assembler mischen geht ganz einfach, falls man es denn wirklich mal braucht (was ich arg bezweifele). Extra dafür mit Basic anzufangen, ist -piep-. Und nimm als Einstieg lieber gleich einen ATMega644. Ist pimkompatibel zum Mega32, hat aber doppelt so viel Speicher. Da brauchst du dir zunächst mal keine Sorgen zu machen. Vermutlich wird später für deine Anwendung ein Mega8(8) völlig ausreichen, der Umstieg ist dann aber einfach. Die Dinger sind bis auf Speicherbestückung und Pinanzahl alle ziemlich identisch. Oliver
Angehängte Dateien:
-
SC.jpg
26 KB
Manuel, > Du hast oben geschrieben, dass du BASCOM bevorzugst, weil man Basic > und Assemlber Code einfach mischen kann. > Macht es das in vielen Bereichen für dich "nur" einfacher, oder > sind alleine mit C sonst Funktionen nicht erreichbar? Du kannst alles mit C machen. Es ist meine persönliche Vorliebe, Basic da zu verwenden, wo's zeitlich unkritisch ist und Assembler da wo's speicher/code-effizient und zeitkritisch ist. Bei ersterem reicht mir die Leistung die Bascom bringt locker aus, bei letzerem kann ich das so schnell/effizient schreiben, wie ich will und muss mich nicht dem C Compiler ausliefern. Hab' mir mal Eclipse und den AVR GCC installiert, das ist keine schlechte Programmierumgebung, aber um anzufangen brauchst Du erstens Durchsetzungs- und auch Leidensbereitschaft, zweitens ist meiner Meinung nach im GCC die Anwendung von Inline Assembler nur noch ein Albtraum, ein "Pain in the Ass", wie die englischsprachige Community dazu sagen würde. Ich komm mit Bascom gut klar, dränge aber niemand meine Meinung auf, das wirst Du von der C Community nicht unbedingt behaupten können, die empfinden alles Andere als C als Quatsch. Ohne hier einen Flamewar anzetteln zu wollen, C'ler haben eine deutlich geringere Toleranz gegenüber anderen Sprachen, als Basic Verwender. Wirst Du hier im Forum sehen. Z.B. Oliver's -piep-, was immer das jetzt sein soll... Für Dich kann jedoch auch interessant sein, woher Du im Zweifelsfall Hilfe bekommst, hier im Forum wirst Du gute Hilfe zu C bekommen, auch ein Paar Bascom Programmierer sind hier unterwegs, so wie ich :D Im Bascom Forum wirst Du gute Hilfe zu Bascom finden, eher weniger zu C. Deswegen such' Dir einfach aus, was Du magst. GCC ist umsonst, Bascom kostet was in der Codegröße unbegrenzten Version, die kostenlose Demo geht, glaube ich, 4K Code, das reicht aus für die Tinys. Daneben gibt's auch noch Micro Pascal und andere C Compiler, bei denen Du wiederum den AVR GCC in die Tonne klopfen würdest. Die kosten aber durchaus richtig Geld. Aber soviel zu dem. Der STK600 ist sozusagen die modernere Form des STK500, vorzugsweise für die fortgeschritteneren/neueren AVR's gedacht, aber auch für Mega32 oder Tiny verwendbar. Das Carrier Board für den 500er sollte gerade eben erlauben, die moderneren AVR's verwenden zu können. Nimm ein Steckbrett, und wurstel einen Tiny2313 drauf, dann sieht's so aus wie auf dem Bild und funktioniert auch. Aber mach' sowas, wenn Du fit bist, nimm für den Anfang etwas sicher Funktionierendes. Das macht mehr Spass und gibt weniger Frust :-)
Amen. ... C'ler sind nicht intollerant, aber die basic-jünger werden alle in der hölle schmoren duckundwech ....
> ... C'ler sind nicht intollerant, aber die basic-jünger werden alle in > der hölle schmoren duckundwech .... He, he :D
MWS wrote: > Ich komm mit Bascom gut klar, dränge aber niemand meine Meinung auf, das > wirst Du von der C Community nicht unbedingt behaupten können, die > empfinden alles Andere als C als Quatsch. Das würd ich so nicht sagen. Es ist nur so: Wenn hier im Forum BASCOM Leute nach Hilfe fragen, dann sind die meistens so dermassen Blank was die Innereien ihres µC und wie man damit arbeitet betrifft, dass es schon nicht mehr schön ist. Scheint so, als ob die hohe Hardware-Abstaktion, die BASCOM mitbringt, die Leute faul macht, sich mit der Maschinerie darunter zu beschäftigen.
>Z.B. Oliver's -piep-, was immer das jetzt >sein soll... Es gibt überhaupt keinen Grund, für jemanden, der C und C++ kann, Basic zu lernen, nur weil er AVR's programmieren möchte. Und einem Programmieranfänger würde ich es auch nicht empfehlen. "...ist meiner Meinung nach im GCC die Anwendung von Inline Assembler nur noch ein Albtraum, ein "Pain in the Ass", wie die englischsprachige Community dazu sagen würde." Stimmt. Das ist eine krampfartige Krücke, und mehr soll es auch gar nicht sein. Sollte es tatsächlich mal erforderlich sein, etwas in Assembler zu schreiben, kommt das in eine eigene Datei, in reinem Assemblercode. Mit sauberer Struktur und definierter Schnittstelle. Oliver
> Scheint so, als ob die hohe Hardware-Abstaktion, die BASCOM mitbringt, > die Leute faul macht, sich mit der Maschinerie darunter zu beschäftigen. So wie die Leute, die C++ mit dem ganzen stdlib-HighLevel-Schnickschnack lernen. Ach, ist das nicht der Weg, den du immer empfiehlst? Aber Basic als High-Level-Sprache ist ploetzlich schlecht fuer den Einstieg?
Ich würde dir empfehlen mal alle Infos die du im Netz über den Asuro findest zusammenzutragen. Der hat nämlich auch zwei Motoren (incl. Treiber) und zwei Drehencoder (über Reflexlichtschranken) dazu sind dann auch alle Quellen (C, Asm, ...) offen und es gibt eine fertige AsuroLib (auf Sourceforge in C) worin solche Sachen wie Geradeauslauf schön einfach gelöst sind, hat aber auch noch Verbesserungspotential. Die Schaltung kannst du dann fast 1:1 übernehmen oder dir für die Motoren was anderes einfallen lassen, ganz wie du magst. Wenn Du dir den Atmega8 aus dem Asuro direkt besorgst kannst du auch auf den Programmer verzichten, da dieser einen seriellen Bootloader hat. Ich halte das für einen sehr schönen Einstieg, sowohl in die Elektronik als auch in die µC Programmierung, ob mit oder ohne die Hardware, da gibt es Dokus satt und man kann beliebig viel lernen dabei. Und in deinem Fall kannst du schon fast eine fertige Lösung rausziehen und über die Dekodierung eines Servo/Empfängersignals findet man an anderen Stellen auch schon sehr viel Infos. Ich finde deinen Idee das so exakt und elegant wie möglich machen zu wollen super, da es ein überschaubares System ist an dem man dennoch sehr viel herumprobieren kann. Meine persönlichen Top 5 mit fallendem Anspruch (Eleganz) wären wie folgt: 1. BLDC ohne Sensoren (Back-EMF, eigener Treiber oder evtl. der vom Mikrokopter) 2. BLDC mit Hall Sensoren (wie bei Festplatten oder CD roms zu finden, vereinfacht natürlich die Regelung) 3. DC-Motoren + Encoder (s. Asuro, dürfte die einfachste Lösung sein mit einer echten Regelung) 4. Schrittmotoren (funktioniert sicher toll fände ich aber fast ein bisschen Langweilig weil es keine Regelung ist. Wenn du aber natürlich selbst an der mikrostep Ansteuerung schraubst entfällt jede Art von Langeweile, mit zusätzlichen Encodern zur Erkennung von Schrittverlusten wird dann sogar wieder richtiger Spass draus.) 5. Jede Lösung die fertige Fahrtenregler verwendet. (das ist jetzt natürlich schon sehr subjektiv) Die Liste müsste so eigentlich auch fast die Effizienz der Antriebe wiedergeben. Ach ja wenn du die BLDCs dann auch noch mit einer Sinusoidal modulierten PWM ansteuerst wäre das natürlich doppelplus Gut aber dann ist dein erstes Jahr vermutlich auch schon fast vorbei. Außer Konkurrenz: Das geregelte Sperrdifferenzial von dem Panzer, ist elektrisch natürlich stumpf, entbehrt aber nicht eines gewissen Reizes, zusammen mit Encodern kann das aber natürlich auch ein heiterer Regelspass werden. ;) -wiebel
Irgendwie ist das alles oversized. Wenn das Schiff nicht sowieso schon ungeregelt geradeaus fährt, reicht doch ein Sensor mit sehr wenigen Impulsen pro Umdrehung, um die Drehzahlen ausreichend genau aneinander anzugleichen. Das ist ja alles nicht hochdynamisch. Ich sehe da auch eher die Schwierigkeit, dem Dampfer so genau zu bauen, daß der nicht von sich aus eine leichte Kurve fährt. Oliver
Ich hab Manuel jetzt auch eher so verstanden, das er Spaß an der Materie entwickelt und richtig loslegen will. -wiebel
@Karl Heinz: meiner Meinung nach muss ein C-Programmierer durch den prinzipiell schwierigeren Einstieg in die Sprache bereits ein höheres Grundwissen mitbringen. Keine Ahnung vom Innenleben eines AVR's zu haben ist dagegen nicht nur Privileg von Bascom Programmierern, das seh' ich bei C Anwendern auch zur Genüge. Das Kapseln der Register und Prozessoreinheiten ist dagegen etwas, daß bei Bascom den Einstieg erleichtert, möglicherweise etwas das Neulinge anzieht, und dann gibt's halt auch viele Neulingsfragen. @Oliver: Es ist halt höchst angenehm zu schreiben:
1 | Dim a as Byte |
2 | a = &h05 |
3 | $asm |
4 | LDS R26, {a}
|
5 | LDI R27, &h10 |
6 | ADD R26, R27 |
7 | STS {a}, R26
|
8 | $end asm |
9 | a = a / 2 |
10 | ... |
Das Ganze ohne mir jetzt den Inline Murks des GCC anzutun, und ohne eine externe Datei dafür schreiben zu müssen. Aber wie gesagt, meine persönliche Vorliebe ist es Bascom/ASM zu mischen, wer das nicht so macht, für den sind möglicherweise andere Aspekte wichtiger. Ich lass' z.B. auch Bascom's Config Kram weg, denn genauso problemlos ist es möglich die Prozessorregister dort direkt zu adressieren. Und das ist das eigentlich Schöne: Ich hab' die Wahl. Die hab' ich mit den Inline Verrenkungen des GCC nicht wirklich.
Juppi wrote: > Ach, ist das nicht der Weg, den du immer empfiehlst? Aber Basic als > High-Level-Sprache ist ploetzlich schlecht fuer den Einstieg? LOL. Da hast du nicht so unrecht. Ich bin allerdings trotzdem der Meinung, dass jeder Programmierer seine Basissachen wie lineare Listen, dynamische Arrays u.dlg können muss. Im täglichen Programmieralltag kann er dann ja std::list, std::vector u dlg. benutzen. Von einem Werkzeugmacher erwarte ich ja auch, dass er nach wie vor mit Säge und Feile umgehen kann, auch wenn er in der tatsächlichen Produktion auf CNC Drehmaschinen und Fräsbänken arbeitet.
MWS wrote: > Keine Ahnung vom Innenleben eines AVR's zu haben ist dagegen nicht nur > Privileg von Bascom Programmierern, das seh' ich bei C Anwendern auch > zur Genüge. > > Das Kapseln der Register und Prozessoreinheiten ist dagegen etwas, daß > bei Bascom den Einstieg erleichtert, möglicherweise etwas das Neulinge > anzieht, und dann gibt's halt auch viele Neulingsfragen. Das ist fraglos auch eine gute Sache. Nicht falsch verstehen: Ich hab nichts gegen BASCOM. Hab auch selber schon überlegt, da mal ein paar Dinge damit zu realisieren, eben weil ich mir dann nicht mehr aus den Datenblättern die Einzelheiten zusammensuchen muss. Auf der anderen Seite ging das dann immer schnell und war eigentlich nie das grosse Problem in einem Projekt.
>Es ist halt höchst angenehm zu schreiben: >... Das mag ja angenehm sein, es ist aber auch höchst sinnlos. Nicht nur dein vereinfachtes Beispiel, sondern in den allermeisten Fällen generell. Wenn dein Code Größen- oder Geschwindigkeitsmäßig von ein paar wenigen Inline-Assembler-Befehlen abhängt, hast du ein ernsthaftes Design-Problem in deiner Software. Das mag erforderlich sein, wenn man aus Platz- und/oder Kostengründen den allerkleinsten Tiny in riesen Stückzahlen einsetzten muß, aber dann nimmt man erst recht kein Bascom. >a = a / 2 Da darf es dann wieder der Compiler übernehmen. Schade, eine lesbare, schnelle und fehlersichere Divisionsroutine in inline-Assembler hätte ich jetzt hier doch gerne gesehen. Abgesehen davon, gcc, und vermutlich alle anderen ernsthaften C-Compiler, würde die Zeile in ein einfaches Rechts-Shift optimieren. Kürzer und schneller geht es nicht. Ganz ohne Assembler. Keine Ahnung, was Bascom daraus macht. >Und das ist das eigentlich Schöne: Ich hab' die Wahl. Nein. Anscheinend bist du gezwungen, so etwas zu nutzen. Normalerweise braucht man so etwas eben so gut wie nie. Oliver
Karl heinz Buchegger wrote: > Das ist fraglos auch eine gute Sache. > Nicht falsch verstehen: Ich hab nichts gegen BASCOM. Hab auch selber > schon überlegt, da mal ein paar Dinge damit zu realisieren, eben weil > ich mir dann nicht mehr aus den Datenblättern die Einzelheiten > zusammensuchen muss. Auf der anderen Seite ging das dann immer schnell > und war eigentlich nie das grosse Problem in einem Projekt. Nachtrag: Was mich am BASCOM eigentlich immer abgeschreckt hat ist, dass man arithmetische Ausdrücke so zerstückeln muss. Für mich eigentlich unverständlich, warum man da keinen vernünftigen Expressionparser reinmachen kann. Aber der/die Autoren werden schon ihre Gründe dafür haben.
@Oliver: > Nein. Anscheinend bist du gezwungen, so etwas zu nutzen. Normalerweise > braucht man so etwas eben so gut wie nie. Wenn Du weist, was ich brauche, dann ist's ja gut :D Bin immer froh, wenn ich das selber weis. Aber ernsthaft, ich reize die Hardware dort aus wo ich es als sinnvoll betrachte. Wenn das ein "Zwang" ist, dann soll'st halt recht haben. Mein vereinfachtes Beispiel sollte auch nur die Verwendung von ASM in Bascom demonstrieren, für sowas Einfaches hätte das Gezeigte keinen Sinn. Ein richtiger Fall ist eine zeitkritische ISR, z.B. schnelle Abfrage des ADC und nebenbei noch etwas Anderes, und möglichst viel davon. Da zählt dann schneller und kleiner Code. Für: wenn Taster gedrückt, dann schalte LED ein, brauch' ich's sicher nicht. Wie Du möglicherweise bemerkt hast, verstehe ich sowohl C, als daß ich es auch schreiben kann. Vielleicht weniger gut als Bascom, einfach aufgrund der Übung. Bis jetzt habe ich keinen Grund gefunden, in C zu schreiben. >Karl heinz Buchegger wrote: >Nachtrag: > Was mich am BASCOM eigentlich immer abgeschreckt hat ist, dass man > arithmetische Ausdrücke so zerstückeln muss. Das ist etwas, was ich gerne geändert wüsste.
Hallo, komisch das so viele Forumsbeiträge in die Diskussion um die beste Programmiersprache ausarten. Ist Euch schon mal aufgefallen, daß die bekennenden Assemblerprogrammierer da fast nie mitreden? Offenbar ist denen egal mit was einer proggt. Ansonsten findet doch jeder die Sprache besser, welche er kann. Ich programmiere die AVRs auch am liebsten mit Bascom, obwohl ich in der Firma C programmiere. Aber das hat alles nichts mehr mit der ursprünglichen Frage zu tun. Eigentlich schade ! Gruß Jürgen
>Ein richtiger Fall ist eine zeitkritische ISR, z.B. schnelle Abfrage des >ADC und nebenbei noch etwas Anderes, Ich sach ja, Design-Problem, oder keine Vorstellung davon, was das Programm und Prozessor wirklich machen. Wenn du Bascom oder C die ISR-Grundfunktionalität machen lässt, und dann in der ISR mit inline-Assembler anfängst, gehen vorher schon so viele Takte für Register pushen drauf, daß es auf "schnell" im Sinne von einem (eventuell) zusätzlich eingesparten Takt durch inline-Assembler garantiert nicht mehr ankommt. Abgesehen davon sind Register- und Portzugriffe in C (und vermutlich auch in Bascom) genausoschnell wie in Assembler, da die auf die entsprechenden Assmblerbefehle 1:1 umgesetzt werden. Wenn es da zeitkritisch ist (und das bedeutet wirklich, das es auf einzelne CPU-Takte ankommt) dann hilft nur noch, das Register-Retten selber zu machen (was übrigends auch in C geht), die ISR so zu designen, daß gar keine Register gerettet werden müssen, oder eben gleich die ISR ganz in Assembler zu schreiben. Alles kein Grund für inline-Assembler. >und möglichst viel davon. Da zählt Design-Problem... >...schneller und kleiner Code. Richtig. Geht in C genauso, wie in Assembler. Oliver
be-cool, naja, das war dann schon irgendwie meine Schuld, nachdem ich möglichst dem TE noch einen neutralen Hinweis auf die verfügbaren Sprachen geben wollte. Andererseits sah's aus, als ob er mit der vorher gegebenen Info durchaus zufrieden war. Vielleicht hilft ihm dieser Teil der Diskussion zu erkennen, womit er am liebsten arbeiten möchte, bzw. wie Anwender der einen oder anderen Sprache die Sache so sehen. Also denke ich nicht, daß er enttäuscht ist. Solche Diskussionen entstehen natürlich oft mit dem Hintergrund, in missionarischen Eifer den zukünftigen µC Programmierer auf den rechten Pfad der Tugend zu führen :D Wegen meiner kann er nehmen, was er will, die Prinzipienreiterei ist doch Krampf. Denn egal was den Job gut und für mich angenehm erledigt, ist perfekt für mich. Ist doch nur'n Werkzeug, um dieses schwarze Teil mit den silbernen Füßen dran zu überzeugen, das zu tun was ich will. Und wenn eine Dikussion etwas auswandert, finde ich es zum Teil sehr interessant und manchmal auch amüsant. Da muss man nix schade finden. @Oliver: Sollt'st recht haben, klar, ein Designproblem. Sagte ja schon, es ist gut daß Du weist, was ich mache. Nur, Du interpretierst meine Worte in Deinem Sinn. Offen gesagt, nach Deinem Eifer zu urteilen glaube ich, für Dich trifft Obengesagtes zu. Das Keyword für Bascom heist übrigens NOSAVE, damit weist man den Compiler an, die Register nicht zu sichern. Könnt' es sein, daß Du über Bascom redest, obwohl Du keine Ahnung davon hast ? Und wie kommst Du eigentlich auf die irrige Idee, daß andere Leute außer Dir auf der Brennsuppe dahergeschwommen sind ? Ist Dir schon aufgefallen, daß Du der beste Beweis meines Intolleranz Argumentes bist ?
Um aufs Thema zurückzukommen: Neben der mechanischen Variante "Differential" reicht doch auch eine schaltbare Kupplung. Zum Manövrieren mit unterschiedlichen Raddrehzahlen wird die geöffnet, sonst verbindet die beide Räder. Damit bist du dann in wirklich allen Betriebszuständen synchron, selbst bei Notstopps mit plötzlichem "AK zurück". Oliver
manuel, wenn du eine einger maßen vernünftige fernsteuerung hast, die einen v-mischer bietet, dann nimm einfach 2x bl-motor und 2x b-controller mit govenor und die sache hat sich.
>Sollt'st recht haben, klar, ein Designproblem. Sagte ja schon, es ist >gut daß Du weist, was ich mache. Ich habe kein Ahnung davon, was du machst. Ich bestreite nicht, daß man mit Bascom alles auf eine AVR machen kann, was überhaupt möglich ist. Ich bezweifele auch nicht, daß man generell in jeder Programmiersprache modulare, gut strukturierte, les- und wartbare Programme schreiben kann, wenn man denn kann. Es darf und soll nutzen, was wer will. Das ist gar nicht das Thema. Das Thema ist dein Argument, daß selbst für den C-erfahrenen Threadersteller Bascom zur AVR-Programmierung die bessere Wahl sei, weil dort inline-Assembler besser unterstützt wird, als in C. Das Argument ist nunmal Blödsinn, und du kannst es nicht belegen. Mischen von Hochsprache und Assembler in einer Funktion hat überhaupt keine Vorteile, nur Nachteile. Die Fälle, in denen es unbedingt erforderlich ist, sind so extrem selten, daß sie als Argument pro oder contra C/Bascom völlig zu vernachlässigen sind (auch wenn es bein gcc tatsächlich ein "pain in the ass" ist). Bascom ist dann klar im Vorteil, wenn es um schnelle Erfolgserlebnisse bei der Realisierung kurzer, überschaubarer und nah an den Prozessorfunktionen liegender Programme geht. Eine LED blinkt mit Bascom schon, da ist Eclipse noch nicht mal fertig gestartet. Oliver
> Das Thema ist dein Argument, daß selbst für den C-erfahrenen > Threadersteller Bascom zur AVR-Programmierung die bessere Wahl sei, > weil dort inline-Assembler besser unterstützt wird, als in C. Oliver, Du hast ganz sicher ein Problem zu verstehen, was Dein Gesprächspartner sagt. Hör doch mal genau hin. Und jetzt schaust Dir meine Posts in dem Thread an, und Du wirst feststellen, daß ich immer sage, es gefällt mir, verstehst Du: MIR. Somit führe ich kein diesbezügliches Argument und ich erhebe auch keinen Anspruch auf Allgemeingültigkeit. Weiter begründe ich warum mir das so gefällt, und rate ihm er solle doch nehmen, was ihm besser liegt. Ich bin also tolerant gegenüber der von Dir bevorzugten Programmiersprache, die nicht unbedingt anfängerfreundlich ist. Zu dieser Toleranz bist Du offenbar nicht fähig. Da Manuel sowohl in VB, als auch in C Erfahrung hat, soll er nehmen, was er möchte. Nimmt er Bascom, vielleicht gefällt's ihm nicht, dann macht er halt mit etwas anderem weiter. Oder umgekehrt. Mich würde allein so ein dünbrettgebohre abschrecken, wie hier von Deiner Seite kommt. War ich jetzt immer noch nicht verständlich für Dich ? Quintessenz: ein guter Programmierer wird gute, intelligente und da wir hardwarenah arbeiten auch schnell Algorithmen benutzen, und eine passende Programmiersprache als Werkzeug seiner Wahl. Egal welche Sprache, die Betonung liegt hier auf "passende". Nur wäre derjenige ein Narr, der denkt er kann C und wäre deswegen automatisch ein guter Programmierer. Gaaaanz falsch.
Irgendwie habe ich das Grundproblem noch nicht verstanden. Sollen die Schaufeln immer gleich laufen, waere ein Motor und eine Welle die ideale Wahl. Soll das Schiff moeglichst geradeaus laufen (ohne Rudereinsatz), laesst sich das IMO am besten ueber 2 komplett separate Motoren und eine Trimmung realisieren - da wuerde ich idealerweise einfach die vom (Computer)-Sender nehmen...
gute programmierer? lol. die meisten sind zufrieden, wenn das, was sie vorhaben, irgendwie gelingt, und der chef nicht draufkommt, das der wunderwuzzi keinen tau hat.
Peter Stegemann wrote: > Irgendwie habe ich das Grundproblem noch nicht verstanden. Sollen die > Schaufeln immer gleich laufen, waere ein Motor und eine Welle die ideale > Wahl. Soll das Schiff moeglichst geradeaus laufen (ohne Rudereinsatz), > laesst sich das IMO am besten ueber 2 komplett separate Motoren und eine > Trimmung realisieren - da wuerde ich idealerweise einfach die vom > (Computer)-Sender nehmen... ... solange die Motoren bei gleichen variablen Versorgungsspannungen auch gleiche Drehzahl haben. Und genau davor fürchtet sich der OP: Das bei jeder Gasstellung eine andere Trimmstellung notwendig sein könnte.
>Du hast ganz sicher ein Problem zu verstehen, was Dein Gesprächspartner >sagt. Hör doch mal genau hin. Habe ich. Und nur ein unsinniges Argument gehört. Auch wenn es dein "ganz persönliches" ist, und selbstverständlich nur für dich und sonst niemanden gilt. Warum schreibst du es dann überhaupt? Nicht nur in einem Nebensatz, nein, gleich absatzweise. Mit solchen "Hinweisen": >Du wirst hier im Forum einige Mitglieder finden, die sich abschätzig >über Bascom äußern. Nimm die Sprache, in der Du lieber programmierst. >C'ler haben eine deutlich >geringere Toleranz gegenüber anderen Sprachen, als Basic Verwender. nur, um dann deine ach so große Toleranz zu beweisen. Danke, ich habe den Werbefeldzug pro Bascom gehört. Nicht nur der Inhalt, auch der Ton macht die Musik. Für mich persönlich (!!!) ist und bleibt das Argument mit der besseren inline-Unterstützung ganz großer, an den Haaren herbeigezogener, Bullshit, aber selbtsverständlich darf jeder dazu seine einen Meinung haben. Ich bin ja, genauso wie du, sehr tolerant. Und natürlich schreibe auch ich hier grundsätzlich nur meine ganz persönliche Meinung. Was anderes geht in solche einem Forum gar nicht. Mir persönlich (!!!) reicht der Fakt, daß im Lauf der Zeit nach Basic (und FORTRAN) andere Programmiersprachen entwickelt wurden (auch modernere Basic-Dialekte), die sich durchgesetzt haben. Für mich persönlich (!!!) gibt es keine einzigen Grund, Basic in auf eine Mikrocontroller einzusetzen. Ich persönlich (!!!) habe vor Jahren mit Basic meine ersten Programmschritte gemacht (Commodore 64, Dragon 32 und wie sie alle hiessen), und bin heilfroh, daß sich da andere die Mühe gemacht haben, aus den Erfahrungen mit Fortran (und dem daraus abgeleitetem Basic) zu lernen, und neuere, modernere und weitaus besser strukturierte Programmiersprachen zu ersinnen. Ich persönlich (!!!) habe Jahre damit verbracht, mich in semiprofessionellen (sprich: hochschul- :-) steuerungsnahen Softwareprojekten durch Sourceode von anderen Leuten zu wühlen und zu darin zu programmieren, in FORTRAN, Pascal, C, C++, Eiffel, Lisp, unter Dos, Unix, Windows, Apple Mac, VxWorks, in Assembler auf allen mögichen Prozessoren. Nirgends perfekt, aber überall ausreichend. In allen Programmiersprachen gab es gut gemachte und schlecht gemachte Programme. Ausnahme: Fortran. Da überwiegten (nach meiner ganz persönlichen (!!!)Meinung) die schlechten. Basic kam da schon gar nicht mehr vor, ist aber leider zu nah dran an Fortran. Alles meine ganz persönliche Meinung. Wer das anders liest, ist selber schuld. >Mich würde allein so ein dünbrettgebohre abschrecken, wie hier von >Deiner Seite kommt. Mich würde einfach ein klitzekleines Besipiel überzeugen, in dem du zeigst, daß inline Assembler in Bascom ein Problem so grundsätzlich besser, eleganter, kürzer, einfach irgendwie überzeugend, löst, daß sich deine ganz persönliche Empfehlung an den Threaderöffner, C statt Bascom einzusetzen, nachvollziehen lässt. Oliver Oliver
Oliver, mit Dir eine Diskussion zu führen erinnert mich an ein nörgelndes Kind, das glaubt sein Spielzeug ist das Beste. Großes Geschrei, wenn jemand etwas anderes sagt. Wenn derjenige, der vor dem µC sitzt, ein schlauer Kopf ist, dann sucht er sich schon die Programmiersprache mit der er gut klarkommt. Hab' da beim Manuel überhaupt keine Zweifel, daß er das Richtige findet. Auch wird seine Seele sicher nicht der Hölle anheim fallen, sollte er Bascom, oder etwas Anderes ausprobieren. Nur weil Du im Laufe Deines Studiums oder Berufes eine Lösung für Dich gefunden hast, ist sie noch lange nicht auf Andere übertragbar. Eigenartigerweise gibst Du doch selbst zu, klein angefangen zu haben, wieso gestehst Du das nicht auch Anderen zu ? Und jetz ist Bascom im Vergleich alles Andere als "klein". Jetzt kann's ja sein, daß dieses Thema Dich irgendwie besonders aufregt, darum meinn Rat: Mach Dich locker. Glaubst Du im Ernst, ich such hier jetzt nach Codeschnipseln, nur um Dich von irgendwas zu überzeugen ? Das ist weder mein Ziel, noch hab' ich's nötig, ich weis was ich kann. Selbst wenn ich Dir eine in Bascom codegewordene Desoxyribonukleinsäure zeigen würde, bekäm' ich das gleiche Genörgel, von wegen C ist besser, das wäre auch in C besser gegangen, usw. Glaubst Du ich steh' auf so was ? > daß sich deine ganz persönliche Empfehlung an den Threaderöffner, > C statt Bascom einzusetzen, nachvollziehen lässt. Nochmal gaaaaanz langsam, zum langsamen mitdenken: Ich habe die Vorzüge von Bascom aus meiner Sicht dargestellt und Manuel geraten, er möge nehmen, was ihm besser zusagt. Ich habe nicht gesagt, nimm C statt Bascom, und auch nirgends gesagt, nimm Bascom statt C. Ich hab' gesagt, nimm, was Dir gefällt. Bist Du begriffsstutzig?
>Glaubst Du im Ernst, ich such hier jetzt nach Codeschnipseln, nur um >Dich von irgendwas zu überzeugen ? Das ist weder mein Ziel, noch hab' >ich's nötig, ich weis was ich kann. Es war dein Argument, nicht meins. Und es war so ungewöhnlich, daß ich da gerne noch etwas gelernt hätte. Ach ja, entschuldige, daß ich bei deiner Erwähnung, einen ADC im Interrupt auslesen zu können, nicht gleich in Ehrfurcht erstarre. Die obige Antwort reicht mir persönlich. Machen wir hier einfach Schluß. Oliver
Karl heinz Buchegger wrote: > ... solange die Motoren bei gleichen variablen Versorgungsspannungen > auch gleiche Drehzahl haben. Und genau davor fürchtet sich der OP: Das > bei jeder Gasstellung eine andere Trimmstellung notwendig sein könnte. Hm, das Problem sollte sich z.B. mit buerstenlosen Motoren und passenden Reglern (nicht Stellern, also mit Heli- oder Governer-Mode) loesen lassen.
>Hm, das Problem sollte sich z.B. mit buerstenlosen Motoren und passenden >Reglern (nicht Stellern, also mit Heli- oder Governer-Mode) loesen >lassen. Das sollte auch mit "billigen" Bürstenmotoren gehen. [OT] Was soll eigentlich schon wieder dieses Auf-Programmiersprachen-Rumgereite? Der Algorithmus ist die Lösung des Problems, nicht die Sprache in der man ihm aufschreibt. Das ist dann eher eine Optimierung. (Öl ins Feuer: C ist das bessere Optimier-Werkzeug! ;) [/OT]
Was machen denn die armen Modellbauer mit Mehrschrauben-Antrieben in ihren Modellen? Ich glaube kaum, daß da auch nur einer über Synchronisation nachdenkt. Da gibt es so viele Störungen durch Wellen und Wind, geradeaus fährt da auf Dauer sowieso nichts von alleine. Und die "echten" Dampfschiffer, wenn sie denn überhaupt zwei Dampfmaschinen hatten, waren bestimmt schon froh, wenn die beide ungefähr in die gleiche Richtung liefen. Den Rest machte der Käptn am Rad. Die mit nur einer Maschine hatten zwar das Problem mit den Drehzahlen nicht, am Rad drehen musste der Käptn aber genauso :-) Oliver
Oliver sieht es genau richtig. Drehzahlunterschiede von 10% bemerkt man überhaupt nicht. Andreas
STK500-Besitzer wrote: >>Hm, das Problem sollte sich z.B. mit buerstenlosen Motoren und passenden >>Reglern (nicht Stellern, also mit Heli- oder Governer-Mode) loesen >>lassen. > Das sollte auch mit "billigen" Bürstenmotoren gehen. Nur sind die meist sowieso nicht billiger und die Regelung nicht integriert.
Mal abgesehen davon, dass zwischenzeitlich der "Krieg" hier mehr Platz einnimmt als die Problemlösung - Anfangs war ich ja überrascht, dass dieses Forum besser funktioniert... wie blauäugig - finde ich es interessant, dass immer mehr Leute erklären, warum die Idee, Aufgabe wie auch immer so nicht sinnvoll ist. Natürlich kann ich eine durchgehende Welle einbauen und ich bezweifle auch nicht, dass ein guter Geradeauslauf ohne zusätzliche Steuerung möglich ist. Fakt ist: ich will, dass die Schaufeln synchron laufen. Ob ich das will weil ich glaube, dass damit der Dampfer am besten funktioniert oder ob ich das einfach will, weil mir dann mein Schnitzel besser schmeckt spielt doch keine Rolle! Aber vielleicht baue ich am Ende auch einfach einen Raketenantrieb ein und lass die Schaufelräder durch die Wasserströmung antreiben...
Manuel wrote: > Fakt ist: ich will, dass die Schaufeln synchron laufen. > Ob ich das will weil ich glaube, dass damit der Dampfer am besten > funktioniert oder ob ich das einfach will, weil mir dann mein Schnitzel > besser schmeckt spielt doch keine Rolle! Hier kommen die ganze Zeit Leute an, die genau wissen, was sie wollen und nachher kommt raus, dass sie sich nur schon voellig verfranst haben. Du hast diverse Vorschlaege bekommen, ich habe dir auch nochmal einen gemacht, der sich mit Fertigteilen erledigen laesst - wie waer's mit einem Dankeschoen?
Mein Dankeschön habe ich oben schon mehrfach verbreitet - auch für einen Vorschlag mit Brushless Motoren... Und wenn ich einfach nur will, dass sich die Schaufeln synchron drehen, kann ich mich noch nicht weit verfranzt haben.
Hi Sei doch nicht gleich eingeschnappt. Vielleicht solltest du auch noch mal deinen Lösungsansatz überdenken. Wenn mich meinen Erinnerungen an meine (mehr passive Modellbauzeit) nicht trügen, werden 'modernere' Schaufelradantriebe nicht über die Drehzahl, sondern über die Stellung der Schaufeln gesteuert. Für einen maximalen Vortrieb werden die Schaufeln so gesteuert, das sie während der Eintauchzeit immer senkrecht zu Wasseroberfläche stehen. Die Schaufelräder drehen sich mit der gleichen Drehzahl (eine Achse). Allerdings stellt das einen recht hohen mechanischen Aufwand dar. Aus der Historie stammen Schaufelradantriebe aus der Dampfmaschinenzeit und waren bei grösseren (Segel-) Schiffen als Hilfsantrieb und bei kleineren als Hauptantrieb mit jeweils einer Dampfmaschine bestückt. Die Geschwindigkeit wurde über die Drehzahl und die Richtung mit dem Ruder bestimmt. Eine getrennte Reglung wäre in Hinsicht auf Vorbildtreue eigentlich nicht notwendig. MfG Spess
>Fakt ist: ich will, dass die Schaufeln synchron laufen.
Aussagen wie Synchron, Gleichzeitig, Sofort, Schnell, sind in
technischen Systemen grundsätzlich ohne genauere Definition, was das
eigentlich bedeuten soll, unbrauchbar und nicht erfüllbar.
Also: Was verstehst du unter "Synchron"?
Winkelsynchron, wie starr verbunden? Immer, in jedem
Geradeaus-Betriebszustand? Mit welcher zulässigen Abweichung, statisch
und dynamisch?
Winkelsynchron, zusätzlich mit dem Wunsch, daß im Geradeausbetrieb die
Schaufeln auf beiden Seiten gleichzeitig ein- und austauchen? Und wie
groß darf dann während des Ausregelns der Abweichung die maximale
Drehzahldifferenz sein?
Drehzahlsynchron? Mit welcher zulässigen Abweichung, statisch und
dynamisch?
Gehen tut (fast) alles. Aber wissen, was du wirklich willst, solltest du
schon.
Oliver
Hi Manuel, ich hoffe du hast trotzdem genügend Tipps bekommen um etwas davon umzusetzen, wenn ja informiere uns doch bitte wie du es am Ende gelöst hast und wie es geklappt hat. Vielleicht behältst du, der besseren Lesbarkeit des Threads wegen, die Wahl der Programmiersprache für dich. sigh -wiebel
Jetzt mal Hand auf's Herz: ich möchte, dass sich beide Seiten mit der gleichen Drehzahl drehen. Und dass meine Beschreibung akademischen, wissenschaftlichen oder meinetwegen auch nach Ingenieursmäßigen Prüfungen nicht Standhält, mag ja sein. Aber hast du Anhand der Beschreibung wirklich nicht verstanden, was das Ding tun soll?
Woher kommt eigentlich die Idee, dass einem besser geholfen wird, wenn man die potentiellen Helfer dumm anmacht?
Besser geholfen wird? Besser, als mit ner Diskussion über diverse Programmiermöglichkeiten?
>ich möchte, dass sich beide Seiten mit der >gleichen Drehzahl drehen. Hand aufs Herz: Wenn du zwei baugleiche Gleichstrommotoren nimmst, und auf beide an die selbe Spannungsversorgung hängst, ganz ohne Regelung, dann laufen die "gleichschnell". Du wirst an den Schaufelrädern mit blosem Auge keine Unterschied feststellen können, wenn die Mechanik nicht arg unterschiedlich klemmt (was ich bei deinem Perfektionsanspruch selbstverständlich ausschliesse :-) Optisch gleichschnell reicht aber nun anscheinend für deine Anwendung nicht aus, es soll "gleicher" sein. Da es aber deine Anwendung ist, die nur du kennst, musst du schon mal formulieren, was denn nun in deinen Augen "gleich" bedeutet. Oliver
Manuel wrote: > Besser geholfen wird? Besser, als mit ner Diskussion über diverse > Programmiermöglichkeiten? Du scheisst hier vor allem die an, die konkret versucht haben, dein Problem zu verstehen (z.B. Oliver). Vieleicht ist es besser, du bleibst in deinem Bastelkeller.
@Peter: Wie Du vielleicht erkennen kannst, wurde Manuels Thread benutzt, um akademische Sichtweisen über den Wert bestimmter Programmiersprachen unter die Leute zu bringen. Die Diskussion hab' ich eine Zeit lang selbst mitgemacht, es hat mich wirklich interessiert wie weit der Schmarrn gehen kann. Nun weis ich Bescheid und hoffe daß unsere Wirtschaft von solchen Erbsenzählern verschont bleibt, viel heiße Luft aber praktisch kommt nix raus. Mich stört selbst, wenn ein Hilfesuchender sich über gegebene Hilfe beschwert, hab' das bei Manuel aber in keiner Weise feststellen können, er ist meiner Meinung nach aus dem Gros der Fragesteller hier im Forum eindeutig einer der Guten. Das er sich übers Hijacking seines Threads beschwert, kann ich verstehen. Ohne nun viel reinzuinterpretieren, was Manuel nun genau will, so ist doch unter Berücksichtigung der typischen Funktionsweise eines Schaufelraddampfers und unter Berücksichtigung der Aussagen von Manuel meiner Meinung nach folgendes richtig: - Die Schaufeln sollen sich bei Geradeausfahrt synchron zueinander bewegen, in der Weise daß für das Auge kein Unterschied in der Umlaufgeschwindigkeit der Räder feststellbar ist. - Für deutliche Kurskorrekturen, bzw. Wendemanöver sollen die Schaufeln einzeln in Geschwindigkeit und Drehrichtung gesteuert werden können. - Bei Rädern mit vielen Schaufeln ist Winkelsynchronität nicht notwendig, da nicht wahrnehmbar, bei wenigen Schaufeln evtl. wünschenswert, Ansteuerung verkompliziert sich dadurch. Mögliche Antriebe: - Normale Elektromotoren mit Hallgeber und Getriebe - Kollektorlose Motoren mit Vorgabe der Solldrehzahl per serieller Ansteuerung - Schrittmotoren - Mit Encodern auf den Schaufelrädern lässt sich bei jeder der genannten Lösungen Winkelsynchronität erreichen Das sollte es einigermaßen treffen. :D
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.