Beiträge von Gnom

    Ich bezog mich auf Hardware-PWM. Nutzt dein Programm Hardware-PWM? Ne, gell? Und hast du mit deinem geeichten Frequenzzähler auch den Jitter gemessen oder nur einen Mittelwert?

    Und hör doch endlich mal auf, bei jeder Gelegenheit anderen ans Bein zu treten. Oder hast du das charakterlich nötig? Minderwertigkeitskomplese? Das wäre wirklich bemitleidenswert.
    Wenn du nicht weißt, woher ich meine "zusammenhanglos herauskopierten Textpassagen" habe, woher willst du dann wissen, dass sie nicht zutreffen?


    Spar dir die Antwort - ich werde sie nicht lesen!

    [...] GPIOs die Hardware-PWM beherrschen. Damit kann man [...] via des PWM Kanals ein solches Taktsignal erzeugen.

    Meines Wissens kann der Pi nur bestimmte PWM-Frequenzen erzeugen, weil sie mit Dividern aus einem Basistakt von 19,2 MHz erzeugt werden. 48 KHz ist damit nicht möglich, weil es keinen Divider von 400 gibt.


    So, allen viel Spaß und Erfolg - ich bin dann hier mal raus.

    Ist schon seltsam, keiner hat eine Lösung, also könnt ihr das nicht oder kann der RPi das nicht?

    Vielleicht liest du nur, was du lesen willst...
    Nicht nur ich hab dir deutlich gesagt, dass der Pi das nicht kann und dafür auch gar nicht gedacht ist. Und ich hab dir zwei Lösungen genannt - einen Taktgenerator und einen Mikrocontroller mit Timer-Interrupt.
    So viel zum Thema "von oben herab", "Hilfsbereitschaft", "das kann ich auch" und "keiner hat ne Lösung".

    Vielleicht hörst du mal mit dem Gemaule auf. Nur weil Du Erwartungen an den Pi hast, die der nicht erfüllen kann, musst du hier nicht die beleidigte Leberwurst spielen.

    Und das ist doch der Sinn eines RPi, er dient dazu komplexe messtechnische Dienste zu steuern.

    Das ist mir vollkommen neu!

    Wenn du schon von "professionell" redest, dann justier mal deine Weltsicht. Ich kaufe gerade ein Gerät, das 100.000 mehrfarbige Strichcodes in der Stunde auf Codewert, Position und Farbabweichungen prüft. Das ist komplexe, professionelle Messtechnik - und die ist nicht für 400 € zu haben und wird auch nicht von einem 35-€-Pi gesteuert. Dafür legst du den Gegenwert eines VW-Golf hin.

    Du willst was 100% Professionelles - für 40 €? Jaja, man ist ja bescheiden... Und du willst mit gpiozero oder ähnlichen Libraries ein stabiles 48 KHz-Signal erzeugen - auf einem SoC, der nebenbei noch ein Multiuser-Betriebssystem, Dateizufgriffe, Netzwerk, GUI, Gerätetreiber aller Art und vieles mehr steuert? Vielleicht nebenbei noch ruckelfrei 4K-Videos schauen? Halte ich für ein ziemlich aussichtsloses Ansinnen.

    Der Pi IST eine Bastelwerkzeug - als solches wurde er erfunden und als solches versteht er sich auch. Das heißt aber nicht, dass er zu schlecht ist, um auch für ernsthafte Anwendungen eingesetzt zu werden. Wenn jemand teure Messpaltinen speziell für den Pi entwickelt, wird er dafür schon einen Grund haben. Möglicherweise hat er aber nicht vorgesehen, dass seine Käufer die Samplefrequenz über den Pi ändern - sonst stünde sicher im Handbuch, wie das geht...

    Wenn es dir, so verstehe ich es zumindest, zunächst mal ausschließlich darum geht, dem Messboard über einen dafür vorgesehenen Eingang eine andere Frequenz zu geben, dann solltest du vielleicht mal nachforschen, was man für sowas benutzt, wenn man es "professionell" haben will. Einen Pi würd ich dafür jedenfalls nicht als ideal ansehen. Man öffnet ja auch keine Bierdosen mit ner Rohrzange. Jedenfalls find ich es ziemlich schäbig, hier die gesamte Pi-Community in den Dreck zu treten, nur weil DU DEIN spezielles Problem nicht lösen kannst.

    Es gibt Quarze mit 12288000 Hz, die in der Audiotechnik eingesetzt werden und mit einem Teiler von 256 genau 48000 Hz erzeugen. Es gibt auch programmiernbare Taktgeber-ICs mit verschiedenen Frequenzen. Vielleicht schaust du dich mal nach einer geeigneten Taktgeberschaltung um. Alternativ könntest du mit einem µC und einem Timer-Interrupt auch zum Ziel kommen.

    Ob es mit "auslesen, ob Spannung anliegt" getan ist, müsste man erst mal klären. Mit einem Multimeter könntest du dir da möglicherwese schon Klarheit verschaffen. Vieleicht brauchts aber auch ein Oszilloskop, um zu sehen, was da wirklich passiert. Womöglich kommt es nämlich nicht drauf an, OB Spannung anliegt, sondern WIE VIEL.
    Es wird schwierig, dir irgendwelche wirklich zielführenden Tips zu geben, so lange du keine genaueren Informationen mitteilst. Was für ein Dart-Modell ist das? Wie sieht die Platine aus? Welche Steuerchips sind da drauf? Gibts irgendwelche Schaltpläne? Detaillierte Fotos der Platine? Hast du schon mal versucht, Spannungen zu messen?

    Man kann rumspekulieren... 8 Pins pro Ziffer? Haben die Anzeigen nur 7 Segmete ohne einen Punkt, dann kann das sein. (Allerdings hab ich noch nie eine 7-Segment-Anzeige ohne Dezimalpunkt gesehen - und folglich müssten es mindestens 9 Pins sein.) Liegt tatsächlich kein Multiplexing vor, ist es möglicherweise relativ einfach, die Spannungswerte abzugreifen, weil sie dann vermutlich dauerhaft anliegen. Aber auch mit den 8/9-Pin LEDs kann man mit Multiplexing arbeiten.
    Die sieben Signale für die jeweiligen Segmete müssten aus irgendeinem Treiber-IC kommen. für 4 x 3 Ziffern wäre das ohne Multiplexing 12 (mit Multiplexing weniger) einzelne Treiber-ICs (z.B. 54/74xx4543, CD4511/4055, SN7447, 54/74xx246/247/248) oder auch 2 bis 4 Stück, die mehrere Ziffern multiplexen (z.B. ICM 7211 AM, ICM7218BIPI). Die ICs müssten ja irgendwo auf der Platine zu sehen sein. Wenn die als Eingänge BCD-Werte bekommen, könntest du die Signale dort abgreifen.

    Meine Einschätzung ist, dass das grundsätzlich geht. Wenn wirklich kein Multiplexing vorliegt oder wenn man an die Eingänge der LED-Treiber dran kommt, ist es möglicherweise sogar relativ einfach. Wenn man "gemultiplexte" Signale an den LEDs abgreifen muss, wirds etwas komplizierter - sollte aber trotzdem gehen. Je nach Art der Verschaltung und der zugänglichen Signale kann der Aufwand zwischen 84 (= 12 Ziffern x 7 Segmente) und 16 (= 4 BCD-Ziffern + 12 Multiplexleitungen) auszuwertenden Signalen liegen. (Es genügt allerdings auch, die Segmente a, b, e, f, g auszulesen, um die 10 Ziffern zu unterscheiden - also nicht 12 x 7, sondern 12 x 5 = 60)

    Abgesehen von diesen offenen technischen Details würde ich das nicht direkt mit dem Pi, sondern mit einem WLAN-fähigen Microcontroller machen und die Daten dann ggf. zur weiteren Verwendung an den Pi senden.


    Also, gib uns doch mal mehr Input.

    Wenn dein GPIO als Ausgang dient, spielen Pullup/Pulldown-Widerstände keine Rolle. Die sind nur für Eingänge relevant.

    150 Ohm ist schon recht wenig, das bedeutet 14 mA. Normalerweise belastet man die Ausgänge des Pi geringer. Ca. 390-680 Ohm wäre eigentlich eine gängige Größe, dann bist du bei 5 bis 3 mA. 20 m Kabel (hin und zurück 40) haben auch noch einen gewissen Widerstand, den sollte man ggf. einberechnen.

    Das Schalten des Optokopplers sollte eigentlich (auch bei 150 Ohm) sauber funktionieren. Wenn er nicht abschaltet, vermute ich eher einen Softwarefehler.

    Was hängt denn am Ausgang des Optokopplers dran? Vielleicht schaltet er ja korrekt und das Problem liegt dort...

    Wenn der GPIO auf High reagieren soll, dann würde ich schon fast initial den internen Pullup auf False setzen oder auf None und den active_state angeben.

    https://gpiozero.readthedocs.io/en/stable/api_…italinputdevice

    Wenn der GPIO mittels Pullup oben ist, dann reagiert der auch nicht wenn der ein High bekommt, denn damit ändert sich der Status ja nicht. Wenn der GPIO mit einem Pulldown (pull_up=False) unten ist, dann ändert sich der Status, wenn der GPIO ein High wird.

    //Edit

    Jetzt hab ich das erst kapiert! :blush:

    Hatte ich übersehen.

    Mal am Rande: Regdone hat einen Komparator, dessen Ausgang an den GPIO geht. Der Komparator zieht das Signal aktiv sowohl nach oben als auch nach unten. Der GPIO braucht also gar keinen Pull (weder up noch -down). Der kann also getrost abgeschaltet werden. Es funktioniert aber genauso mit Pullup oder auch mit Pulldown, weil der Komparator einen geringen Ausgangswiderstand hat und somit einen viel höheren Strom liefert bzw. aufnimmt, als über den Pull-Widerstand abfließt bzw. zugeführt wird.

    Du irrst! Aber lass dir das von jemandem erklären, der mehr Geduld hat als ich.
    Jedenfalls gibt es für die Überzeugung, mit der du hier deine (vorsichtig ausgedrückt) etwas eigenwillig interpretierten Sachverhalte darstellst, keinerlei Anlass.

    Meine "konsultierten Unterlagen" sind die im Internet zu findenden Fotos der Platine, auf denen die Bezeichnung des Mosfet zu erkennen ist. Ich nehme an, der dient als Verpolungsschutz.

    Dieser FDD8530 ist eine PMOS, welcher gegen Masse schaltet, und wie im Diagramm des Datasheet zu sehen bei 30A diese gerade einmal für 1 mSek ( Millisekunde ) durchleiten kann.

    Abgesehen davon, dass du einen anderen Mosfet verlinkt hast (6685 P-Channel statt 8530, welcher ein N-Channel ist) unterliegst du einem Irrtum. Die Drain-Source-Voltage ist ja nicht 12 Volt. Nur im abgeschalteten Zustand ist sie 12 V, aber da ist der Stom null. Im eingeschalteten Zustand hängt es von der Last ab. Ist der Motor stark belastet, fällt an ihm viel Spannung ab und Vgs ist sehr klein, womit der Strom hoch sein kann. Ist der Motor gering belastet, ist der Strom klein, was auch keine Probleme macht. Stromspitzen hingegen sollte der Mosfet ja vertragen.

    Auf der Platine ist nur ein weiteres Bauteil erkennbar, ein Mosfet FDD8580, 30A. Was der macht, weiß ich nicht, aber jedenfalls reicht ja einer nicht für zwei H-Brücken eines Stepperdrivers. (Nebenbei, ich hab zahlreiche Stepper-Platinen gesehen, die offenbar nur 4 Mosfets haben - man braucht doch 8, oder hab ich da was nicht kapiert?)
    Seltsam auch, dass nur zwei der vier Anschlüsse des Treiber-ICs rausgeführt sind... wo man doch üblicherweise alle vier braucht für einen Stepper.
    Die 30 A stammen aus dem Datenblatt des Treiber-ICs VNH2SP30. Und ich kann mir einfach nicht vorstellen, dass man über die dünnen Beinchen des ICs 30 A ziehen kann... Laut Datenblatt ist das aber so... Kann mir auch kaum vorstellen, dass die Platine das aushält.

    Die meinen Tatsächlich den IC auf der Platine. Ich dachte, das bezieht sich auf einen Mosfet in der Schaltung.
    Jetzt bin ich aber doch erstaunt, dass man so nen popligen IC mit 30 A betreiben kann.

    Aber trotzdem frage ich mich, wenn das Ding 30 A continous kann, was dann die Angabe "Typischer Nennstrom" bedeuten soll? Geht er bei 30 A auf Dauer doch kaputt? Im Datenblatt hab ich die 14 A nicht gefunden. Sind das die ingenieurmäßgen 100 % Sicherheitsaufschlag?

    Also ich bin kein Spezialist in OOP, aber meine Vorstellung wäre folgende:

    - Eine Klasse "Alarm", in der für jeden Alarm alle Attribute (Uhrzeit, Dauer, Anzahl Wiederholungen, Status usw...) hinterlegt sind und die entsprechenden Methoden, um all das zu verwalten. Für jeden Alarm gibts eine Instanz.
    Die Attribute würde ich als JSON oder ähnlich abspeichern um sie ggf. wieder laden zu können. Auch die Methoden dafür gehören meiner Meinung nach in die Klasse.

    - Ein Klasse "Alarmhandler", von der nur eine Instanz erzeugt wird und die alle Alarme managed. (Geht wahrscheinlich auch ganz ohne Instanz nur mit Klassenattributen.) Sollten hier überhaupt Settings nötig sein, würde ich hier ebenfalls Methoden hinterlegen, um die Daten zu speichern und zu laden.
    Der Alarmhandler könnte die Klasse "Alarm" transparent verwalten, so dass gar kein direkter Zugriff vom (Haupt)Programm auf die Methoden von "Alarm" erfolgt.

    - Eine Klasse "Audioausgabe", die die Methoden und ggf. Attribute für den Sound hat. Handling der Settings ebenso innerhalb der Klasse. Auch die Sound sollten dann vom Alarmhandler oder vielleicht noch besser vom Hauptprogramm aus gemanaged werden, nicht direkt von den Alarmen.

    Ok, dann hat man drei mal Methoden für Dateizugriffe auf Attribute oder Objektdaten und der Einfachheit halber dann womöglich auch drei getrennte Settings-Dateien... Wenn man das unbedingt umgehen will, kann man auch eine Serttings-Klasse schreiben, die die Objekte in eine Datei schreibt und liest. Dann würde ich aber im Hauptprogramm ganz am Anfang alle Objekte aus der Datei lesen und in den jeweiligen Klassen instanziieren und nicht aus den einzelnen Klassen direkt auf die Settings-Klasse zugreifen. Ich bin der Ansicht, dass man Zugriffe von Methoden einer Klasse auf Methode/Attribute anderer Klassen möglichst vermeiden sollte. Im Zweifel lieber eine Funktion im Hauptprogramm erstellen, die zwischen beiden Klassen "vermittelt".
    Wenn man aber persönlich mit kreuz und quer verlaufenden Zugriffen zwischen den Klassen leben kann, geht das natürlich auch. Ich finde aber, das ist sozusagen das OO-Pendant zum Spaghetti-Code.
    Eine extra Klasse für die Settings erscheint mir nur dann sinnvoll, wenn diese Klasse sehr stabil und universell verwendbar ist. Die paar Zeilen Code in den einzelnen Klassen, die man für JSON braucht, machen das meiner Meinung nach nicht erforderlich.

    Außerdem müssten die Programmteile, die neue Objekte (Alarme) erstellen oder Attribute ändern (auch beim Alarmhandler oder der Audioausgabe) dann auf die Settings-Klasse zugreifen und die Änderungen abspeichern. Im entsprechenden Programmteil müsste man also das Objekt erstellen/ändern und anschließend mittels Settings-Klasse die Änderungen speichern. Das ist doppelte Arbeit.
    Wenn man die Methoden in den jeweiligen Klassen hat, kann man das bei Änderungen von Attributen oder Erstellung neuer Objekte transparent innerhalb der Klassen (Alarm, Alarmhandler, Audioausgabe) abarbeiten.

    Den Zugriff aus den Klassen (Alarm, Alarmhandler, Audioausgabe) auf eine Klasse "Settings" würde ich wegen der intransparenten Abhängigkeiten jedenfalls vermeiden. Die Abhängigkeit von Alarm und Alarmhandler ist dagegen natürlich zwangsläufig - beide müssten in ein Modul gehören, das konsistent ist. Wenn man das auch noch umgehen möchte, kann man die relevanten Alarm-Attribute im Hauptprogramm an den Alarmhandler übergeben oder die Methoden des Alarmhandlers in die Klasse Alarm integrieren. Man kann ihnen beim Aufruf einzelne Alarm-Instanzen übergeben (was wiederholte Aufrufe bedingt), oder Listen von Alarm-Instanzen übergeben, z. B., um zu prüfen, ob einer der Alarmzeitpunkte erreicht ist (was ja wahrscheinlich jede Minute gemacht werden muss).


    Das sollen nur ein paar Denkanstöße sein. Bitte fangt jetzt nicht an, zu zerpflücken, was da besser oder schlechter ist. Es gibt dutzende von möglichen Ansätzen und man kann sich bestimmt die Köpfe heiß reden... Welche man nimm, hängt am Ende wahrscheinlich vor allem von den Neigungen des Programmierers ab.

    Die ganze Diskussion hier ist wieder mal unübertroffen.

    Ein offensichtlicher Voll-Laie (gar nicht böse gemeint) hat den Wunsch, etwas zu bauen, was ihn in den Augen etwas erfahrenerer User definitiv überfordern muss. Die wenigsten Beiträge hier gehen auf diesen Umstand ein. Stattdessen wird der Kandidat mit Fachbegriffen und übersteigerten Experteneinschätzungen vollgekotzt (Sorry, ein besseres Wort dafür fällt mir nicht ein). Wenn ihr es nötig habt, eure Hybris gegeneinander zu messen, dann verschont doch bitte derartige bemitleidenswerte Opfer damit. (Bin ohnehin gespannt, ob er sich noch mal meldet oder ob er schon das Handtuch geworfen hat.)

    Die einzig wirklich konstruktiven Beiträge stammen von Simonz. Ich kann mich nur anschließen und Zeyarian empfehlen, erst mal kleinere Brötchen zu backen und sich an die verschiedenen Dinge heranzutasten (Code schreiben/Programmieren generell, Sensoren abfragen, Lüfter ansteuern usw.) Für jeden dieser kleinen Schritte bekommt man Hilfe hier im Forum oder auch in vielen Youtube-Videos, Maker-Websites usw. Die einzelnen Teile zusammenzufügen, bietet sich dann als nachfolgender Schritt an. Dass eine einfache Steuerung mit zwei Sensoren und einem Lüfter oder so ähnlich am Ende nicht die Bedingungen ergeben wird, die sich Zeyarian für seinen Incubator wüscht, ist vielleicht erst mal nebensächlich. Die Hühnchen setzt man dann besser erst rein, wenn das ganze funktioniert. Bis dahin mögen dann noch einige Verbesserungen nötig sein - aber Rom wurde ja bekanntlich auch nicht in einem Tag erbaut, der Weg ist das Ziel und Erfahrung ist die Summe der gemachten Fehler.

    Ich denke, ansonsten doch auch!

    Von minus nach plus hast du glatten Durchgang (mit dem Spannungsabfall der Dioden). Wenn du bei zwei Gleichrichtern die Anschlüsse gegenläufig verbindest, funktioniert je nach Phasenlage jeweils einer der beiden wie ein Stück Draht zwischen plus und minus des jeweils anderen Gleichrichters. Das würde meiner bescheidenen Einschätzung nach eine lustige Rauchwolke verursachen - aber nicht den Motor antreiben. Ob dabei beide Gleichrichter mit L und/oder N verbunden sind, spielt erst mal keine Rolle.

    Sollte ich mich irren, dann mach ich einen höflichen Knicks und lass dich gerne weiterarbeiten. Falls aber nicht, solltest du vielleicht generell die Finger von all diesen Sachen lassen. Ich will dir ungern zu nahe treten, aber ich fürchte, du hast hinreichend mangelnde Ahnung von dem, was du da tust und läufst Gefahr, dich umzubringen. Ich bin echt nicht zimperlich, aber bei 230 V an einer amateurhaft zusammengepfriemelten Gleichrichterschaltung hört er Spaß wirklich endgültig auf!

    und nur weil (noch) kein Tempolimit eingeführt worden ist auf den Autobahnen, deswegen willst du die Maßnahmen bei der Brandbekämpfung wieder abschaffen? :/

    Das hab ich mit keinem Wort gesagt... im Gegenteil! Aber wer nur lesen kann, was er lesen will, liest nie das, was geschrieben wurde. Es wird seinen Grund haben, warum du glaubst, meinen Beitrag angreifen zu müssen.

    Also, ich finds richtig gut, dass man hier ab und zu mal ganz knallhart gesagt bekommt, wie blöd man ist. Von Leuten, die nicht blöd sind. Ach, was sag ich... von Leuten, die über jeden Zweifel erhaben sind. Götter der Unfehlbarkeit sozusagen.
    Rasp-Berlin, hör doch bitte auf, so pikiert rumzumaulen. Du erzürnst womöglich die Götter und stürzt das Forum ins Unglück.
    Und merkt dir: Leute, bei denen es piept, rufen besser sofort die Feuerwehr!