Beiträge von Michael D

Kannst doch die Endstufenschaltung per Transistor ans Schaltnetz koppeln und vom µC einschalten lassen und dieser hat doch sicher ein paar EEPROM Bytes frei...

Was man (noch) nicht kann, kann man lernen. Wenn du den Kram schon da hast probiers doch einfach mal aus, ist wirklich kein Hexenwerk. (Natürlich vorausgesetzt, du hast auch was sinnvolles zu ätzen, weiss jetzt gerade nicht mehr sogenau, worums hier geht *g*)

Was man (noch) nicht kann, kann man lernen. Wenn du den Kram schon da hast probiers doch einfach mal aus, ist wirklich kein Hexenwerk. (Natürlich vorausgesetzt, du hast auch was sinnvolles zu ätzen, weiss jetzt gerade nicht mehr sogenau, worums hier geht *g*)

Hier gäbs noch einen für Spezialeffekte :)))
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&category=12469&item=7515302250&rd=1

Freut mich, aber den hättest du vermutlich mit weniger Aufwand als hier zu posten auch selbst finden können: google wurde erfunden...

http://www.artisticlicence.com/user-guides/art-net.pdf

Zitat

Mal noch ne Frage zum AD der AVR´s: is das nen echter AD oder auch so ne Krankheit wie bei den 89Cxx51 ?

Ich weis jetzt nicht was das "Kranke" für Dinger sind, aber die AD Wandler bei den AVRs würd ich schon als echt bezeichnen...
Machen wahlweise glaub ich 8 oder 10 Auflösung, wobei die AVRs bei den AD Wandlern nicht den Besten Ruf haben, PICs haben glaub ich die schnelleren. Grundsätzlich funzen die aber, hab die schon benutzt
Fast jeder AVR hat zusätzlich noch so nen Analog Comperator, der je nach Verhältniss zweier analoger Spannungen zueinander n Bit setzt oder so. Damit kann man auch AD Wandeln, wenn man noch nen DA Wandler (z.B. per PWM) hat, aber wer macht so nen Aufwand...

Zitat

Mal noch ne Frage zum AD der AVR´s: is das nen echter AD oder auch so ne Krankheit wie bei den 89Cxx51 ?

Ich weis jetzt nicht was das "Kranke" für Dinger sind, aber die AD Wandler bei den AVRs würd ich schon als echt bezeichnen...
Machen wahlweise glaub ich 8 oder 10 Auflösung, wobei die AVRs bei den AD Wandlern nicht den Besten Ruf haben, PICs haben glaub ich die schnelleren. Grundsätzlich funzen die aber, hab die schon benutzt
Fast jeder AVR hat zusätzlich noch so nen Analog Comperator, der je nach Verhältniss zweier analoger Spannungen zueinander n Bit setzt oder so. Damit kann man auch AD Wandeln, wenn man noch nen DA Wandler (z.B. per PWM) hat, aber wer macht so nen Aufwand...

Naja, ich mach das in der Uni in Projekten, (noch) nicht privat.
Ich dachte erst auch, wazu kann man das denn gebrauchen, es gibt doch Microcontroller. Aber wenn du dich z.B. mal auf http://www.opencores.org umschaust, siehst du, dass es da schon eine ganze Menge toller Projekte gibt. Und es ist einfach toll, mal eben nen anderen Prozessor reinzunehmen oder ne gerade benötigte Instruktion hinzufügen zu können. Und alles was du an Gluelogig und Peripherie sonst brauchst landet auch gleich auf dem Chip und man braucht eigentlich nur noch ein paar simple Tranceiver für die Signalanpassung.
Abstraktionsebene ist nicht heftiger, nur beschreibt man halt Hardware und nicht Software, das muss man verinnerlicht haben, dann wird VHDL auch leicht...
Klar, für einfache Sachen gerade im Lichtbereich ist das föllig oversized, aber es eröffnet einem irgendwie auch in Hardware die Flexibilität der Software. Aber lassen wir das Thema, wir sind hier in einem PA-Forum...

Naja, ich mach das in der Uni in Projekten, (noch) nicht privat.
Ich dachte erst auch, wazu kann man das denn gebrauchen, es gibt doch Microcontroller. Aber wenn du dich z.B. mal auf http://www.opencores.org umschaust, siehst du, dass es da schon eine ganze Menge toller Projekte gibt. Und es ist einfach toll, mal eben nen anderen Prozessor reinzunehmen oder ne gerade benötigte Instruktion hinzufügen zu können. Und alles was du an Gluelogig und Peripherie sonst brauchst landet auch gleich auf dem Chip und man braucht eigentlich nur noch ein paar simple Tranceiver für die Signalanpassung.
Abstraktionsebene ist nicht heftiger, nur beschreibt man halt Hardware und nicht Software, das muss man verinnerlicht haben, dann wird VHDL auch leicht...
Klar, für einfache Sachen gerade im Lichtbereich ist das föllig oversized, aber es eröffnet einem irgendwie auch in Hardware die Flexibilität der Software. Aber lassen wir das Thema, wir sind hier in einem PA-Forum...

