Hi, ich möchte alle 2 Sekunden die Drehzahlen von bis zu 32 Lüftern ermitteln und mit den Daten auf einem Arduino Mega 2560 weiterarbeiten. Der Messbereich soll zwischen 600 und 3000 RPM liegen, also wäre eine 12Bit-Variable zur Speicherung geeignet. Da der Arduino selbst noch viele andere Dinge tun soll, scheidet eine direkte Messung an dessen Pins aus, oder? Vor allem müsste ich die Signale selbst ja noch multiplexen usw. Eine externe Drehzahlbestimmung muss also her, die dem Arduino fertige Daten liefert. Der Arduino hat einen parallelen 8Bit-Bus, über den er schnell kommunizieren kann. Meine Idee: Die Signalleitungen der Lüfter liegen jeweils an einem 8Bit-Counter, der die Pulse zählt. Alle 2 Sekunden werden die Daten parallel ausgelesen und der Counter resettet. Ich könnte also bis zu 7680 RPM messen, was mehr als genug ist. Über 32-faches Multiplexing würden dann einfach nacheinander die OutputEnable-Pins der Counter angesteuert und der Wert über den parallelen 8Bit-Bus in den Arduino eingelesen. Meine Frage: Würde das so funktionieren? Gibt es dabei irgendetwas zu beachten? Gibt es bessere/günstigere/effizientere/platzsparendere Methoden? Vielen Dank und lieben Gruß Marlon
Man könnte aus ein paar CD405x einen 1:32 Multiplexer bauen und die Signale nacheinander mit dem Input Capture ausmessen. Oder man sucht sich ein paar kleine uCs, die Input Capture und I2C haben, lässt diese das Signal auswerten und holt sich die Daten alle 2 Sekunden übers I2C.
Multiplexer für die 32 Lüfter (5x74HC4052) und dann mit Timer Input Capture oder Interrupt auswerten. Wenn es nicht um Überwachung dreht/dreht nicht geht geht es evtl. auch einfacher. viel Erfolg Hauspapa
Das mit dem Input Capture ist ein gutes Stichwort, das kannte ich bisher noch nicht. Da alle Daten auf einmal in sehr kurzer Zeit gesammelt werden sollen, sind mehrere kleine µCs zur Daten(vor)aufbereitung vermutlich die beste Wahl... Mit 4 Tinys und jeweils nem 1:8 Multiplexer könnte das vielleicht schon recht platzsparend gehen. Morgen mach ich mir da mal etwas mehr Gedanken drum. Danke für die Antworten! ;)
wenn du ein tpi-gerät hast und SOIC löten kannst (ist nicht viel schwerer als DIP), dann is der tiny40 sehr interessant - Er hat ein Hw-I²C (zwar nur Slave, reicht aber) - Er hat rel. viele Pins (20-Pin SOIC) - Er hat einen ADC (hier nützlich für I²C-Adressen) Also Reichen zwei Tiny40 ohne irgendein Gemultiplexe aus um 32 Lüfter zu überwachen (und die Frequenzen der Lüfter sind jetzt nicht so krass, dass man die nicht einfach abtasten kann).
Marlon S. schrieb: > Da alle Daten auf einmal in sehr kurzer Zeit gesammelt Marlon S. schrieb: > ich möchte alle 2 Sekunden die Drehzahlen von bis zu 32 Lüftern 2 Sekunden ist für einen µC eine sehr lange Zeit... Die Messung der Periodenzeit mit dem Input Capture ist laut sprut [1] bis 6.3kHz genauer als die Frequenzzählung. Im worst Case braucht die Messung einer Periode 1/600Hz=1.67ms. Wenn wir als Zeit zum Umschalten des Multiplexeres usw. 5ms (mehr als nötig) nehmen, sind es für alle 32 Signale nur 213ms. Es ist also kein Problem in 2 Sekunden die 32 Signale hintereinander zu Messen... [1] http://www.sprut.de/electronic/pic/projekte/frequenz/freq_uni_628.htm#messprinzip
Max H. schrieb: > 1/600Hz=1.67ms 600 RPM (Rounds per MINUTE) sind dummerweise nur 10 Hz, also braucht eine Messung 100 ms (ist immernoch nicht viel)....
Sry, mein Fehler, ich habe irgendwie die PRM mit Hz verwechselt :-(
Max H. schrieb: > Im worst Case braucht die Messung einer Periode 1/600Hz=1.67ms. 600Hz wären aber 36000 RPM :D //EDIT: Okay, hast es selbst gemerkt Bei 600 RPM hingegen wären wir bei 100ms je Periode schon bei 3,2 Sekunden. Ich kann mir das im Kopf aber auch grad nicht so richtig vorstellen, wie ich die verscheidenen Signale direkt über nen Multiplexer aufnehmen soll, während der restliche Code läuft. Ich kann den Multiplexer ja auch erst dann "weiterschalten", wenn ich ein Signal bekommen habe, ansonsten könnte ich es verpassen. Wenn dann der nächste Lüfter dran ist, muss ich schlimmstenfalls ja wieder 100ms warten... Könnte vielleicht trotzdem jemand den Ablauf der Messung/Protokollierung einmal genau(er) erklären? Ich weiß nämlich nicht genau, ob ich es verstanden hab. Mit 2 Tinys würde das mit schlimmstenfalls 1,6 Sekunden je µC ja passen. Finepitch kann ich löten, seitdem ich dieses wunderbare Flussmittel habe :D Heute Abend kann ich leider nicht mehr antworten, weil ich jetzt weg muss, aber morgen früh bin ich wieder da ;)
:
Bearbeitet durch User
Bei so ewig langen Zeiten lohnt es sich doch gar nicht ein ICP zu benutzen. Einfach die Taktsignale an 32 I/Os und dann entweder PCINT oder einzeln abfragen.
Kommt halt drauf an wie genau du die Daten brauchst. Reicht dir alle 2 Sekunden eine Stichprobe, dann geht das mit Multiplexer und einem µC Eingang Brauchst du die Daten kontinuierlich dann ist dein erster Ansatz gar nicht mal so schlecht. Ich würde allerdings hinter die 8Bitcounter ein Schieberegister schalten. Alle Schiebregister dann in eine Kette. und dann alle 2 Sekunden den kompletten Block über SPI durchtakten. Gruß, Ralph
Hi, ich denke dass das mit eine uC und vielleicht einem Port Multiplexer geht. Was nirgends steht ist, wieviele Flanken Du per RPM bekommst. Folgender Anstatz: 3600 RPM = 60 Hz = 16,6ms, Genauigkeit so 1% heisst 160us Aufloesung. Das sollte mit einem CTC im hintergrund und einer ISR die immer einen ganzen Port einliest und ggf. 4fach multiplext (anzahl pins) gehen. Im Hintergrund bei steigender Flanke den Zaheler fuer das jeweilige Bit auswerten und dann auf 0 resetten. Zaehler *Isr Frequenz = RPM Frequenz. Das einzig hakelige koennten die ganzen zaehler sein, die Du ggf. volatile bearbeiten musst, es muesste aber auch gehen den port wert zur Auswertung an die main zu geben, und dort die zaehler zu behandeln. Haengt von deiner prozessorgeschwindigkeit ab, ist aber ja nur eine schleife die von 0..7 das Bit auf 1 abfragt und dann ein zaehler[i] inkrementiert. Mit einer array of int struktur machar. Wie haeufig Du das dann irgendwo hinschiebst ist eine andere Sache, da sind die 2s dann langsam. //hufnala
Es gibt z.B von Maxim ICs, die das machen und per I2C ausgelesen werden können.
Angehängte Dateien:
Hier hab ich was. Drehzahlmessung mit einem Tiny85, der Wert kann dann bequem per i2C ausgelesen werden. Somit kannst du bis zu 128 verschiedene Drehzahlen messen. Du musst nur jedem Sensor eine andere Adresse vergeben.
Das relativ langsame Zählen kann ein µC gut übernehmen ein µC könnte etwa 8 oder 16 Kanäle in Software Zählen (einfach Pollen) Das gibt auch gleich Entprellen in Software. Dann braucht es halt 2 oder 4 kleine µCs die dann per I2C verbunden sind. Ein größerer Chip mit 34 IOs könnte ggf. auch alle 32 Kanäle erledigen - vermutlich ist es aber mit 2 kleinen einfacher. Es gingen auch externe Zähler ICs - etwa ein 74HC590 , das ist ein 8 Bit Zähler mit Output Enable für die parallelen Ausgänge. Man kann also die Ausgänge direkt zusammenschalten und muss nur noch jeweils genau einen der Chips auslesen. Das braucht aber halt 1 IC je Lüfter und dann noch mal etwa eines für je 6-8 Kanäle dazu. Also schon so etwa in Richtung 38-40 ICs.
Ralph schrieb: > Reicht dir alle 2 Sekunden eine Stichprobe, dann geht das mit > Multiplexer und einem µC Eingang > > Brauchst du die Daten kontinuierlich dann ist dein erster Ansatz gar > nicht mal so schlecht. > Ich würde allerdings hinter die 8Bitcounter ein Schieberegister > schalten. > Alle Schiebregister dann in eine Kette. und dann alle 2 Sekunden den > kompletten Block über SPI durchtakten. Ich weiß nicht genau, was du mit Stichprobe meinst... Ich möchte alle 2 Sekunden von allen Lüftern die Daten haben. Über den Zeitraum von 2 Sekunden erfolgt die Messung und Speicherung der Werte, die dann am Ende des Zeitraums gemeinsam ausgelesen werden sollen. Das mit den Schieberegistern ist eine gute Idee, aber insgesamt scheint mir der Aufbau für rund 30 Lüfter dann sehr groß zu werden... hufnala schrieb: > Hi, ich denke dass das mit eine uC und vielleicht einem Port Multiplexer > geht. Was nirgends steht ist, wieviele Flanken Du per RPM bekommst. Wenn ich bei nem 2ten µC den Port multiplexe, sollte mir das schon einiges an Platz sparen. Die Flanken pro RPM weiß ich noch nicht genau, aber alles über 1 ist ja zu meinem Vorteil. Michael L. schrieb: > Hier hab ich was. Drehzahlmessung mit einem Tiny85, der Wert kann dann > bequem per i2C ausgelesen werden. > > Somit kannst du bis zu 128 verschiedene Drehzahlen messen. Du musst nur > jedem Sensor eine andere Adresse vergeben. Den Fototransistor könnte ich dann ja durch nen normalen ersetzen und mit dem RPM-Sognal ansteuern. Für 128 Drehzahlen bräuchte ich dann aber auch 128 Tinys, oder? Viel Möglichkeiten zum Multiplexen gibts da ja nicht mehr. Harry schrieb: > Es gibt z.B von Maxim ICs, die das machen und per I2C ausgelesen werden > können. Hab mir mal grad den MAX31785 angeschaut und mich gleich ein bisschen verliebt :D Der macht ja direkt ALLES für mich! Ich hatte hier bisher nicht erwähnt, dass ich die RPM auch steuern will, weil ich mir dafür schon was überlegt hatte, aber mit dem Chip kann ich mir ja ne Menge Arbeit sparen. Klar, "selbstgemacht" ist schöner, aber die RPM-Messung und -Steuerung ist nur ein kleiner Teilaspekt einer größeren Sache und sollte deshalb möglichst unkompliziert und kompakt sein. Wichtig ist, dass ich die RPM über I²C auch auslesen kann, weil die Daten einerseits vom Arduino verarbeitet und andererseits aber noch in einer Datenbank protokolliert werden sollen. Die Funktion hab ich beim Überfliegen zwar nicht gefunden, sollte bei dem riesigen Funktionsumfang aber gegeben sein... Ein Frage habe ich dazu aber noch: Die Lüfter, die ich verwenden will, sind 3-polig. Sie haben also kein PWM Input und müssen über die Spannung gesteuert werden. Könnte ich die PWM-Outputs des Maxim-Chips einfach an nen Transistor in der Spannungsversorgung des Lüfters hängen?
Marlon S. schrieb: >> Brauchst du die Daten kontinuierlich dann ist dein erster Ansatz gar >> nicht mal so schlecht. >> Ich würde allerdings hinter die 8Bitcounter ein Schieberegister >> schalten. >> Alle Schiebregister dann in eine Kette. und dann alle 2 Sekunden den >> kompletten Block über SPI durchtakten. > > Ich weiß nicht genau, was du mit Stichprobe meinst... Ich möchte alle 2 > Sekunden von allen Lüftern die Daten haben. Über den Zeitraum von 2 > Sekunden erfolgt die Messung und Speicherung der Werte, die dann am Ende > des Zeitraums gemeinsam ausgelesen werden sollen. Das mit den > Schieberegistern ist eine gute Idee, aber insgesamt scheint mir der > Aufbau für rund 30 Lüfter dann sehr groß zu werden. Mit multiplexen siehst du immer nur in einem bestimmtest Zeitfenster auf einen der Lüfter. Du berechnest also aus dem was du in dem kurzen Zeitfenster messen kannst die Drehzahl für die komplette Zeit. Also eine "Stichprobe" der möglichen Pulse in einem definierten kleine Zeitfenster wird hochgerechnete zur Drehzahl in der vollen Zeit. Dein erster Ansatz bietet eine permanente Messung mit zeitlich gestaffelter Auswertung. Hier bekommst du also alle Pulse in der gesamten Zeit und daraus eine real berechnete Drehzahl im Gegensatz zur abgeschätzten Hochrechnung auf Basis kurzer Meßschnipsel.
Wenn die Messung der Periodendauer bis 6,3 kHz beste Genauigkeit verspricht, dann sorge dafür, dass die Sensoren an den Motoren in etwa diese Frequenz abgeben. Dazu brauchst du eine Sensorik, die 10 oder 12 Impulse pro Umdrehung abgibt. Dann einfach einen Sensor ansteuern, eine volle Periode (also 1/10 oder 1/12 Umdrehung) messen, Wert abspeichern, der nächste bitte.
ernst oellers schrieb: > Wenn die Messung der Periodendauer bis 6,3 kHz beste Genauigkeit > verspricht, dann sorge dafür, dass die Sensoren an den Motoren in etwa > diese Frequenz abgeben. Dazu brauchst du eine Sensorik, die 10 oder 12 > Impulse pro Umdrehung abgibt. Dann einfach einen Sensor ansteuern, eine > volle Periode (also 1/10 oder 1/12 Umdrehung) messen, Wert abspeichern, > der nächste bitte. Da noch was einzubauen wird sehr schwierig, denke ich, da es sich um 120/140 mm PC-Lüfter handelt... Ich bin jetzt beim MAX31790 hängen geblieben, weil der genau das macht, was ich brauche (RPM messen und regeln), mit 4x4mm ÄUSSERST kompakt ist und sich bequem über das I²C-Protokoll ansprechen lässt. Ein eigener Ansatz ist zwar eigentlich schöner, in diesem Falle muss es aber möglichst zweckmäßig sein. Ich danke euch trotzdem sehr für eure zahlreichen Antworten! Ist mir irgendwie etwas peinlich, dass ich einfach nur zu blöd zum Googeln war...
hufnala schrieb: > Hi, ich denke dass das mit eine uC und vielleicht einem Port > Multiplexer > geht. Was nirgends steht ist, wieviele Flanken Du per RPM bekommst. > > Folgender Anstatz: 3600 RPM = 60 Hz = 16,6ms, Genauigkeit so 1% heisst > 160us Aufloesung. Das sollte mit einem CTC im hintergrund und einer ISR > die immer einen ganzen Port einliest und ggf. 4fach multiplext (anzahl > pins) gehen. Im Hintergrund bei steigender Flanke den Zaheler fuer das > jeweilige Bit auswerten und dann auf 0 resetten. Zaehler *Isr Frequenz = > RPM Frequenz. So würde ich es auch versuchen, vermutlich langweilt sich der Prozessor dabei noch. Alternativ könnte man sich bei den Flanken auch Interrupts generieren lassen und sozusagen Software-ICP machen, indem man einen freilaufenden Timer im Flanken-Interrupt ausliest. > Das einzig hakelige koennten die ganzen zaehler sein, die > Du ggf. volatile bearbeiten musst, es muesste aber auch gehen den port > wert zur Auswertung an die main zu geben, und dort die zaehler zu > behandeln. Da sehe ich kein Problem. > Haengt von deiner prozessorgeschwindigkeit ab, ist aber ja > nur eine schleife die von 0..7 das Bit auf 1 abfragt und dann ein > zaehler[i] inkrementiert. Mit einer array of int struktur machar. Wie > haeufig Du das dann irgendwo hinschiebst ist eine andere Sache, da sind > die 2s dann langsam. Warum fällt mir da zwangsläufig Peter Danneggers vertikales-Counter Prinzip aus seiner Entprellroutine ein? ;-)
Marlon S. schrieb: > Da noch was einzubauen wird sehr schwierig, denke ich, da es sich um > 120/140 mm PC-Lüfter handelt... in diesem Zusammenhang mal ganz platt die Frage: wie funktioniert deine Drehzalerfassung überhaupt (messtechnisch gesehen)? Hast du eine Schätzung, wieviel % der Drehzahlmesszeit fürs warten auf die Triggerflanke draufgehen wird?
Marlon S. schrieb: > Den Fototransistor könnte ich dann ja durch nen normalen ersetzen und > mit dem RPM-Sognal ansteuern. Ja genau, wenn du bereits ein fertiges Clock-Signal vom Lüfter hast, kannst du dieses direkt zum tiny führen. Und brauchst keine auswertelektronik vom Fototransistor. > Für 128 Drehzahlen bräuchte ich dann aber auch 128 Tinys, oder? Ja. Ich kann dir auch den Code geben, und du kannst das ganze so anpassen, dass du mit einem Prozessor mehrere Drehzahlen messen kannst. Ich habe die Drehzahlmessung mit einem Hardwaretimer und einem Interrupt am PB4 gelöst, funktioniert bis jetzt einwandfrei.
Marlon S. schrieb: > Über den Zeitraum von 2 > Sekunden erfolgt die Messung und Speicherung der Werte, die dann am Ende > des Zeitraums gemeinsam ausgelesen werden sollen. Ok, und was machst Du mit den x Werten innerhalb der 2s? mitteln? Nur den weitergeben der dann aktuell kommt? Bei 16ms sind das rund 150 Werte die in der Zwischenzeit angefallen sind. >Mit multiplexen siehst du immer nur in einem bestimmtest Zeitfenster auf >einen der Lüfter. Stimmt, aber wenn alle 16ms eine relevante Flanke aufschlägt, und alle 160us alle 4 Kanäle durch sind, ist das Zeitfenster lediglich die Genauigkeit. Bezogen auf die 2s ist das absolut vernachlässigbar. Vermtl. kann der Arduino das im Hintergrund noch mit machen (freie Ports vorausgesetzt), hängt natürlich von der freien Performance ab. Ich würde einem Tiny2313 alle 500ms die Daten von 8 Motoren (*4 = 32 Motore in 2s) per UART rauszuschieben. Dazu noch 'nen bisschen Vogelfutter für das Multiplexen und gut ist. >Wenn ich bei nem 2ten µC den Port multiplexe, sollte mir das schon >einiges an Platz sparen. Die Flanken pro RPM weiß ich noch nicht genau, >aber alles über 1 ist ja zu meinem Vorteil. Nee, isses nicht, irgendwann kommt dein uC nicht mehr hinterher, 10 Flanken = 1,6ms Auswertezeit, gemultiplext 400us, da wird es dann eng mit der Genauigkeit. >Ich bin jetzt beim MAX31790 hängen geblieben, weil der genau das macht, >was ich brauche (RPM messen und regeln) OK, von regeln war auf den ersten Seiten nicht die Rede, da müsste man wirklich mal sehen was geht. Wie willst Du Regeln? PWM? Dann wird es nicht ganz so einfach werden. //hufnala //hufnala
hufnala schrieb: >>Mit multiplexen siehst du immer nur in einem bestimmtest Zeitfenster auf >>einen der Lüfter. > Stimmt, aber wenn alle 16ms eine relevante Flanke aufschlägt, und alle > 160us > alle 4 Kanäle durch sind, ist das Zeitfenster lediglich die Genauigkeit. > Bezogen auf die 2s ist das absolut vernachlässigbar. Wie lang ist denn ein Puls ? Ist der Puls kürzer als diese 160µs kann es leicht passieren das der Puls eben NICHT erkannt wird. Das geht dann nur Eventbasiert ==> IRQ pro Kanal und kein Polling. Wieviele Pulse pro Umdrehung liefert der verwendete Lüfter ? Die Frage ist ganz einfach. Soll es eine Messung oder eine Abschätzung sein ? Messung ==> Erfassung aller Pulse eines Lüfters ( Hardwarecounter) ==> errechnen der Drehzahl Abschätzung ==> Pollen mit multiplexen ==> erfassen von einigen Pulsen in definierten Zeitfenstern ==> Hochrechung aus Teilweise vorhandene Daten ; und dabei ist nicht bekannt wie vollständig die Daten ( Pulse) erfasst worden sind. ( Pulsbreite, zeitliche Verschiebung der Pulse au den multiülexten Kanälen, synchronisieren der Umschlatungen mit dem Multiplexer .... )
Ralph schrieb: > Wie lang ist denn ein Puls ? Ist der Puls kürzer als diese 160µs kann es > leicht passieren das der Puls eben NICHT erkannt wird. > Das geht dann nur Eventbasiert ==> IRQ pro Kanal und kein Polling. Nein, dann ist die Grenze der Erkunng da wie schnell er interne Timer mit Multiplex zur Pulslänge steht. Bei <1% Auflösung geht das auch weiter mit Pollen. > Wieviele Pulse pro Umdrehung liefert der verwendete Lüfter ? Die Antwort hätte ich auch gerne :-) > Die Frage ist ganz einfach. > Soll es eine Messung oder eine Abschätzung sein ? Nein, meine MEthode beschreibt eine Messung für das Signal mit einer Genauigkeit von ca. 1%. DAs ist keine Abschätzung mehr. Selbst eine Regelung (rudimentär) ist vermtl. auf dieser Basis möglich. Dazu müssten aber - wie so häufig - die Anforderungen und gegebenheiten klar sein. > Messung ==> Erfassung aller Pulse eines Lüfters ( Hardwarecounter) ==> > errechnen der Drehzahl > Abschätzung ==> Pollen mit multiplexen ==> erfassen von einigen Pulsen > in definierten Zeitfenstern ==> Hochrechung aus Teilweise vorhandene > Daten ; und dabei ist nicht bekannt wie vollständig die Daten ( Pulse) > erfasst worden sind. ( Pulsbreite, zeitliche Verschiebung der Pulse au > den multiülexten Kanälen, synchronisieren der Umschlatungen mit dem > Multiplexer .... ) Die Definition ist so falsch: Eine Messung kann auch ein pollen (übrigens wie von mir beschrieben mit einer natürlich "zeitlich passenden" Frequenz sein. Diese muss - dem Anwendungfall entsprechend deutlich kleiner dem kleinsten Puls sein. Sobald Du Dich in die Analogmesstechnik begibst, gibt es quasi kein anderes verfahren mehr für Messungen. Das geht nur mit einer Zeit als definierte Basis für die Abtastung. //hufnala
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.