Es wird anstrengend genug sein, das er mit seinen unterschiedlichen Persönlichkeiten nicht durcheinander kommt. Unter diesem Stressfaktor kann die Wortwahl schon mal etwas vernachlässigt werden. Bitte hab Rücksicht
go woke go broke
Es wird anstrengend genug sein, das er mit seinen unterschiedlichen Persönlichkeiten nicht durcheinander kommt. Unter diesem Stressfaktor kann die Wortwahl schon mal etwas vernachlässigt werden. Bitte hab Rücksicht
go woke go broke
Guten Morgen,
Ein Pi/Zero ist dafür eigentlich schon zu groß. Ein Mikrocontroller (Pi Pico, ESP32 oder Arduino) reicht dafür allemale.
Und noch ein Nachbetrachtung die du hoffentlich plausibel erklären kannst.
Du schlägst eine µController zur ADC Meßwertaufnahem vor, um ein Meßreihe entstehen zu lassen.
Gut kann man machen. Stelle ich auch nicht in Frage.
Nur meine Frage dazu wäre, von welcher Meßrate des ADCs gehst du aus, und wie lange soll der Event der Krafteinwirkung aufgezeichnet werden ?
Wenn ich mich richtig erinnere sind diese µController alle nicht mit sehr viel RAM ausgestattet um eine Meßreihe mit einer entsprechend hohen Meßrate bei einer entsprechenden ADC Auflösung in Form eines Arrays speichern zu können !
Bis 8 Bit immerhin ein Integerwert von der Größe 1 Byte, bis 16 bit von 2 Byte und bei über 16 Bit bs 24 bit immerhin schon 3 Byte.
Bei einem Arduino mit einem ATMEGA 328 sind das immerhin nur 2 Kbyte die als Variablen Speicher zur Verfügung stehen ! Damit ergibt sich ein ungünstiges Verhältnis, welches aus Genauigkeit und Anzahl der Einzelmessungen besteht. Entweder man nimmt viele Meßwerte mit einer geringen Genauigkeit auf, um ein gewisses Zeitfenster zu überbrücken, oder man wünscht sich eine besonders hohe Genauigkeit, was dann aber zur Folge hat das das Zeitfenster radikal schrumpft.
Wenn man sich nun an eine Studie zur Schalgkraft für Boxer orientiert, die es auch im Internet im Bereich Sportmedizin frei zugänglich einzusehen gibt, komme ich hier zu eine Schluß, dass man für mind. 500 ms die Kraftverlaufskurve aufzeichnen müsste.
Daraus ergibt sich das der ADC selber mit mind. 5'000 Messungen pro Sekunde exakte Werte liefern können muss. Mit 8 oder 10 Bit brauchst du hier nicht anfangen !
Du kannst ja hieraus mal versuchen eine Programmlogik zu entwickeln, wie man das mit den sehr beschränkten Kapazitäten eines Arduinos umsetzen könnte. Es geht nicht wirklich und scheitert an der Tatsache, das dir der RAM für die Zwischenspeicherung der ADC Rohmesswerte ausgehen wird, ohne das du diese schon während der Aufzeichnungsphase in einen physikalische Float-Pont Krafteinheit umrechnen kannst.
Das aber nur mal nebenbei, wenn man sich die Zeit nimmt in eine solche Aufgabenstellung hineinzudenken, und einige Hintergrundrecherchen anstellt.
Ich hoffe du kannst dem TO eine gute Lösung aus einem µController, aus einem schnellen ADC, mit einer Genauigkeit größer 12 Bit anbieten, die er dann so auch direkt eins zu eins umsetzen kann.
Es grüßt
Roland
Guten Abend,
Was soll diese sehr schwammig formulierte Aussage bedeuten ?
Dehnmessstreifen, als rein analog arbeitende Systeme, kann man pro Zeiteinheit so oft auswerten, wie der angeschlossene ADC Meßwerte wandeln kann.
Damit fallen fast alle Delta-Sigma ADCs schon einmal automatisch aus der Reihe der bevorzugten ADCs. Hier sollte man alternativ auf SAR oder Pipelined ADCs setzen, inwiefern man mit den Rahmenbedingungen klarkommt.
Hinzu kommt allerdings auch noch die Auflösung der ADCs selber, welche sich an der Aufgabe und gewünschten Genauigkeit orientieren.
Zur vereinfachten Erklärung:
- Delta-Sigma ADCs sind sehr genau, ereichen Auflösung größer 20 Bit , sind aber verhältnismäßig langsam. Hier sprechen wir nur von einigen Zehn unter 100 Meßzyklen pro Sekunde. Damit den Höchstwert zu erwischen ist damit eher unwahrscheinlich, bzw. fast unmöglich.
- SAR ADCs erreichen wiederum Betriebsspannungsabhängig bis zu 300.000 Einzelmessungen pro Sekunde, allerdings bei einer maximalen Auflösung von 13 bit. Daher sind sehr schnelle Anbindungen via des SPI Bus fast anabdingbar, welches auch zur Folge hat, die Enfernung zwischen dem ADC-Chip selber und dem ausertendem Controller stark eingeschränkt ist ( unter 20 cm ).
- Pipelineed ADCs haben ein Meßrate von bis zu 200.000.000 ( 200 Millionen ) Messuungen pro Sekunde, allerdings mit einer Auflösung in BIT welche sich zwischen den Delta-Sigmal ADCs und den SAR-ADCs bewegen. Für die maximale Samplingrate ( Meßrate ) können diese speziellen ADCs ihre Meßwerte auch dirket in einen RAM Baustein schreiben, so das der auswertende Controller über eine entsprechende DMA Schnittstelle ( extern ) verfügen muss. Was mit den bisher genannten bzw. vom TO projektierten Controller nicht möglich ist. Hier kann man auch wie bei den meisten SAR ADCs via SPI Meßdaen über den SPI Bus abgreifen, allerdings dann nicht mit voller Meßrate.
Aufbau und Sensoren:
Hier kann man verschiedene Wege gehen, die auch ein gewisses Verständins voraussetzen, weil das Ganze geht dann nicht mehr ohne Zusatzbeschaltung.
Dehnstreifen mit Delta-Sigma ADCs auslesen das geht fast direkt und es gibt auch spezialisierte ADCs für diesen Anwendungsfall. Allerdings erreicht man hiermit nur 16 bis 24 Messungen pro Sekunde, was für deinen Anwendungsfall der komplett falsche Ansatz wäre. SAR ADCs die auf hohe Meßraten ausgelegt sind benötigen zudem eine exteren Referenzspannung mit welchm der ADC die geänderten Widerstandswerte -> Spannungsänderung vergleicht um möglichst genaue Meßergebnisse liefern zu können. Damit hat man wie bei der MCP3x0x Serie welche auch in gpiozero vom RasPI unterstützt werden das Problem, welche darin besteht, diese mit zwei getrennten Spannungen ( Versorgunsgspannung und Referenzspannung ) betreiben zu müssen. Dieses zwingt einem wiederum Pegelwandler ( Levelshifter ) zu verwenden, das die theoretische Meßrate von der Betriebs- bzw Versorgungsspannung, weniger von dem Bus Clock-Takt abhängig ist !
Mit den üblichen 8 oder 10 BIT ADCs wie sie zB in den Arduino Prozesorren ( AVR ATMega 328 ) sind zwar mit bis zu 150.000 Messungen pro Sekunde nicht langsam, aber auch hier die wenigen BIT und einer eher ungenaue, vor allem temperaturabhängige Referenzspannung macht diese nicht zu den bevorzugten Mitteln.
Aber auch noch ein Wort zu den andeen Mikrocontrollern die hier genannt wurden, sowohl der ESP32 wie auch der RasPi PICO sind zwar mit 12 Bit ADC Chanels besser aufgestellt, aber ohne Zusatzbeschaltung kann man die jeweils interne Refernezspannung auf diesen Boards vergessen. Die zyklischen Schwankungen in der Referenzspannung auf beiden Boards reichen aus um ein Poti halbwegs genau auszulesen, aber im differenziellen Meßverfahren hebt diese fast den Gewinn einer höheren Auflösung wieder auf. Ja man kann mit einer externen Beschaltung zB dem Pico eine genauere, präzisire und gleichförmigere Referenzspannung zuführen, allerdings sollte man sich über den Aufwand im klaren werden, und einige Regeln in der Programmierung zwingend berücksichtigen. Ansonsten erreicht man hiermit auch nur Netto 7 bis 9 Bit verwertbare Meßauflösung.
Pipelineed ADCs dürften sowohl vom Preis, wie auch von der Zusatzbeschaltung / Voraussetzungen an den auswertenden Controller und der Programmierung außerhalb dessen liegen, was du ausgeben willst ( 250 € + ). Hier hilft einem auch nicht mehr ChatGPT weiter, hier muss man sich durch die Datenblätter fräsen, und die gesamte Dokumentation entsprechend in der Programmierung auch umsetzen können. Deswegen gehe ich mal nicht weiter darauf ein.
Zudem kann man einen solchen Dehnmeßstreifen auf mehrere Arten auslesen / auswerten. Vereinfacht reicht hier eine an die Referenzspannung gekoppelte Konstantstromquelle, so dass man diese Dehnmeßstreifen vereinfacht auch mit einem Pseudodifferenziellen ADC mit relativ wenig Zusatzaufwand auslesen kann. Oder man scheut aufwendige Berechnungen nicht, baut eine Wheatstonesche Messbrücke auf, an welcher man eine Kette OPVs aus Differenzverstärker und einem Addierer auf, um den Meßbereich optimal außerhalb des Zero OFF-Set Errors eines ADCs zu betreiben. [ Meßwerte die sich im unteren Achtel nahe des Zero Off-Set-Punkts bewegen sind immer mit vorsicht zu genießen. Deswegen kann man auf dieser Meßspannung via OPV eine Hilfsspannung aufaddieren, um diesen unteren Meßbereich aus der Auswertung herauszunehmen ]
Je nach dem was du genau vor hast, welche Dehnmessstreifen du ausgewählt hast ( Kraftmessdose ) ob 2oder 4 Leitertechnik zur Werterfassung an den Dehnmeßstreifen könntest du dir mal den MCP3561 ADC ansehen, welcher in Abhängigkeit der Meßgenauigkeit eine umgekehrt langsamere Meßrate liefert. Hier hättest du ein breites Spekturum aus Schnelligkeit und hoher Meßauflösung, welches sich einfach auch im laufenden Betreieb via SPI Befehle verändern / anpassen lässt. Zudem verfügt dieser auch differenziell geeignete ADC über einen IRQ Ausgang, welcher eine Signalimpuls an den Controller sendet, wenn eine bedeutende Wertänderung stattgefunden hat. Dieses hätte den Vorteil, der Controller auch PICO oder ESP32 könnten sich im Sleep Modus befinden, und mit der ersten festgestellten Krafteinwirkung / -veränderung geweckt werden und mit der Wertabfrage via des SPI Busses beginnen und eine Daten- / Meßreihe aufnehmen. Damit muss man nicht ständig in einem loop() auf de Bus herumackern, in der Hoffnung, das es mal zu einer Krafteinwirkung kommt.
Dehnmeßstreifen sind sehr robust, wenn diese ausreichend dimensioniert sind, benötigen aber je nach Umfeldbedingungen auch noch einen Temperatursensor um einen referenzierenden Abgleich vornehmen zu können.
Bei hohen oder höchsten Meßraten größer 100.000 Messungen / Sekunde sollte man dann aber lieber zu einen Mikrocontroller wie den PICO oder ESP32 ins Auge fassen, hier hat der RasPI selber seine Schwierigkeiten auf oder mit dem SPI kontinuierlich maximale Datenraten zu fahren. Der RasPi ist kein Echtzeitsystem im Gegensatz zu den schon genannten Mikrocontrollern.
Damit wäre es deine primäre Aufgabe, erst einmal das Projekt klar zu definieren, und zu schauen welche Wertbereich einer Kraft zu erwarten sind. Danach richtet sich dann alles aus, sowohl die Methode der Auswertung, die Aswahl des ADCs , die benötigten Arbeitsspannungen und welche Auswerteelekronik ( analog ) für dich am einfachsten umzusetzen wäre.
Es grüßt
Roland
Guten Morgen,
Gnom , deine Aussage:
Du kannst den I2C-Bus direkt an den Pi anschließen (3,3 V). Jeden MCP kannst du direkt oder über jeweils einen eigenen Levelshifter mit dem Bus verbinden.
ist vollkommen widersinnig. Wenn du dazu beachten würdest, dass die meisten Levelshifer schon über einen Pullup Widerstand verfügen, würdest du gemäß Berechnung Parallelschaltung von Widerständen bei mehreren Levelshifters mit Pullup den Gesamtwiderstand dieser auf ein derart geringen Widerstandwerts herhöhen, mit welchen sich die Datenausgänge der I2C-Endgeräte problemlos zerstören lassen.
1/ RGesamt = 1 / R1 + 1 / R2 + ... +1 / Rn
Damit fällt diese Methode einfach aus, oder weg, wenn man zB solche Levelshifter Module verwendet -> Siehe Bild
Damit pro Spannungswert auf der Slaveseite einen einzigen Levelshifter, mehr nicht. Dann ganz normal in Sternschaltung am der High-Site des LS auf die Slaves weiterverteilen.
aproxxo
10 mal einen MCP23017 mit einem I2C Bus als Host geht nur wenn du einen Multiplexer verwendest. Da die Adressierbarkeit der MCP23017 auf 8 eigenständige Adressen beschränkt ist , müsstest du entweder:
- einen Bus-Multiplexer verwenden, damit du mindestens 2 dieser MCP23017 mit einer schon einmal verwendeten Busadresse betreiben kannst
- einen zweiten I2C Bus auf dem RasPi initiieren
- oder wie fred0815 schon vorgeschlagen hat auf die SPI Version MCP23S17 ausweichen. Hier kannst du den Datenverkehr MOSI, MISO, SCLK weiterhin komplett parallel schalten, die Adresscodierung A0-A2 nutzen um an einem CS-Port 8 dieser MCP23S17 und mit einem weiteren CS-Port die restlichen MCP23S17 auch wieder mit einer Adresscodierung anzusprechen.
Hier würde dann für den Grundbetrieb ein 3-Kanal Levelshifter ausreichen, welcher für MOSI, MISO und SCLK verwendet wird. Bei den CS0 , CS1 Leitungen ist dieses nicht notwenig, da dieser zum aktivieren der MCP23S17 nur von mind. 2,8 V ( High Zustand ) auf Low gezogen werden muss, und hier eine Spannung kleiner 0,8 V ( 0,0 bis 0,79 V ) ausreicht damit der Slave ( MCP23S17 ) auf die Datensignale reagiert.
Damit noch einmal zusammengefasst, unabhängig mit welcher Pegelspannung die MCP23017 / MCP23S17 arbeiten:
- Entweder bei I2C einen Bus-Multiplexer TCA9548A [Anzeige] verwenden und du könntest auf 8 x 8 dieser MCP23017 erweitern. Benötigst am RasPi aber nur 2 GPIOs für den I2C Bus.
- du macht einen zweiten I2C Bus auf, und benötigst zusätzlich 2 weitere freie GPIOs !
- du setzt auf SPI benötigst, dann aber mind. 5 GPIOs inkl. CS0 und CS1 . Hast aber einen Geschwindigkeitsvorteil gegenüber der Multiplex-Version. Denn diese Multiplexer haben nicht nur eine eigene Latenz, sondern können auch nicht mit dem maximal möglichen Clocktakt des I2C Busses für den MCP23017 betrieben werden.
Ergänzender Hinweis: Wenn du beabsichtigst diese MCP23x17 auch als Input zu nutzen, und die INT Funktion für eine Pegeländerung an einem der MCP23x17 GPIO Pins zu nutzen, müssen auch die INT_A und INT_B Leitungen zum RasPI über einen Levelshifter laufen.
es grüßt
Roland
Guten Morgen, und schönen Feiertag,
Grundsätzlich muss man das Thema Stromversorgung dort beginnen, wo die ganze Sache heiß wird.
Egal wie viele dieser Relais gleichzeitig schalten werden, es gibt immer noch den Fall des könnte. Da die SW bestimmt wie viele dieser Relais gleichzeitig zum Anziehen gebracht werden können, musst du eine einfache Grundüberlegung anstellen.
Diese gleichzeitig schaltenden Relais benötigen immer einen Anzugstrom, und das muss du erst einmal ermitteln. Je nach Relaistyp können das für bis zun einige ms ( im schlimmsten Fall wenn diese schon ausllutscht sind 120 ms ) 150 mA+ pro Relais sein. Das muss deine Stromversorgung abkönnen, und das muss durch entsprechende ELKO Kapazitäten abgedeckt sein. Dann kommen noch die Relais hinzu, welche sich alle schon im angezogenen Zustand befinden, egal mit welcher Spannung diese Relais betrieben ( nicht nur angesteuert ) werden.
Bei dem Schieberegister bin ich mir nicht sicher ob das die Lösung der ersten Wahl ist, denn man muss um die Ausgänge als Binäre Ausgänge setzen zu können, das ganze Durchtackern. Also wenn ich die Funktion richtig verstanden habe entsprechend viele Fortschaltimpulse an diese Register /-array senden, damit die Ausgänge dann wieder den Zustand haben, wie es gewünsht ist.
Bei dieser Anzahl von möglichen Ausgängen eher schwierig, zumindest stelle ich mir das so vor, wenn man eines der unteren Bits löschen will, aber eines der oberen Bit hinzufügen will. Klar geht das Durchtackern des Taktsignale schnell, auch wenn man den Reset Input benutzt, aber dennoch man muss auch hierführ eine gewisse Zeit einberechnen. Und wie die Relais sich dann verhalten, wenn man für einige µs fast ms der Strom weg ist, sowie sich das auf den Fahrbetreib auswirkt - ich habe keine wirkliche Vorstellung dass das alles Störungs- und Unterbrechungsfrei funktionieren wird.
Was die Ausage Eingänge angeht, warum so viele Imput IRQ belegen ?
Hier kann man das ganze verkürzen wenn, man die INT Ausgabe der INPUT MCP23017 zb auf einem SPI MCP23S17 umlegt. Und von hier nur 2 Leitungen zu RasPi führt. Der Puffer im MCP23017 bleibt für 20 ms bestehen. Man hat also in der Summe seitens des RasPI 20 ms Zeit dieses Register auszlesen. Schaltet man nun noch einen MCP23S17 dazwischen, laufen die INTs bei MCP23S17 ein dieser gibt für 16 dieser MCP23017 Register = 16 * 8 = 128Eingänge dieses Signal an den RasPi weiter, dieser liest mit einer viel höheren Geschwindigkeit dem Port des MCP23S17 aus, und fragt anschließend anhand einer DICT ( in Python ) den entsprechendne MCP23017 ab, welcher eine Veränderung am einem seiner Eingänge bemerkt hat. Wenn man das richtig gescheit aufbaut, den MCP23S17 mit einem SCLK Takt von 1,2 MHz betreibt dauert deiser gesamte Vorgang keine 630 µs und man hat in der Auswerte SW die Information auch mit dem Umweg über den MCP23S17 an welchem der I2C MCP23017 Eingänge sich etwas getan hat.
Dazu muss man nicht zwangsläufig ständig auf dem I2C Bus herumackern, oder diesen mit solchen sinnfreien Loop Abfragen blockieren.
In der Summe mit den MCP23S17 weil diese viel viel schneller abgefragt werden können, kann man mit einem solchen Portexpander immer 128 Eingangskanäle über nur 2 INT IRQ GPIO Ports des RasPi abfragen. Wobei mir jetzt aber auch noch der Multiplexer in den Sinn kommt, der die I2C Kommunikation zusätzlich ausbremst.
Viellicht wäre der Gedanke nutzbringender wenn man auf diese Vielzahl der I/O über die SPI MCP23S17 laufen lässt, das kostet einem dann nur pro 8 Block ( Via Adresswahl ) einen CS Port ( SPI Bus ) und bringt die Input Expander über einen I2C MCP23017 zusammen.
Letztere, diese Variate habe ich schon einmal auf einem ESP umgesetzt, und das funktioniert absolut zuverlässig und schneller. Hierzu sollte man erwähnen, das die SPI Portexpander wegen des höheren BusTaktes 3 bis 4 mal schneller eine Ausführung eines OUTPUT Befehls umsetzen, wie die I2C Versionen.
Wenn man sich den Code beider Versionen anschaut, lässt sich das mit einer Bibliothek zusammenfasssen, so das nur die Schreib- udn Lesebefehle dann über eigene Funktionsblöcke je nach Bus-System ausgeführt werden. DIe interne Regsiterssetzung bzw das Auslesen dieser erfolgt bei beiden Versionen mit den gleichen Befehlen.
Ws ich allerdings nicht mit Bestimmheit sagen wie man bei einem RasPi die Busgeschwindigkeit für den SPI Bus einstellen kann, und was der PI hier in der Lage ist auch umzusetzen.
Es grüßt
Roland
Guten Abend,
Der Vorteil dieser Module sind zwar, dass man diese schön mit teuren kabeln aneinanderreihen kann, aber dann hören sämtliche Vorteile dieser Module bei einem Projekt dieses Umfangs auf.
Das Ganze ist nicht so einfach wie es ausschaut und das beginnt mit der Stromversorgung und endet mit den Schaltpegeln die an diese Relaiskarten herausgehen sollen.
Diese MCP23017 benötigen je nach dem und hier beginnen dann deine Probleme erst richt ! :
- Welche Schaltspannung, und welchen dazugehörigen Strom benötigt jeder Relaus Kanal für sich einzeln ?
Hinweis dazu: Jeder dieser MCP23017 kann nur 700 mW oder 0,7 W umsetzen. Daraus ergibt sich je nach Betriebs- und Ausgangsspannung am Portexpander GPIO unterschiedliche Stromwerte [ Bei Vcc 3,3 V = Summe 212 mA oder 140mA bei 5,0 V Betreibsspannung ]. Diese Teilen sich dann auf diese 16 Output Ports auf. Jedoch darf der einzelne GPIO am Portexpander auch Impulsweise nicht mehr wie mit 25 mA belastet werden.
Daraus ergibt sich je nach Betriebspannung mit welchen du diese MCP23017 in der Parallelschaltung betreiben willst ein etsprechnd hoher Strombedarf. Hast du dir schon Gedanken gemacht wie du bei 8 diese MCP23017 und einer Vcc 3,3 V diese ca 1,7 A oder 1,3 A bei 5 V nur für 8 dieser MCP23017 in einer Kette bereitstellen willst ? Wenn du dann das Ganze auch noch mittels dieses Bus-Multiplexers um den Faktor 8 Erweitern willst, kommt man dann auf fast 15 A ( 13,6 A ) bei 3,3 Volt oder ca. 10 A ( 9,6 A ) bei 5,0 Volt !?
Da ist der Eigenstrombedarf des Multiplexers noch nicht einberechnet.
Aber wenn dann auch noch alle Ausgänge an einem einzelnen dieser MCP23017 gleichzeitig ein Relais ansteuern sollen und angezogen halten soll, dann darf dein Relais am Steuereingang nicht mehr wie 13 mA @ 3,3 V oder 8 mA @ 5,0 V ziehen ! Sonst fliegt dir die ganze Schose um die Ohren.
Zudem ist zu beachten, die Vcc des Portepanders entspricht dem Signal auf dem I2C Bus, was bei einem 5,0 V Betrieb dieser noch einen Pegelwandler ( Levelshifter ) von 3,3 V / 5,0 V voraussetzt, sonst überlebt das Ganze dein Raspi nicht.
Kann man alles machen - keine Thema, aber es kommen dann auch noch Leitungslängenbeschränkungen hinzu, so das diese jeweils Kette aus 8 dieser Protexpander Module ( Link zu Reichelt ) nicht unbegrenzt lang werden dürfen. Eine weitere Bremse ist dieser Multiplexer welcher die BUS-Geschwindigkeit erhabsetzt um überhaupt noch funktionieren zu können.
Für dich wäre erst einmal wie schon geschrieben wichtig, welchen Anzugsstrom ein solches Relais benötigt, wenn diese Relaiskarte über keine OptoKopplereingänge verfügt, und welcher resultierende Haltstrom diese Relais benötigen, denn das muss du dann via eines weiteren Stromkreises gesondert bereitstellen. Es gibt unter diesen blauen Relais die auf den meist bei Amazon angebotenen Karten Modelle / Versionen die einen Anzugsstrom ( das einleiten des Umschaltvorgangs ) von bis zu 140 mA benötigen. Wenn dann auf der Relaiskarte kein Schaltverstärker verbaut ist, oder auch kein Optokoppler dann würdest du den MCP23017 sofort schrotten, denn der einzelne GPIO kann nur max. mit 25 mA bbelastet werden, wobei immer dieser 700 mW Gesamtleistung Pro MCP23017 als oberstes Limit zu beachten ist !!!
Wenn halbwegs begabt bist einen Lötkolben zu schwingen, dann baue dir diese Expanderkarte selber. Das geht mit Locjrasterplatinen und den Schaltkreisen in DIP Ausführung besser und du kannst unabhängig der Relaiskarten oder Relais selber gleich noch einen MOSFET wie den BSS138 oder 2N7000 nachschalten. Damit kannst du den Strombedarf für diese Expander ( in der Summe 8 x 8 ) gering halten und die Relais trotzdem mit 5,0 V ansteuern. Allerdingsbenötigst du dann noch eine Freilaufdiode zum Schutz des MOSFETs sowie zwei zusätzlicher Widerstände ( Gate-Vorwiderstand und einen Gate-Source- Pulldown ).
Hier der Vorteil der genannten MOSFETs diese lassen sich mit jeweils 1,2-1,5 mA via des Gates auch mit 3,3 Volt ansteuern auch wenn das daran angeschlossene Relais mit 5 Volt betreiben wird.
Wobei ich mir hier mehr Gedanken machen würde wie bekomme ich für 8 x 8x 16 = 1024 diesen Relais Anzugstrom her, der theoretisch auftreten könnte. Im dümmsten Fall aller Fälle sind das 1024 * 0,14 A = 143,5 A bei 5 Volt ! Sowie im einfachsten Fall, wenn alle Relais nur einen Haltestrom von 15 mA aufweisen immerhin noch 22 A !!!
Die Programmierung ist eher das geringste Problem. Viel mehr sehe ich das Problem woher du für all diese ggf 5,0 V Relais den Strom herbekommen willst, und wie du alle diese vielen Proexpander plus den Multiplexer mit Strom versorgen willst ?
Alternativ du bist soweit in der Materie drin das du mit Fritzing oder KiCAD dir selber eine solche Ansteuerplatine mit dieser hohen Anzahl Proexpander designen könntest !? Fritzing ist für Linux auch das RasBianOS kostenfrei, ebenso KiCAD.
In diesem Sinne, bevor du planst irgendwleche Module zu kaufen, überlege dir ganz genau wie du diesen ganzen Batz mit Strom versorgen willst und ob du das überhaupt auf die Reihe bekommst !?
Es grüßt
Roland
Guten Morgen,
Wenn du mehrer Relaiskarten ansteuern willst, diese über einen Portexpander ansteuern, und ggf sogar über die gleichen Protexpander entsprechende Rückmelder in dein Steuerungssystem einspeisen willst, dann würde ich zu einem MCP23017 greifen.
Diese sind schnelle bezüglich des Datenverkehrs auf dem I²C wie andere Mitbewerbermodell aus den Häuser NXP oder Texas Instruments.
Zudem haben diese einen INT Rückmelder. Was für dich bedeutet die Portexpander welche als Eingänge dienen müssen nicht ständig via des Datenbusses I2C abgefrat werden, sondern der Portexpander meldet sich über einen separaten GPIO bei PI, das sich hier etwas verändert hat.
Wenn du wissen willst wie schnel dieser MCP23017 Portexpander sein können, mal von den resultierenden Schaltlatenzen der Relais selber abgesehen dann kommt man auf mit SCl Bus-Takt auf etwas 350 Schaltvorgänge im Multi-Bus Betrieb ( mehrere dieser MCP23017 parellel , nur mit getrennten Busadressen ) pro Sekunde.
Das Bedeutet du kannst via des I2C Busses 8 dieser !6 Port- Portexpander MCP23017 prallel anschliesen und betreiben. Wenn das nicht ausreichen sollte dann die SPI Version MCP23S17 verwenden, diese können mit der Erweiterung um ein CS Pin ( Gehört zum SPI BUS ) um jeweils weitere 8 dieser Expander erweitert werden. Auch hier kann man mehrere dieser MCP23S17 via Adress-Codierung an einem SPI BUs mit einem einzigen CS Signal 8 dieser Expander parallel schalten. Nur durch die Erweiterung um einen zusätzlichen CS Pin, bei gleichen Datenleitungen MOSI , MISO und SCLK kannst du das solange erweitern bis dir die freien GPIOs für die CS Funktion am PI ausgeht.
Technisch gesehen sind 16 CS, mal 8 MCP23S17 mal 16 I/O Ports an einem RasPI = 2048 solcher I/O Kanäle möglich.
SPI hat zudem den Vorteil das diese um einiges schneller ist, wie der I2C Bus. Allerdings wenn du auch Rückmeldekanäle installieren willst, musst du dir eine Möglichkeit erschaffen oder offen lassen diese INT-Rückmelder ( Eingangs-Portexpander ) mit dem RasPi zuverbinden .
Dieses kann man über einen GPIO IRQ Event machen, der dann diesen betreffenden Portexpander ausliest, und feststellen kann an welchem der Eingänge ein Siganalwechsel stattgefunden hat.
Damit müsstest du nur die entsprechende Anzahl Portexpander anschließen, diese nach dem Bus-Init entsprechend konfigurieren, ob Eingang oder Ausgang und dann läuft die Sache.
Noch ein Hinweis zu dem Beitrag von Fliegenhals bezüglich der Hallsensoren. Hier musst du aufpassen, besonders bei den digitalen Ausführungen, für welche Magnetfeldstärke diese ausgelegt sind, sonst kann es passieren das dieser nicht immer oder korrekt meldet.
Alternativ dann analoge Hallsensoren, welche dann aber eine Nachbeschaltung benötigen. Hier kann man mit einem einstellbaren Schwellwertschalter ( Operationsverstärker ) dann die Schaltschwelle mittels eins Potis sehr genau einstellen. Ohne zu wissen, welche Induktivität deine N-Spur verursacht um einen solchen Gleismelder aufzubauen, kann das auch sehr schnell teuer werden, wenn man versucht mit digital arbeitenden Hall-Sensoren so etwas aufzubauen, weil man muss sehr viel herumprobieren. Oder man kann in anderen Foren für Modellbau dort ein paar Werte abgreifen.
Es grüßt
Roland.
Guten Tag,
Der Part Bluetooth, da bin ich raus, außer der schon gewonnen Erkenntnis - das ist nichts für größere Entfernungen.
Jedoch bei der Steuerung würde ich auf einen µController setzen. Wie dem PICO W, oder einem ESP32.
Was du als Befehle sendest ist das eine ! Was der Controller ob nun eine RasPI oder µController draus macht ist was ganz anderes und von deinen Motor-Drivern abhängig.
Dann noch der Hinweis, weil aus deinen Angaben nichts hervorgeht, was soll mit dem Kettenfahrzeug passieren, wenn keine Funkverbindung besteht. Solllen die Ketten via Motorbremse ( Wicklungsschluß ) gebremst werden ? Oder soll sich das Fahrzeug im Falle das es an einem Hang steht der Schwerkraft folgen einfach weiter bewegen dürfen ?
Das ist aus meiner Betrachtungsweise, weil ja auch durch eine technische Störung ein Abbbruch der Funkverbindung eintreten könnte nicht wirklich bis zum Endedurchdacht. Oder die Angaben fehlen deinerseits.
Es grüßt
Roland
Das nicht, aber ich hab sie gerade an ein 12 V/17 A Netzteil gehängt. Ich denk, meine Nachbarn sind jetzt alle wach.
Was mich gerade trotzdem etwas "beunruhigt": Die Hupe besteht aus zwei einzelnen Hupen. Angegeben sind beide zusammen auf 4 A. Ich hatte jetzt die Stromzange bei einer Hupe mit dran und die hat dann 5,6 A angezeigt. Dann brauch ich (für eine einzelne Hupe) für'n Netzteil nicht unter 10 A anfangen, schätz ich mal. Damit hat sich auch der Step-Up/-Down/Stepper überhaupt erledigt.
USB-Tastatur hab ich keine mehr und auf sowas will ich eig. auch nicht zurück greifen, wenn die Anzahl der Geräte steigen soll. Ich will am Ende min. 4 Anzeigen mit Hupe haben, da könnt ich erst mal 4 Tastaturen killen.
Aber wenn des funktionieren sollte, dann doch auch Pi GPIO -> Levelshifter 5 V -> MOSFET [Anzeige], oder?
Wenn du dir das Datenblatt zu diesem MOSFETs auf diesem Modul mal genauer betrachtest, selbst wenn es dir gelingen sollte mit einem Levelshifter ausreichend GATE-Strom bei PWM Bereitzustellen, wird dir das Teil früher oder Später anrauchen.
Erst bei einer Gate Spannung von 10 volt ereichen diese MOSFETs ihren geringsten Innenwiderstand auf Drain-Source Strecke, und haben erst dann und damit ihren geringsten Thermischen Leistungsverlust.
Das sind Spielereinen ( LINK ) aber nichts für eine Anwendung mit diesen, deinen Leistungsdaten. Denn diese schöne Beschreiibung bezeichnet immer nur Maximalwerte die aber bei dir nicht so zusammentreffen werden.
Guten Tag,
japp, muss zugeben, an die Abwärme vom Widerstand, bzw. dessen Leistung hab ich jetzt nicht gedacht.
Gut das wir darüber gesprochen haben.
Die Hupe wird i. d. R. nicht länger als eine Sekunde angesteuert. Wenn ich da nur auf 50 % Nennleistung des Treibers/Reglers geh, sollte da keine extra Kühlung nötig sein(?).
Hier müsstest du auf zwei Dinge achten, den dritten Fall lassen wir mal außen vor.
Transistoren sind Stromgesteuert ! Eine Leistungsreglung damit geschieht primär über den Strom der zu Basis fließt, weniger wie die anliegende Basisspannung ( Wobei beide voneinder abhängig sind )
Hingegen MOSFETS sind rein Spannungsgesteuert, und der Strom zum Gate spielt eine untergeodnete Rolle, wenn es um eine Verstärkungsschaltung geht.
Damit ist es einfacher mit einem DAC oder DigiPOT ( leider nur via I2Coder SPI anstuerbar ) einen MOSFET zu steuern. Hierbei müsstest du nur beachten, das sich je nach Gate-Spannung auch der Innenwiderstand ändert, und somit die Verlustleistung beeinflusst. -> möglicher Weise Thema Passivkühlung !?
Ob das Horn oder Hupe auch noch mit einer PWM getakteten Eingangsspannung fehlerfrei funktioniert sollte im Vorfeld geklärt sein. Sonst verrennt man sich in der Lösungsplanung.
Ein sehr einfache Möglichkeit ist welche nur wenige Bauteile erfordert, sowohl bei PWM wie auch bei einer Reglung der Steuerspannung funktioniert ist eine simple MOSFET-Ansteuerungsschaltung. Dazu sucht man sich einen MOSFET, am besten einen LogicLevel MOSFET ( IRL oder IRLZ Serie ) heraus, welcher schon mit einer kleinen Gatespannung ( unter 3,3 Volt ) angesteuert werden kann. Da sowohl die Ausgänge des RasPi nicht viel Strom liefern können, was bei einer Nutzung eines PWM Signals kritisch werden könnte) wie auch DACs oder DigiPOTs nur sehr geringe Ströme ausgeben, bzw durchleiten können, kann man diese nicht dafür nutzen das Gate eines MOSFETs direkt anzusteuern.
Hier kann man sich mit einem fast beliebigen Operationsverstärker in der Beschaltunsgvariante Impedanzwandler einen Stromverstärker bauen, bei welchem gilt Uin = Uout . Nur das hierbei jetzt mehr Strom zu Gate fließen kann, ohne das der Eingang übermäßig belastet wird, was besonders bei PWM wichtig werden könnte.
Ich sag nicht generell Nein zu einem Lautsprecher und Tongenerator, damit ist aber der Aufwand wieder höher als mit einer einfachen 12 V Regelung.
Wenn man diese Kosten rein im Verhältnis zu einem Lastwiderstand der 50 Watt Klasse setzt, welcher auch noch aktiv gekühlt werden müsste, oder ein entsprechendes bauliches Monster sein wird, was sich in Form von Platz und Transportmasse niederschlägt, dann kommt man mit einem NE555 mit Außenbeschaltng und einem CLASS D Verstärker in der 10 WATT Klasse auf ca. 7 Euro Materialeinsatz. Auch diese Schaltung ließe sich von der Lautstärke via eine DigiPOTs ( 8 Bit = 255 Lautstärkestufen ) entsprechend Regeln und würde nicht mehr wie 1,30 Euro kosten.
Den I2C Bus kann man bequem einfach durch Parallelschaltung der Datenleitungen erweitern. Das geht auch bei einem HAT, wenn man an die betreffenden GPIO Header ( SDA udn SCL ) einfach paar Drähtchen anlötet.
Das ist alles keine Raketenwissenschaft. Würde aber sehr zuverlässig und vor allem Verschleißfrei funktionieren. Relaiskarten und Gleichspannungslasten in diesem Ampere Bereich bedeutet früher oder später immer den Ausfall des Relais, besonders wenn die Schaltzeiten so kurz sind.
Dieses HAT ver- oder behindert nicht die Verwendung des I2C-Busses. Es ist aus meiner Sicht nur Bequemlichkeitsdenken.
Es grüßt
Roland
Guten Abend,
Falls es dir nicht aufgefallen ist, einmal schreibst du in deinem Einführungstext:
sudo pip3 install adafruit-circuitpython-ssd1306
Und in deinem Bildschirmprint steht
sudo pip3 install adafruit-circuitpython-servo-kit
hat das eine besondere Bewandnis ?
es grüßt
Roland
Guiten Abend.
Vergiss mal ganz schnell die Idee mit einem umschaltenden Relais das Ganze umsetzen zu wollen.
Auch der Widerstand muß den Strom abkönnen, welcher durch die Hupe fliest. Damit wäre ein mind. 50 Watt Widerstand notwendig ! Wie willst du dieses Monster kühlen ?
Dann solltest du dir im weiterem überlegen, wie du eine Leistung, egal ob mit PWM, einen DAC oder einem DigitalPotentiometer regeln willst dieses auch bezüglich des Leistungsverstärkers Transistor, MOSFET oder Thyristor so umzusetzen gedenkst. Du solltest dabei immer Bedenken, egal welcher Leistungstreiber zum Einsatz kommt, dieser muss ggf je nach Benutzungsdauer auch entsprechend gekühlt werden.
12 Volt bei 4 A sind schon mal eine Hausnummer. Wäre hier nicht eine einfahchere Lösung besser die auf einem Tongenerator z.B. NE555 basiert, welcher am Ausgang geregelt werden kann, und dann mittels eine Class-D Verstärkers einen Lautsprecher ( Hornlautsprecher ) anzusteuern ?
Nur Nachgefragt: Warum steht der I2C Bus oder andere GPIOs z.B. für den SPI Bus nicht mehr zur Verfügung ? Oder scheust du einfach nur mehrere Bus Endkomponenten an einene der Busse anzuschließen ?
Es grüßt
Roland
Hallo,
Dann lerne Schaltpläne Korrekt zeichnen !
Aus diesem Abschnitt deines Schaltplanes geht hervor:
hier ist zu sehen:
Wenn etwas anderes beabsichtig ist, solltest du ganz schnell lernen deine Schaltpläne korrekt zu zeichnen !
Was man auch nicht macht - bei einer solchen Komplexität eines Schaltregisters, die Anschlüsse zu einem Netzwerkbus zusammen zu fassen.
Egal was du machst, egal was du hier vorgibst darstellen zu wollen, wenn man diese Schaltung vereinfacht zusammengefasst mit LM358 aufbaut um das R2R Netzwerk wie gezeichnet abzubilden, was ich auch im praktischen Aufbau auch getan habe, um deine Thesen zu widerlegen, komme ich immer wieder zu meiner ursprüngichen Aussage zurück. Das Ganze ist ein riesengroßer Murks.
Nur kenne ich das Verhalten deiner LT1356 OPVs nicht, jedoch bestättigt sich mit LM358 Ersatztypen dieses von mir benannte Schalt- und Spannungsverhalten.
Also bitte ich dich, hier nicht als Lehrmeister aufzutreten, welcher noch nicht einmal die Grundschaltungen an einem OPV -> Komparatorschaltung ohne Rückkopplung verstanden hat, und auch nicht die Grundlagen eines Spannunsgteilers zu erkennen mag.
Dieses Ganze hier ist doch von keinem wirklichen Nutzwert für die Forengemeinschaft. Das ist ein theoretischer Ansatz, welcher vom Grundaufbau schon zum scheitern verurteit ist.
Da zudem auch keine Absicht deinerseits besteht, auch nur Teile dieser Schaltung in der Praxis auszuprobieren und nachzumessen, sondern deine Erzählungen eher einer Geschichte gleicht, welche keinerlei praktischen Bezug hat.
Baue dieses R2R Netzwerk mit diesen Widerstandswerten auf, benutze so wie gezeichet ein symmentrische Spannungsversorgung, lege den Bezugspunkt des Spannungsteiler auf Masse und du kannst mit jedem billige Multimeter aus dem Baumarkt nachprüfen das du hier nur Unsinn verbreitest .
Damit kannst du dich mal der praktischen Schaltunsgumsetzung zuwenden, und hier nicht nur theoretische Abhandlungen von dir geben, die bei einer praktischen Umsetzung nicht so funktionieren wie du es mit deinem Beitrag beschreiben willst.
Machen, einfach machen, ich spende dir auch die Platine mit dem Aufbau bestehend aus 10x LM358 + aller Widerstände Vielschicht Metalloxid 1% in den Werten 50 kOHm und 100 kOhm.
Hallo,
Ein paar Fragen an den Autor dieses neuerlichen Schaltbildes hätte ich hier schon einmal - weil so richtig ergibt das Ganze keinen Sinn. Gehe ich richtig in der Annahme oder interpretiere ich die Funktion richtig, wenn ich folgende Dinge annehme:
Hast du diesbezüglich folgende Dinge berücksichtigt ?
Wenn du den Spannungspegeln der PICO-GPIO nicht vertraust, dann nimm dir einen P-Chanel MOSFET als Kleinlastsytem in der Bauform SOT-23 und einer Umschaltzeit im unteren zweistelligen Nanosekunden Bereich, schalte diese invertierend damit bei einer Gatespannung gleich GND die anliegende Sourcespannung über den Drain in dein R2R fließen kann. Durch einen Pullup gegen Pin 36 des PICO kannst du sicherstellen die Umschaltung GPIO-OUT auf GND führt nur in diesem Fall zu einer Spannungseinspeisung in dieses R2R.
Bevor es dir gelingt durch Eingriffe in die symmetrische Spannungsversorgung dieses asymmetrische Verhalten der OPV als Komparator auszugleichen, bevor es dir gelingt durch das gegebene zeitlich asymmetrische Schaltverhalten als Komparator sowohl die Referenzspannung pro OPV-Gatter anzupassen, wie auch das GPIO Ausgangssignal anzupassen, damit diese geannnten natürlichen, für diesen Anwendungsfall Fehler auszugleichen, oder abzustellen, geht der gesamte Sinn eines R2R DAC verloren.
Mein Ansätz wäre beim klassichen R2R zu bleiben, diesen nur im positiven Spannungsbereich zu beteiben, dazu wie schon erwähnt die Ungenauigkeiten der GPIO-Ausgangsspannung nur mittels invertiert schaltender PMOS auszugleichen, und dann einen einfacheren Weg suchen, diese Wellenform durch Übertrager oder Ein- und Auskoppelelemente in ein vollsymmetrisches NF Signal zu verwandeln. Je höher die Anzahl der beteiligten Bauelemente während und bei der Signalformmodulation, um so höher ist auch der potentielle Fehler in der resultierenden Signalform. Bleibe im Bereich des R2R einfach, verkomplziere nichts. Verzichte auf komplexe Signalinvertierungen wie mit diesem ganzen OPV Gedöns.
Falls dir das alles zu einfach oder zu simpel erscheint, oder eben dann doch in der Beschaltung um den PICO herum auszuufern droht, du kannst auch mittels einer kompilierbaren Hochsprache ein I2S Signal erzeugen, und dieses dann in einen Audioverstärker mit einem I2S Signaleingang schicken, ähnlich wie es bei der kleinen Variante mit dem ESP von md_fg vorgeschlagen wurde.
Auch der PICO lässt sich ohne Probleme auf 240 MHz hochtakten, so das bezüglich der CPU Leistung dieser einem ESP im Nichts nachsteht.
Noch dieses als letzte Hinweis: Wenn du via Pin 35 eine Spannung 3,3 Volt in das PICO einspeist , somit Pin 39 und 40 unbenutzt lässt, umgehst du den Spannungsregeler auf der PICO-Platine. Damit sind die Schwankungen der Ausgangsspannungen an den GPIO-OUT darauf beschränkt was die Versorgungsspannungsquelle bevorzugt Linearregler über Pin 35 einspeist liefert. Man kann auch mit einem LM317 und einer externen einstellbaren Referenzspannungsquelle diesen entsprechend hochgenau stabilisieren und trotzdem zu einer einstellbar Versorgungsspannungquelle machen. Damit könntest du ohne Schalt- und Signalverstärkerelemente den R2R aus den GPIO dirket betreiben. Wieider eine Fehlerquelle weniger.
Roland
Hallo und guten Morgen,
Ein Frage bezüglich der Schaltung an md_fg hätte ich mal.
Dazu habe ich mir im dem verlinkten Beitrag diese Schaltung mal genauer angesehen und stoße dabei auf eine kleine Merkwürdigkeit. Könntest du mir bitte einmal im Detail erklären, welchen Einfluß die Oszillator-Frequenz des ICL7660, welche auch ein laut Datenblatt unschönes Ripple hinterläßt, Einfluß auf das Ausgangssignal haben könnte.
Meines Wissens nach kann an nicht mit einem einzelnen ELKO - im Plan bezeichnet 10 µF Tantal
diese Form der Ausgangsripples
[ Auszug aus dem Datenblatt des ICL7660 : Hersteller RENESAS ]
glätten. Damit entsteht doch, weil dieser negative Anteil der Vcc des OPVs somit periodischen Schankungen im Bereich 5-8 kHz unterworfen ist, auch eine solches Kurvenform-Duplikat, welches sich über diesen speziellen Aufbau mit nur einem OPV-Schaltkreis als solches dann auch wieder in Form eines erhöhten Rauschens im Ausgangssignal wiederfindet.
Gibt es bezüglich dieser Nachbeschaltung des ESP-DAC irgendwelche genauern Auswertung ( Oszilloskopansichten ) wie das insgesamt mit dem Störanteil in Nutzsignal sich verhält ?
Auch die Bilder, welche im Blog von AZ-Delivery zu diesem Thema jedoch unter Teil1 veröffentlich worden - läßt hier nichts Gutes erahnen.
[Bild aus dem Blog-Beitrag]
Wenn ich diese Bild richtig interpretiere und die Schwankungen der Spannungspunkte an den Amplitudenumkkehrpunkten betrachte sieht das für mich so aus, das hier ein Fremdrauschanteil in der Größenordung von 5 bis 7 % im Nutzsignal enthalten ist.
Damit stelle ich einfach mal die Frage in den Raum, ob es sich wirklich mit einem so "minderwertigen" Ausgangssignal lohnt b.z.w. ob es überhaupt sinnvoll ist, damit einen Verstärkerstufe / Frequenzweichen abstimmen zu wollen ? Sowie ob man damit das angedachte Ziel einer Abstimmung erreichen zu können ? So wie ich Batucada2 verstanden habe, möchte er Gegentaktendstufen auf Basis von Elektronenröhren in den Verwendung als Vorverstärker und Endverstärker abstimmen.
Sorry, wenn ich diese Ausreißer um die Nulllinie sehe ( nachfolgendes Bild ) stelle ich die tatsächliche Verwendbarkeit dieser Schaltung für diesen Anwendungsfall in Frage.
[Bildschirmausschnitt mit Markierungen des oberen Bildes aus dem Blog-Beitrag ]
Ich hoffe md_fg kann hierzu genauere Angaben liefern, und g.g.f. diese Bilder ( Oszilloskopaufzeichnungen ) aus der Blog-Doku revidieren.
es grüßt
Roland
Sorry, wenn ich das mal so am Rande bemerke:
Ich verstehe hiervon nur so viel, wie ich eins und eins zusammenzählen kann.
In einem Beitrag hat der TO ein Gehäuse-Design präsentert, wo unter der RasPi Platine noch zwei SSDs eingelagert sind, zudem ein Teil des RasPI von einem HAT, einem Hifi_Berry abgedeckt werden.
In erster Linie kritisierte der TO das aufheizen des RasPi, aber um den Betriebszustand der SSDs macht er sich offensichtlich keine Gedanken.
Für mich stellt sich die alleinige Frage was passiert, oder wird passieren wenn dieser Sub-Prozess - dieses Python Programm einmal hängt, oder gar abstürzt ?
Die Einbindung weiterer Sensoren, oder gar die Abfrage via S.M.A.R.T. welchen Betriebszustand / -temperturen die SSDs haben, sehe ich hier noch gar nicht berücksichtigt.
Auch wenn das Projekt nun schon einiges an Fortschritt erzielt hat, würde ich einem RasPi alleine nicht die vollständige Lüfter-Kontrolle überlassen. Es gibt Halbleiter-Kontakt-Temperatursensore welche mittels I²C abgefragt werden können, und die objektive Gehäusetemperatur der SDDs liefern können.
Mal abgesehen davon wie lange benötigt ein RasPI mit dem Startprozess bis unter günstigsten Bedingungen diese Lüftersteuerung aktiv wird ?
Auch wenn es von der Forenrubrik hier vielleicht der falsche Beitrag ist, ich würde diese Controller-Funktion an einen µController übertragen, welcher nicht nur eine deutlich kürze Reboot--Zeit hat ( Watchdog ) sondern auch mit den RasPi auf unterschiedliche Art und Weise kommunizieren kann, um von diesem die via gpiozero ausgelesene CPU Temperatur zu erfahren. Ich kenne weder den Hauptverwendungszweck dieses RasPis vollständig, und auch nicht den Sinn dieser beiden SDDs. Dennoch gebe ich zu bedenken, das reine Dateioperationen über das Filesystem, sprich dem reinen kopieren von Daten zwischen A und B die SSDs thermisch mehr belastet wie die CPU selber.
Daher schein mir diese Auswertung wie in den Pythonen Programmen präsentiert als unvollständig zu erscheinen. Ebenso, was in einem der Beiträge zuvor scho erwähnt wurde, fehlt hier eine logische Betrachtung der ermittelten Tachowerte. Weder wird eine proportionale Unterschreitung zum ausgegebenen PWM dazu genutzt, eine Alarmmeldung auszugeben - man verlässt sich offensichtlich ausschließlich auf das PWM Signal. Und zu anderen was würde passsieren, wenn der Lüfter die theoretisch dem PWM Wert entsprechende Drehzahl nicht mehr erreicht, oder wegen einer Blockierung stehen geblieben ist ?
Ich denke hier sollte der TO sich mal einige zusätzliche Überlegungen anstellen, wie er die Funktions- und Betriebssicherheit entsprechend seinen persönlichen Anforderungen erhöhen könnte.
Es grüßt Roland
Diese Tabelle besteht aus einer mehreren Listen.
Diese Basistabelle enthält immer 1200 Einträge.
Die Anzahl der Einträge innerhalb der Tuple variiert sehr stark. Diese lese ich aus einer Datei ein, welche von einer anderen Software erstellt wird. Diese nutze ich nur. Kenne aber deren Code nicht.
Dann gibt es eine globales Kamera Bild.
Einmal sollen alle Farben die in dieser Tuple sind erhalten bleiben, die anderen Bildpunkte sollen durch einen Durchsichtigen Punkt ersetzt werden. Die andere Funktion macht es genau anders herum, jedoch mit einem Zusatz, es findet eine Vergleich zu einem Grauwert statt.
Es entstehen also jeweils 2 neue Bilder.
Doch das mache ich schon. Aber nicht direkt, sondern mit einer Kopie.
Ein Rückkopplung ist nicht gewollt, und konnte ich auch bisher nicht feststellen.
Alle anderen Berechnungen und Auswertungen finden dann ausschließlich mit der arbeitstabelle statt.
Ich danke euch für die vielen Antworten.
Leider verstehe ich von diesen Diskussionen nicht einmal die Hälfte.
Dazu bin ich zuerst dem Hinweis von @bennetr nachgegangen. Eine reine Katastrophe. Die Durchlaufzeit hat sich sogar noch verlängert. Mit @DeaD_EyE Methode welche ähnlich der vorherigen ist komme ich überhaupt nicht klar. Weil ich habe keine Rückmeldung mittels eines return, welcher dann auch noch ausgegeben werden muss.
Entweder ich habe einen Code-Fehler oder die ganze funktioniert doch nicht so wie es soll ?
Die ersten Funktionsaufrufe solange max_worker nicht überschritten werden, folgen noch dem Prinzip einer leicht beschleunigten Abarbeitung. Jedoch muss erst der Pool vollständig leer laufen, oder abgearbeitet sein bevor sich der Pool wieder mit neuen Aufgaben füllt.
import concurrent.futures
def funktion1(wert, tabelle):
pass
def funktion2(wert, tabelle):
pass
max_workers = 8
with concurrent.futures.ThreadPoolExecutor(max_workers) as pool:
for i in range(1200):
pool.submit(funktion1, i, Tabelle)
pool.submit(funktion2, i, Tabelle)
Display More
je öfters diese Programmkonstrukt durchlaufen um so höher sind auch die Durchlaufzeiten der einzelnen Funktionsaufrufe. Das heißt, bis ca. "i" = 30 findet noch eine schnellere Abarbeitung statt. Dann wird das ganze so etwas von langsam, das einzelne Durchläufe einer Funktion, mit den gleichen Parametern im Gegensatz zur rein seriellen Abarbeitung sich auf bis zu 23 Minuten verlängern. Obwohl im Ablauf meines ersten Codes dieser Vorgang noch rein ans nach dem anderen nur ca. 3-5 min im Maximalfall gedauert hat.
Danke im Voraus.
Roland
Ich habe mal eine Frage bezüglich der Parallelisierung und damit zur Beschleunigung der Programmlaufzeit.
def funktion1(wert, tabelle):
# Ausführungscode Aufgabe 1
def funktion2(wert, tabelle):
# Ausführungscode Aufgabe 2
parameter2 = LIST(#irgendwas)
for übergabewert in range(1200):
funktion1(übergabewert, parameter2)
funktion2(übergabewert, parameter2)
nun habe ich schon in einem Internet-Tutorial gelesen, man könne nur ein gewisse Anzahl Threds starten, was von der Anzahl der CPU Cores abhängig sein soll.
Wie kann ich nun den Ablauf dahingehend anpassen und verbessern ?
Wenn man jetzt sagen würde, Okay 8 Threads sind zulässig, aber man möchte das immer mindestens 2 Threads von einer Funktion genutzt werden.
Dazu möchte ich anmerken, die Durchlaufzeiten der beiden Funktionen ist sehr unterschiedlich und auch sehr stark von diesem Übergabewert abhängig. Einmal ist die Durchlaufzeit von Funktion1 sehr kurz, hingegen Funktion2 mit dem gleichen Werte viel viel länger dauert. Aber auch umgekehrt.
Es ist für das Ergebnis schlussendlich nicht relevant ob alle Durchläufe zum gleichen Zeitpunkt fertig werden. Es kann je nach dem einmal die eine Funktion und dann auch wieder andere Funktion eher fertig sein. Jedoch möchte ich nicht das wie in diesem Grundprogramm die Abarbeitung rein statisch in chronologischer Reihenfolge abgearbeite wird, sonder erst einmal die ersten 4 Thread mit ersten Funktion starten, und auch mit der zweiten Funktion. Je nach dem wer eher fertig wird soll dann immer der fertiggestellte Ablauf durch einen neuen Thread ergänzt werden. Die einzig wirkliche Bedingung ist, die Reihenfolge der Funktionsaufrufe muss wie in der Schleife 0 bis 1200 einhalten. Was bedeutet wenn Funktion2 noch nicht den Durchlauf für den Übergabewert z.B. 17 gemacht hat, jedoch die andere Funktion zum Beispiel schon bei 35 ist, darf dann eben auch nicht diese 17 als Wert übersprungen werden.
Ich hoffe ich habe das halbwegs verständlich ausgedrückt.
Roland