Ich glaub ich halt mich daraus, nur falls ihr noch nen AVR Code braucht, der n DMX Signal empfängt und daraus ein Richtungssignal für ein Wechslerrelais und ein PWM Signal (12 Bit) generiert sacht Bescheid (vielleicht als Basis oder so), hatte da mal was für nen Spiegelkugelmotor gebaut...
Ich beschäftige mich derweil weiter mit nem FPGA, weil die Teile sind sowiso noch viel geiler als jeder Microcontroller
Viel Erfolg egal bei welcher Variante!

Ich glaub ich halt mich daraus, nur falls ihr noch nen AVR Code braucht, der n DMX Signal empfängt und daraus ein Richtungssignal für ein Wechslerrelais und ein PWM Signal (12 Bit) generiert sacht Bescheid (vielleicht als Basis oder so), hatte da mal was für nen Spiegelkugelmotor gebaut...
Ich beschäftige mich derweil weiter mit nem FPGA, weil die Teile sind sowiso noch viel geiler als jeder Microcontroller
Viel Erfolg egal bei welcher Variante!

Manu:
Natürlich gehts hier nicht um Geschwindigkeit, aber son AVR ist nicht nur schneller, sondern auch viel billiger. Und wenn man sich mal mit einem auskennt, kann man auch mal n anderes Projekt welches mehr Performance benötigt schnell realisieren, wo man mit nem C-Control nur blöd guckt

Manu:
Natürlich gehts hier nicht um Geschwindigkeit, aber son AVR ist nicht nur schneller, sondern auch viel billiger. Und wenn man sich mal mit einem auskennt, kann man auch mal n anderes Projekt welches mehr Performance benötigt schnell realisieren, wo man mit nem C-Control nur blöd guckt

Nun im Prinzip ist das DMX Signal ja keine komplizierte Sache. So ne Empfangsroutine ist im Grunde ja ne Statemachine und man muss eben (neben ihrer korrekten Funktion) nur garantieren, dass sie genug Rechnzeit bekommt, d.h. konkret die Verzögerung zwischen Eintreffen eines Bytes am seriellen Port und dem Aufruf (und der Ausführungszeit) der entsprechenden Interruptroutine muss kleiner als 250000/11s^-1 sein, also 44 µs. Das musst du garantieren können, entweder indem du deine anderen interruptroutinen kurz hälst oder den DMX Interrupt auch in den anderen Interrupts erlaubst. Noch so Suchtipps: Hast du den 9 Bit Mode aktiviert, bzw. 2 Stoppbits eingestellt (9 Bit Mode find ich da cooler, da kann man auch gleich die Breakerkennung machen *g*). Der Unterschied in den generierten DMX Signalen verschiedener Quellen kann schon gross sein (verschiedene Delaylängen von Break, Interframedelays, Delays zwischen Datenbytes usw...), aber wenn deine Statemachine schnell genug aufgerufen werden kann sollte das alles kein Problem sein, weil die Minimalwerte sind ja festgelegt, bzw. ergeben sich aus aus der Tatsache, dass eben ein serielles Format mit 250KBit verwendet wird.
So, und um mich dem allgemeinen DMX Bastler Werbemode anzupassen:
Auf meiner Webseite findeste auch noch in der USB DMX Firmware nen DMX Empfangscode für AVRs

