Posts by schnasseldag

    Der erstbeste Link der Suchmaschine des Vertrauens zu den "Schematics" des PiFace zeigt, daß P1 zur externen Speisung der Open Collector des ULN2801 vorgesehen ist. Damit könnte man z.B. mit einem zusätzlichen 12V oder 24V Schaltnetzteil direkt 12V/24V Koppelrelais steuern, die dann auch die erforderlichen Kriechstrecken zwischen Kleinspannung und Niederspannung einhalten. Die auf den Sainsmartmodulen verbauten Relais halten mit ihrem Mittelanschluß die erforderliche Distanz bei 230VAC (und üblichen Verschmutzungsklassen etc.) nicht ein. Soviel zum Thema 230V.


    Nun schreibt der TE, daß der Niederspannungskreis ja bereits über (12V) Relais fachmännich getrennt wäre. So das der Fall ist, und die Relais bei 12V keinen nennenswerten Strom ziehen (wissen wir nicht, weil wir kein Bild der Relais haben), ließen diese sich auch direkt über das PiFace steuern, wenn eben an P1 die erforderlichen 12V angelegt werden würden. Das Sainsmartgedöns wäe dann schlicht überflüssig.


    Kleine Falle - keine Ahnung, ob die herausgesuchten Schematics zum PiFace des TE passen. Von diesem Modul gibt es verschiedene Hardwarerevisionen.

    Und wie säubert Ihr das Coderad eines Heizungsthermostaten? Rein kommt man in die Dinger ja seit einiger Zeit nicht mehr, weil die Gehäuse nicht mehr verschraubt, sondern verschweißt sind. Schlitze zur Dreckansammlung sind aber massenhaft vorhanden, sodaß sich die Codescheibe der Lichtschranke gern zusetzt. Da hilft dann nur Pressluft zur Beschleunigung des Coderades auf weiß-nich' wieviel Umdrehungen, damit die Fliehkraft den Schmutz herunterwirft - weil geziehlt einblasen geht leider nicht wirklich. Dafür sind die drecks "Dreckeinlaßschlitze" leider zu klein und innen verblendet/zugebaut.

    Hallo Paileheisster,


    vom ULN2803 gibt es verschiedene Typen (selbst bei den DIP-Typen) mit unterschiedlichen Leistungen. Zur Stromsteigerung kannst Du mehrere Ausgänge parallelschalten. Aber, die Strombelastung pro Ausgang stellt nur eine Limitierung dar. Letztendlich kommt es auch auf die Wärmeentwicklung im Chip an. Wenn Du ungefähr 0,6V Spannungsabfall am ULN-Ausgang (oder den Ausgängen) annimmst, so gibt das bei 1,3A ungefähr 0,78W Wärmeentwicklung, die abgeführt werden müssen. Diese Wärme äußert sich in einer Temperatursteigerung des IC gegenüber seiner Umgebung (Luft bei 20°C z.B.). Übersteigt das IC dabei die zulässige Höchsttemperatur (siehe Datenblatt), dann muß diese durch Kühlkörper begrenzt werden. Strom/Ausgang oder die Summe der Ströme/Chip sind also nur die Hälfte der Wahrheit, die andere liegt in der zulässigen Höchsttemperatur und der Wärmeentwicklung/Watt. Ich denkle mal, mit 2 ULN (und jeweils 2 parallelgeschalteten Ausgängen) solltest Du leistungsmäßig hinkommen.

    Vewechsle bitte nicht Leistung mit Jitterfreiheit. Dein herausgesuchtes PWM-Board kann zwar saubere Impulse erzeugen, die von Dir geforderte Leistung jedoch eher nicht schalten (es sei denn, Du greifst tatsächlich auf teurere Lüfter mit PWM-Eingang zurück - etwas, was Du Dir eigentlich sparen könntest). Diese Schaltung muß dann immer noch her. Daher der Rat, zunächst mal mit den ULN's anzufangen. Billiger/einfacher geht's vermutlich nicht.


    Schöne Grüße


    schnasseldag

    @Mods: FYI - Im Codesnippet werden meine Quellcodekommentare gestripped.

    Siehe >>> hier <<<


    #include <stdio.h>

    #include <unistd.h>


    #include "../hubolib.h"

    #include "../hubocfg.h" // Required for changing default I2C device.


    using namespace HuboLib;


    /*

    Compile and link:

    g++ FanSpeed.cpp -L../ -lhubo -lpthread -lrt -o FanSpeed.out

    Run:

    sudo ./FanSpeed.out

    Purpose:

    Simple demo doing sending ON-OFF patterns to a digital output e.g. to control fan speed.

    */


    #define FAN_CHANNEL 0

    #define WAIT_TIME 10000



    Das betrifft C++-Zeilen wie auch -Blockkommentare.

    Hallo Pauleheister,


    nachdem der Lüfter-Steuerungsteil Deines Projektes in die Ecke "das stecken wir mal fix zusammen" fällt, habe ich das kurzerhand getan. Siehe Bild:



    Bei den Lüftern handelt es sich um einen ohne Tachogenerator (der große, gerade in Betrieb befindliche links; 12V) und um einen mit Tachogenerator und PWM-Eingang (rechts; 24V), welche aber beide unbenutzt blieben. Gesteuert wurde per An-Aus-Paketfolgen mit Taktungen im 10ms Bereich. Zwar sitzt zwischen den GPIO's des Raspi und dem ULN2803 noch ein MCP23017 IO-Expander, der tut hier aber nix zur Sache, außer, daß er eher die Taktung begrenzen würde. Die Drehzahlen ließen sich durch unterschiedliche Paketfolgen recht gut steuern. Hier das Programm dazu.


    Die WAIT_TIME definiert die Aktualisierungsgeschwindigkeit der An-Aus-Pakete. Die Cycletime von 5ms definiert die Aktualisierungsgeschwindigkeit der IO's, da per Set_DO_Channel zunächst nur in einen Puffer geschrieben wird. Aber das sind Interna meine Lib, die hier unerheblich sind. Die while-Schleife ist eigentlich selbstredend. Die CPU Last liegt bei einem Raspi 2B bei <=2,7%.




    Fazit - fang' mal frohen Mutes mit einem Raspi und einem ULN2803 an. Wenn Probleme auftauchen, dann eher bei der Ansteuerung der Pumpe. Aber wir haben ja auch noch einen Kondensator in der Hinterhand... :-)


    Schöne Grüße


    schnasseldag



    @Mods: Warum werden meine ganzen Quellcode-Kommentare aus dem Codebeispiel gestripped? Da Funzt etwas nicht?!

    Omikron : Was man Dir hier zwischen den Zeilen mitzuteilen versucht ist, daß ein Anschließen eines Summers an die Pfostenbuchse eines IO's als recht unbedarft erachtet wird. Es ehrt Dich ja, lernen zu wollen, aber das hast Du in diesem Thread nicht praktisch gezeigt. Ohne Kenntnis des Ohmschen Gesetzes und etwas Halbleiterwissen verbietet sich eigentlich jedwedes Kabelstecken.

    Ich empfehle Dir die Grundlagen des Elektronikkompendiums zu studieren. Diese Seiten sind wirklich gut. Außerdem will ich nochmals auf meinen Vorschlag der fertigen Lösung zurückkommen. Die kann man nämlich auch erst mal verstehen und so einiges daraus lernen - so man sich ein Multimeter kauft und auch mal mißt. Viele Kinder sind bereits als Säugling in einem Auto mitgefahren, ohne zunächst zu wissen, was ein Auto ist. Danach wurden sie größer und haben den Führerschein gemacht. Später interessierte sich der eine für Technik und wurde letztendlich Kfz-Mechaniker, ein anderer Taxifahrer. Ich habe aber noch nie ein Kind gesehen, welches als Erstlingswerk das Ventilspiel eines Tassenstößels gemessen hat.

    Na mit Kanonen (Dein Leistungsregler) mußt Du ja nicht auf Spatzen schießen. Ein ULN2803 an den GPIO's reicht für Deine 12V Lüfter vollkommen. Der Ausgang des ULN ist als offener Kollektor (OC) ausgeführt und erlaubt Schaltspannungen >24V (zumindest bei den paar mW Deines Lüfters). Zu diesem Thema gibt's hier gefühlt 3623 Threads. Der Arduino ist dann besser, wenn es um echtes (will heißen hardwaregetaktetes) PWM geht. Wäre mechanik im Spiel, die verlorene Meßimpulse eines Tachos oder Windupeffekte eines Reglers mit Knirschen, Brummen und Stößen beantwortet, dann würde ich hinsichtlich der Steller und vor allem der Impulserfassung auch zu einer Hardwarelösung (sprich Arduino) greifen. Für "lastlose" und dabei gedämpfte Lüfter muß das m.E. nicht sein. Wenn, dann würde ich am ehesten bei der Pumpensteuerung vermuten, daß man da etwas hört.


    Noch ein Hinweis. Wenn Dein Boss unbedingt einen Pi sehen will, dann fange halt mal mit dem Pi an und schau, ob das Konzept paßt. Wenn nicht, dann kannst Du zur Steuerung immer noch einen Arduino zwischen den Pi und die Lüfter setzen.

    Omikron : Warum kaufst Du nicht zunächst eine funktionierende Lösung, wenn Du ein Anfänger bist? Z.B. >>> hier <<<. Wenn Du sie dann verstanden und ein wenig herumgemessen hast, dann wird es einfacher auf Bauteileebene zu agieren und sich selbst Schaltungen auszudenken. Das ist nicht nur der schnellere und sicherere Weg, es ist auch der wesentlich billigere!

    Hallo Pauleheister, Hallo Jar,


    der Tachoausgang erlaubte die Implementierung einer Regelung. Schaden würde diese sicherlich nicht (wenn die Regelparameter richtig gewählt werden), ob man sie allerdings bei einer Lüftersteuerung benötigt, ist eine andere Sache. Mit Tachogenerator hätte man jedoch zumindest die Möglichkeit - selbst im Falle einer späteren reinen Steuerung - die Stützwerttabelle der An-Aus-Zeiten für die verschiedenen Geschwindigkeiten zu erstellen.


    Allerdings bergen Tachogenerator/Regelung wieder ein Problem, nämlich das verlustfreie Signalabtasten des Tachos. Und da ist das OS des Raspi wirklich hinderlich, so es sich beim Sensor um einen impulsgebenden (z.B. Hallsensor) handelt. Auch ein Spannungsausgang am Tacho würde wieder zusätzliche Beschaltung erforderlich machen. Im Gleichspannungsfall einen AD-Wandler, im Wechselspannungsfall vermutlich wieder eine Impulszählung des Nulldurchgang. Aber solche Tachos findet man eher bei größeren AC-Motoren.


    Im Falle einer reinen Steuerung würde ich im OS Jitter des Schedulers kein allzugroßes Problem vermuten. Der Jitter der Desktopkernel liegt bei unausgelastetem OS in der Größenordnung einer ms oder sogar darunter. wenn man also Konstrukte in der Größenordnung "usleep(50)" zusammenbaut, dann ist der Fehler für einen in (dämpfender) Luft laufenden Lüfter recht gering. Man vergegenwärtige sich zum Vergleich die geregelten 230V Standlüfter, die z.T. mit Phasenanschittsteuerungen betrieben werden. Auch hier liegt die steuernde (geregelt wird da auch nicht) Phase bei 50Hz, also 20ms.

    Klopfende Geräusche aufgrund axialen Spiels der Welle würde ich ebenso nicht erwarten, da das Propellerblatt die Achse zwingend auf das Axiallager drückt.


    Und falls tatsächlich irgendwelches steuerungsbedingtes Brummen zu hören wäre, dann bestünde immer noch der Weg der Glättung der Pulse über einen Kondensator parallel am Motor. Letztendlich ist es eine Frage der Spannung, wie schnell Lüfter dieser Bauart drehen...


    Schöne Grüße


    schnasseldag

    Wahrscheinlich tut es auch ein normaler Lüfter mit nur zwei Leitungen an einem ULN2803 (siehe Open Collector). Nachdem man die Viskosität der Luft wohl als konstant annehmen darf, ließe sich die Drehzahlsteuerung dann über "einfaches" Ein- und Ausschalten erreichen (notfalls mit Stützwerttabelle für mehrere Drehzahlen, um den quadratisch ansteigenden Strömungswiderstand auszugleichen - so daß überhaupt notwendig ist).

    Echtes PWM im höheren (1kHz) Frequenzbereich bedarf es bei so einer unkritischen Anwendung vermutlich nicht. Falls doch, dann würde ich auf einen Arduino ausweichen. Der kann PWM besser...

    Hallo homemade,


    wenn Du per SSR schaltest, dann werden diese vermutlich eine Nullpunktschaltung integriert haben. D.h. Ein- und Ausschaltpunkt liegen in der Nähe der Phasenumkehr. Soweit so gut. Verwende nochmals einige Gedanke darauf, wie lange Du den Heizstab zuschalten willst und wann Du ihn abschaltest. Wieso? Je nach Regelungstakt Deines Wechselrichters/Homemanagers wird schneller oder langsamer bestimmt, ob Deine Photovoltaikanlage nun über 70% Leistung einspeist oder eben weniger. Ich vermute, das System wird das wohl über eine gewisse Zeit aufintegrieren (wie schnell, daß weiß ich nicht). Sollte dem so sein, dann könntest Du Deine Leistung tatsächlich paketweise zuschalten und abschalten, um eine Art der Lastmodulation zu erreichen. Bewegt man sich nun aber auf "Halbwellen", dann sollte die Belastung nicht immer im gleichen Quadranten erfolgen. Vollwellen wären da schon besser (um die Last gleichmäßig zu verteilen). Nun stellt sich aber die Frage, wie Dein Raspi Kenntnis über die Phasenlage Deines Netzes erhält? Besitzt er diese Kenntnis nicht, dann mußt Du die Zeitspanne Deines "Modulators" entsprechend länger wählen, um z.B. 10 Wellenpakete durchzulassen, damit der Fehler kleiner ausfällt, als beim Versuch der Taktung eines einzelnen Paketes. Je länger Du aber Deine "Modulator-Pulsbreite" setzt, umso eher könntest Du in das Problem fallen, mit dem "70%"-Integratortakt Deiner Photovoltaikanlage zu kollidieren (Shannon).


    Abhilfe schafft die Kenntnis über den Phasendurchgang. Dann kannst Du ganz gezielt einzelne Pakete durchstellen oder eben nicht. Im Zuge der Untersuchung der Wellenpaket- bzw. Phasenanschittssteuerungsmöglichkeit diverser Motoren hatte ich mal einen Testaufbau erstellt. Die Phasenerkennung (mit OK getrennt vom Mikrokontroller) ist im anhängigen Bild zu sehen.

    Nebenbei - tatsächlich weisen einige Motoren bauartbedingt Geräuschentwicklung auf, wenn sie per Wellenpaketsteuerung betrieben werden. Daß hat aber zwei Gründe:

    a.) die Rotoren bewegen sich beim Anlaufen axial auf ein Lagerende (Klopfgeräusch) und

    b.) die Paketzusammensetzung paßt nicht zur Wicklung des Motors, was über einen gewissen Gleichanteil in der erzeugten Wechselspannung zu einer Erwärmung des Motors sowie zu einem Brummgeräusch führt.

    Bei einer Belastung durch einen (ohmschen) Heizstab ohne bewegliche Teile würde ich von keinerlei Geräuschentwicklung ausgehen. Auch ist das Thema EMV bei Nulldurchgangsschaltung ohmscher Lasten ein erheblich geringeres als das von Phasenanschnitten und/oder nicht-ohmschen Lasten.


    Schöne Grüße


    schnasseldag


    PS: Das Bild soll jetzt keine Ermutigung sein, Niederspannung zu handhaben, wie auf dem Bild zu sehen!!! Es soll lediglich verdeutlichen, daß es kein Hexenwerk ist, eine Nulldurchgangsschaltung aufzubauen und mittels SSR und µC eine Last zu schalten.



    @mr_pipapo Wie stellst Du Dir denn das Aussenden der Befehle vom Raspi hin zum Garagentoremfänger vor? Soll der Raspi ein Relais bedienen, welches eine Taste drückt, handelt es sich ggf. um ein bereits bekanntest Protokoll, welches irgendeine Middleware funken kann oder mußt Du das Protokoll irgendwie entschlüsseln? Das sind völlig unterschiedliche Herangehensweisen mit völlig unterschiedlichen Lösungen...

    Hallo Heimfried,

    Das Kind fiele nach meiner Ansicht nur dann in den Brunnen, wenn ich glauben würde, dass diese Leistung anschließend ungeschmälert in den Batterien steckt (und sich dann möglichst auch noch ohne Verluste wieder herausholen lässt). Gerade diese Verluste sind für mich ein wichtiges Thema und die Batterie-Alterung habe ich auch im Blick.

    Soweit gebe ich Dir unumwunden Recht.

    Allerdings meine ich, daß Du den Teufel gegen einen noch größeren Beelzebuben eintauschst, wenn Du Ladungen aufintegrierst. Über die Leerlaufspannung kannst Du einigermaßen genaue Rückschlüsse auf die Kapazität ziehen (modulo Alterungsverluste). Beim Ladevorgang summiert sich ein Anfangsfehler einer ersten Kapazitätsabschätzung bei jedem Ladevorgang auf's Neue. Zudem bekommst Du weitere Unbekannte in Form des Hydrolysestroms in's Spiel. Dieser, Temperatur, der Ladezustand selbst, Ladespannung, Ladestrom und andere Effekte spielen eine Rolle, wie hoch der Ladungswirkungsgrad ausfällt.

    Ohne nähere Kenntnis des Akkuaufbaus und seines chemischen Modells bleibt Dir nur übrig, ihn hin und wieder (sicher) vollzuladen und dann über einen bekannten Lastwiderstand (der zudem nahe des Arbeitspunktes Deiner normalen Entladung liegt - siehe Peukert) zu entladen. Damit wird Alterung erkannt. Die so ermittelte Entladekurve ermöglicht Dir dann Rückschlüsse auf den Ladezustand. Die Kapazität während der Ladung zu messen, birgt erheblich höhere Ungenauigkeiten.


    Das Thema wurde unlängst in einem anderen Thread (Fake Akkus - oder so) auch schon mal aufgeworfen. Wir stand raspiprojekts Meinung, gegen die einiger anderer. Er vertrat - richtigerweise, wie ich meine - die Ansicht, es wäre der Kapazitätsbestimmung zuträglicher, einen geladenen Akku zu entladen als dessen Kapazität über einen Ladevorgang zu ermitteln.

    Im vorliegenden Fall wich der reale Kapazitätswert jedoch derart von den auf dem Akku angegebenen Werte ab, daß der Fake über beide Wege recht klar ersichtlich war. Dennoch ist die Messung über die Entladung der genauere/einfachere Weg. Am Ende interessiert einen sowieso eher, wie lange der Akku bei gegebenem Verbraucher hält. Dann kann man ihn auch mit eben jenem gegebenem Verbraucher entladen.


    Schöne Grüße


    schnasseldag

    Hallo Heimfried,

    Wahrscheinlich wird es drei Laderegler geben, vielleicht auch mehr. Die Messwerte will ich an den Ausgängen der Laderegler nehmen...

    ... und spätestens hier fällt das Kind in den Brunnen. Bei einem angeschlossenen Laderegler wirst Du ohne Kenntnis der Akkueigenschaften und des Verhältnisses Ladestrom/Ladespannung keine vernünftigen Rückschlüsse auf die Kapazität des Akkus ziehen können. Und selbst wenn Du eine derartige Meßreihe ermitteln würdest, so gilt die nur für den Augenblick und nicht den "gealterten" Akku. Letzterer lädt i.d.R. bei niedrigerem Strom/Spannungsverhältnis.

    Eine erste Näherung (ohne Betrachtung der Alterung des Akku) erhältst Du über die sich einstellende Leerlaufspannung bei abgeklemmter Last nach einiger Zeit. Zumindest bei Blei und Lipo-Akkus. Das Thema der Kapazitätsmessung unter Berücksichtigung der Alterung (und dem damit verbundenen Kapazitättsverlust) ist eigentlich nur durch eine Entlademessung möglich. Und selbst hier kommt es darauf an, wie Du entlädst (1/10C, 1C, 5C, 30C - Peukert Effekt) und welche Eigenschaften Dein Akku bauartbedingt aufweist. Ich hatte dazu vor einiger Zeit mal Meßwerte vornehmlich an einer Blei-Gitterbatterie vorgenommen (siehe >>> hier <<<).


    Gruß


    schnasseldag

    Daher suche ich zunächst Möglichkeiten, dieses Protokoll etwa so zu führen, dass die Meldungen im Arbeitsspeicher verbleiben, dann vielleicht alle 24h mir das Protokoll der 24 h per email mit Zeitstempel zugesandt wird und die Protokolldatei "geleert" wird.

    Wie fange ich das an?

    Im einfachsten Fall erstellst Du das Protokoll im tempfs oder in einer RAM-Disk. Dann mußt Du außer einer Pfadänderung nichts an Deinem Programm ändern. Es geht zwar auch anders aber ohne weitere Information zum Datenaufkommen etc. scheint mir das eine ganz pragmatische Lösung zu sein?!


    Aber... So Dein Haus nicht als Durchgangslager fungiert, würde ich jedoch auch nicht annehmen, daß Deine SD-Karte durch die Schreibvorgänge Deines Programmes stark altert. Bei 2kB/Tag (in 2k bekommt man schon einiges an Information gepackt) ist das noch nicht mal 1MB/Jahr. So "billig" ist kein Linux-Upgrade - und da fragt auch keiner nach der Alterung der SD-Karte...:)