Ich versteh gar nicht, was die Leute an C Control so toll finden, dass die immer gleich als erstes dran denken...
Ich kenn mich mit diesem Teil jetzt nicht aus, von daher weiss ich nicht obs da verschiede Versionen gibt, aber das hier hab ich mal auf die Schnelle an Daten im Web gefunden:
---
Versorgungsspannung: stabilisiert 5V DC
Stromaufnahme: ca. 10 bis 30mA (LED's und RS232 abschaltbar)
Programmspeicher: 8 kB (CCBasic-Token)
Digitalports: 16 (einzeln programmierbar als Ein- und Ausgänge als Bit, Byte und Wort)
Analog-Eingänge: 8 (8-Bit Auflösung, im Controller gemultiplext, variable URef von 0 bis 5 V)
Analog-Ausgänge: 2 (8-Bit Auflösung, PWM-moduliert mit 1953 Hz)
Schnittstelle: RS232 (Verbindung über Adapterstecker und NULL-Modem-Leitung)
Abmessungen: 75x50x17mm (LxBxH)
Prozessor: Motorola 68HC05B6
---
Für was werden die Dinger verkauft? 30€ oder mehr?
Im Vergleich dazu z.B. ein ATMEGA8535 (4,40€ bei Reichelt). Praktisch alle Unterschiede zwischen C-Control und ATMEGA gehen positiv für den Mega aus:
5V stab. Spannung braucht auch der Mega, Programmspeicher hatter auch 8K, Digitalports hatter 32. Wenn man 8 Analoge eingangsports braucht hat man "nur noch" 24 digiports. PWM Ausgänge hatter auch. Serielle schnittstelle hatter auch, was ihm hier fehlt is lediglich der pegelumsetzter auf RS232. Den kann man hinzufügen wenn man den wirklich baucht. Brauchst du den?
Der Prozessor im C-Control ist wesentlich älter als so eine AVR Architektur. Und dieser super Basic-Compiler für den C-Control soll sowas von schnarchend langsamen Code generieren... da überhohlt der AVR den n paar mal bei...
Auch den AVR kannste z.B. in C proggen und ich meine es gibt sogar auch Basic dafür.
Und wenn du mal mehr IO ports brauchst nimmste nen anderen AVR Typ. die gibts bis zu 128KB Programmspeicher, mit bis zu 52 digitalen IO Pins, mit viel mehr RAM usw...
Und, wenn du mal sowas gemacht hast und verstanden hast, ermöglichst du dir eine riesen Fülle von Möglichen Aufgaben, die sich auf einmal per Microcontroller lösen lassen. Vieles ist Geschwindigkeitsmässig gar nicht mit C-Control möglich und er kostet ja auch viel mehr...
Also im Prinzip ist C-Control auch nur ein auf ne Platine gelöteter Microcontroller, welchem mit einem schlechten Compiler die Performance geraubt wird und teuer verkauft wird.
Vielleicht sollt ich sowas auch mal machen

Ich versteh gar nicht, was die Leute an C Control so toll finden, dass die immer gleich als erstes dran denken...
Ich kenn mich mit diesem Teil jetzt nicht aus, von daher weiss ich nicht obs da verschiede Versionen gibt, aber das hier hab ich mal auf die Schnelle an Daten im Web gefunden:
---
Versorgungsspannung: stabilisiert 5V DC
Stromaufnahme: ca. 10 bis 30mA (LED's und RS232 abschaltbar)
Programmspeicher: 8 kB (CCBasic-Token)
Digitalports: 16 (einzeln programmierbar als Ein- und Ausgänge als Bit, Byte und Wort)
Analog-Eingänge: 8 (8-Bit Auflösung, im Controller gemultiplext, variable URef von 0 bis 5 V)
Analog-Ausgänge: 2 (8-Bit Auflösung, PWM-moduliert mit 1953 Hz)
Schnittstelle: RS232 (Verbindung über Adapterstecker und NULL-Modem-Leitung)
Abmessungen: 75x50x17mm (LxBxH)
Prozessor: Motorola 68HC05B6
---
Für was werden die Dinger verkauft? 30€ oder mehr?
Im Vergleich dazu z.B. ein ATMEGA8535 (4,40€ bei Reichelt). Praktisch alle Unterschiede zwischen C-Control und ATMEGA gehen positiv für den Mega aus:
5V stab. Spannung braucht auch der Mega, Programmspeicher hatter auch 8K, Digitalports hatter 32. Wenn man 8 Analoge eingangsports braucht hat man "nur noch" 24 digiports. PWM Ausgänge hatter auch. Serielle schnittstelle hatter auch, was ihm hier fehlt is lediglich der pegelumsetzter auf RS232. Den kann man hinzufügen wenn man den wirklich baucht. Brauchst du den?
Der Prozessor im C-Control ist wesentlich älter als so eine AVR Architektur. Und dieser super Basic-Compiler für den C-Control soll sowas von schnarchend langsamen Code generieren... da überhohlt der AVR den n paar mal bei...
Auch den AVR kannste z.B. in C proggen und ich meine es gibt sogar auch Basic dafür.
Und wenn du mal mehr IO ports brauchst nimmste nen anderen AVR Typ. die gibts bis zu 128KB Programmspeicher, mit bis zu 52 digitalen IO Pins, mit viel mehr RAM usw...
Und, wenn du mal sowas gemacht hast und verstanden hast, ermöglichst du dir eine riesen Fülle von Möglichen Aufgaben, die sich auf einmal per Microcontroller lösen lassen. Vieles ist Geschwindigkeitsmässig gar nicht mit C-Control möglich und er kostet ja auch viel mehr...
Also im Prinzip ist C-Control auch nur ein auf ne Platine gelöteter Microcontroller, welchem mit einem schlechten Compiler die Performance geraubt wird und teuer verkauft wird.
Vielleicht sollt ich sowas auch mal machen

Also ich finde, wenn du schon auf die direkte Praxis eingehst solltest du auch realistisch bleiben:

Zitat

5 U/s dann macht der Motor 1 Umdrehung in 200ms !!!! Oh Gott, die arme Glühwendel der Kanne, find ich ein bischen Hart, auch mit perfekter Brems und Beschleunigungsrampe !!!

Aus dieser Aussage schliesse ich, dass du die Lampe direkt an die Motorachse montieren würdest. Dass das ziemlich bekloppt ist, weisst du aber sicher auch, oder? Wenn die Kanne nicht exakt gerade hängt brauchst du schon ein ganz schönes Drehmoment nur um sie zu halten... und dafür einen ziemlich dicken Stepper. Nehmen wir (im Sinne einer praktisch sinnvoll einsetzbaren Lösung) z.B. mal an, der OP will die Lampe gar vertikal schwenken lassen und ihm ist vielleicht die Schrittauflösung des Motors zu gering und er muss Mikroschritt einsetzten... Klar bekommt man Motoren und Steuerungen, die das können, aber ob sich der Aufwand lohnt? Dann doch lieber n Getriebe, nur muss dann der Motor deutlich schneller drehen und schon ist deine Aussage oben schon gar nicht mehr so logisch.

Zitat

Ich wollte mit dem Posting lediglich darauf hinweisen, dass Antriebe bei denen viel Kraft benoetigt wird (und zwar auch Kraft waerend sich der Motor dreht, sonst braeuchte man denn ja nicht *g*) sich besser mit einem "normalem" Motor mit irgendeiner Form von Sensor realisieren lassen

Hier hast du mein Zitat aus dem Zusammenhang gerissen, so dass der eigentlich Sinn nicht klar wird. Der Satz ging so weiter:

Zitat

weil man in der Elektronik eben nicht so viel Aufwand benoetigt (Mikroschritt, Stromregelung usw...) und man sich auch nicht so viele Gedanken ueber Schrittverluste manchen muss. Und das ist vor allem dann sinnvoll, wenn man das ganze nur einmal braucht.

Es ging mir also nicht darum zu zeigen, dass sich die Kanne zu schnell bewegen könnte, sondern darum, dass man für einen Stepperantrieb mit grösserer Last auch eine nicht ganz so triviale Elektronik und Software benötigt und dass da der Entwicklungsaufwand für ein "Einmalprojekt" im Vergleich zu einem Getriebemotor + Inc. Geber sicherlich höher ist...

Also ich finde, wenn du schon auf die direkte Praxis eingehst solltest du auch realistisch bleiben:

Zitat

5 U/s dann macht der Motor 1 Umdrehung in 200ms !!!! Oh Gott, die arme Glühwendel der Kanne, find ich ein bischen Hart, auch mit perfekter Brems und Beschleunigungsrampe !!!

Aus dieser Aussage schliesse ich, dass du die Lampe direkt an die Motorachse montieren würdest. Dass das ziemlich bekloppt ist, weisst du aber sicher auch, oder? Wenn die Kanne nicht exakt gerade hängt brauchst du schon ein ganz schönes Drehmoment nur um sie zu halten... und dafür einen ziemlich dicken Stepper. Nehmen wir (im Sinne einer praktisch sinnvoll einsetzbaren Lösung) z.B. mal an, der OP will die Lampe gar vertikal schwenken lassen und ihm ist vielleicht die Schrittauflösung des Motors zu gering und er muss Mikroschritt einsetzten... Klar bekommt man Motoren und Steuerungen, die das können, aber ob sich der Aufwand lohnt? Dann doch lieber n Getriebe, nur muss dann der Motor deutlich schneller drehen und schon ist deine Aussage oben schon gar nicht mehr so logisch.

Zitat

Ich wollte mit dem Posting lediglich darauf hinweisen, dass Antriebe bei denen viel Kraft benoetigt wird (und zwar auch Kraft waerend sich der Motor dreht, sonst braeuchte man denn ja nicht *g*) sich besser mit einem "normalem" Motor mit irgendeiner Form von Sensor realisieren lassen

Hier hast du mein Zitat aus dem Zusammenhang gerissen, so dass der eigentlich Sinn nicht klar wird. Der Satz ging so weiter:

Zitat

weil man in der Elektronik eben nicht so viel Aufwand benoetigt (Mikroschritt, Stromregelung usw...) und man sich auch nicht so viele Gedanken ueber Schrittverluste manchen muss. Und das ist vor allem dann sinnvoll, wenn man das ganze nur einmal braucht.

Es ging mir also nicht darum zu zeigen, dass sich die Kanne zu schnell bewegen könnte, sondern darum, dass man für einen Stepperantrieb mit grösserer Last auch eine nicht ganz so triviale Elektronik und Software benötigt und dass da der Entwicklungsaufwand für ein "Einmalprojekt" im Vergleich zu einem Getriebemotor + Inc. Geber sicherlich höher ist...

Wie im Kindergarten...