Posts by Gnom

    Wenn die Spannung nicht ausreicht, um dem GPIO ein High-Signal zu geben, kannst du mit dieser Schaltung eigentlich keinen Blumentopf gewinnen. Reicht die Spannung nicht, dann bringt dir auch ein kleinerer Widerstand (z. B. 500 statt 1000 Ohm) nichts.

    Du könntest mit dem Phototransistor einen zusätzlichen Transistor schalten, der dann den GPIO ansteuert. Oder du suchst dir einen empfindlicheren Phototransistor.

    Kannst du die Zuleitung nicht direkt an den Pads anlöten, wo dir der Anschluss abgerissen ist - sofern die Leiterbahnen nicht beschädigt sind?

    Evtl auch "einfach" eine neue Buchse auflöten. Braucht natürlich das passende Werkzeug und eine ruhige Hand. Die USB-Buchse ist ja selbst sehr hitzebeständig (wenn nicht irgendwas aus Plastik drin ist). Wenn du die auf verzinnte Pads aufsetzt und ordentlich heiß machst, könnte das doch klappen. Lötpaste und Heißluftfön zu kaufen, wird sich kaum lohnen, da ist ein neuer Pi billiger.

    In welchem Schrittmodus betreibst du die Motoren? Der Treiber kann offenbar bist zu 1/64-Schritte - da sollte der Motor nicht mehr so laut sein.

    Ansonsten brauchst du einen anderen Treiber. Nema17 ist ja ein recht kleiner Motor. Eine einfache H-Brücke für jeden Motor müsste eigentlich reichen, sowas auf Basis des L293D-Chips. Die Geschwindigkeit kannst du dann über PWM steuern.

    Bist du sicher, dass ein Pi die richtige Basis ist für ein Beatmungsgerät? Könnte durchaus sein, dass der Patient mal drei Minuten keine Luft bekommt, wenn das System sich wegen Update herunterfährt oder wegen eines Treiberfehlers aufhängt.

    Wie aufwändig ist das, was das Ding am Ende machen soll? Die Motoren steuern, ein paar Knöpfchen zum Einstellen, ein kleines LCD, ...? Genügt da nicht ein Mikrocontroller, der viel robuster und zuverlässiger ist? Ich würde mich nicht an ein Beatmungsgerät mit Pi-Steuerung hängen lassen.

    Dann benutzt er wahrscheinlich eine andere Library in der D7 definiert ist. Ich hab bisher immer die Pinnummern angegeben. War mir nicht bekannt, dass es auch Libs gibt, die D7 und sowas definiert haben. Aber ist natürlich komfortabel.

    Franjo, welche Lib benutzt du denn und welchen Boardtyp hast du eingestellt?

    Köstlich!!! :lol:

    Möchtest du damit sagen, dass wir alle ab sofort ungerügt andere Forenmitglieder als Vollidioten beschimpfen dürfen? (Zum Beispiel solche mit 10 Jahren Erfahrung in Automatisierungstechnik, die behaupten, ein Motor zöge mehr Strom, wenn man die Spannung senkt.) Das würde hier wirklich frischen Wind reinbringen. Oder gilt die Beleidigungsfreiheit nur für bestimmte Forenmitglieder? Kann man bei dir einen Antrag stellen, um in den Genuss derartiger Privilegien zu kommen? :bussi2:

    [...] Ich weiß, wie man Antriebe synchronisiert und ich muss mich von so einem Vollidioten wie dir nicht anpissen lassen.

    Meine Frage war, wie man Antriebe synchronisiert... Wenn du weißt, wie es geht, warum schlägst du dann vor, das Band anzuhalten und auf die Synchronisation zu verzichten, statt mir zu sagen, wie es geht.

    Danke für den Vollidioten. Wem keine Argumente mehr einfallen, der wird ausfällig.

    Ich habe ca. 20 Jahre Berufserfahrung im Bereich Automatisierungstechnik, 10 Jahre mit Industrierobotern und 10 Jahre mit didaktische Systemen.

    Wenn ich den Vorschlag mache eine Alternative zu verwenden, um auf die Synchronisation zu verzichten, hat das schon seinen Hintergrund.


    Aber gut, da du ja nicht nur alles besser weißt, sondern auch besser kannst, dann mach mal.

    Viel Erfolg.

    Du platzt hier rein, machst einen vollkommen untauglichen Vorschlag und hältst dich noch für den Experten vor dem Herrn? Deine Hybris ist bemerkenswert. Die Industrieroboter möchte ich mal sehen, die du in 10 Jahren "erfahren" hast. Jeder poplige Greifarm muss Antriebe synchronisieren. Nur deine drehen offenbar jede Achse einzeln nacheinander und die Fließbänder verharren derweil brav im Stillstand. Du hast 20 Jahre Erfahrung mit Automatisierungstechnik, Industrierobotern und didaktischen Systemen? Tolle Formulierung für: "Ich gebe Fischertechnikkurse in der Volkshochschule."

    Wenn du was hast, dann keine Ahnung von nichts!

    Ich frage, wie man zwei Bewegungen synchronisiert und du erzählst mir, dass ich auf die Synchronisation einfach verzichten soll und die Maschine dann eben langsamger läuft...

    1.) Hunderttausende Maschinen in aller Welt arbeiten mit synchronen Bewegungen. Ich hatte ja gehofft, dass irgendjemand hier das Grundprinzip hinter diesen Systemen kennt. Offenbar ist das nicht der Fall.

    2.) Der Sinn einer Maschine ist es nicht, möglichst langsam zu laufen, um die Konstruktion zu vereinfachen.

    3.) Dein Vorschlag ist genau das Gegenteil dessen, was ich erwarte, wenn ich hier meine Frage stelle.



    Wie backe ich eine Schweizer Nusstorte?

    Schmier dir doch ein Butterbrot, das ist einfacher!

    Man fragt sich echt, warum die Monitorhersteller nicht einfach mal einen 3-A-USB-Ladeanschluss rausführen - den hätte doch jeder Handybesitzer gerne am Monitor...


    Ich hab ne Steckerleiste mit Schalter unterm Tisch - damit kann ich Monitor und USB-Schaltnetzteil für den Pi (und ggf. auch Drucker und anderen Schnickschnack) mit einem Klick ein-/ausschalten. Und Stromverbauch für Standby fällt auch weg.

    Er sate nicht "hart" Abschalten. Nur "zusammen" abschalten. Das schließt nicht aus, dass er ihn vorher ordentlich runterfährt.


    USB hat nur begrenzten Strom. und so weit ich weiß, handeln die Anschlüsse den maximalen Strom irgendwie aus.

    Höhere Standards bieten mehr Strom. Wenn du mal unter USB in Wikipedia schaust, da findest du was dazu. USB-BC klingt interessant. Da wird dem Gerät wohl über kurzgeschlossene Datenadern mitgeteilt, dass der Strom zum Baterieladen verwendet wird. So werden 1,5 A / 7,5 W bereitgestellt. Ich finde das alles aber intransparent. Wichtig ist wohl vor allem erst mal, welche Standards der Anschluss an deinem Monitor erfüllt. Wenn das ein USB-1.0 -Anschluss ist, komtm der nicht über 100 mA.

    Wenn du einen geeigneten Anschluss hast, ist die Frage, wie man ihn so mit dem Pi verbindet, dass er auch die nötige Leistung ausspuckt.


    Vielleicht kann dir der Monitorhersteller was dazu sagen.

    Die genannte Lichtschranke bestimmt weniger die räumliche Position, sondern, ob das Teil richtigrum oder gedreht liegt. Wo es liegt, ist klar. Wie es liegt, ist die Frage. Möglicherweise nutze ich dafür auch OpenCV - es gibt Teile, die bedruckt sind und bei denen deshalb die Richtung, wie sie liegen, relevant ist.

    Vielleicht rühre ich ja auch in der falschen Ecke rum, aber wie wäre es mit Drehzahlen messen und angleichen?

    Das erscheint mir ebenfalls zu ungenau und zu aufwändig. Da müsste ich ja sozusagen jedem Motor einen Regelkreis mitgeben. Und das löst immer noch nicht das Problem, dass die Bewegungen ja nicht identisch sind, sondern nur synchron ablaufen. Wenn das Band an Position X ist, soll das Anheben beginnen. Bei Position Y soll das Teil um 90° aufgerichtet sein. Der Hebel, der das Teil hochgehoben hat, muss wieder in Ausgangsstellung sein, wenn das Band Position Z erreicht hat.

    Die Bestimmung der Positionen des Hebels könnte man rechnerisch machen, aber das würde bedeuten, dass man für jeden Schritt des Bandmotors eine Berechnung machen muss. Um die Bewegungen halbwegs fließend zu halten, kann man auch nicht einfach nur jeden 20. Schritt berechnen und synchronisieren. Das würde also viel Rechenzeit kosten.

    Meine einzige Idee bisher ist deshalb, die Bewegung des abhängigen Motors einmal zu berechnen und in einer Tabelle (Array) den Schritten des Hauptmotors zuzuordnen. Dann müsste das Programm nur nach jedem Schritt des Hauptmotors die Werte aller Nebenmotoren aus der Tabelle lesen und die Motoren entsprechend ansteuern.

    Es gibt keine Lichtschranke. Die Position der Teile ist jederzeit bekannt, weil das Band (wie schon gesagt) Mitnehmer hat, die Teile also an definierten Stellen liegen. Es geht nicht darum, wann oder wie sich die Antriebe bewegen, sondern, wie man sie synchron kriegt.

    Wenn ich den Hauptmotor und die anderen jeweils über PWM-Signale steuern würde, hätte ich keine Gewähr, dass die immer synchron bleiben. Die Frequenzen sind unterschiedlich, das EIn- und Ausschalten erfolgt mit leichtem Versatz und das alles kann sich aufsummieren. Deshalb ist die Frage, wie man die Bewegunge eines Motors mit einem anderen synchronisiert.

    Danke für deine Hilfe, Bernd, aber ich weiß, wo das Problem liegt - und zwar genau dort nicht, wo du rumrührst. Wo die Pakete liegen und wie sie gedreht werden ist nicht das Thema.

    Es geht nur darum, wie man software-/hardware-/programmtechnisch die Bewegung eines zweiten Motors mit einem ersten synchronisiert, wenn die Bewegung des ersten Motors variabel ist.

    Dann kannst du auch nicht einfach einen Stab nehmen und die Pakete "umwerfen". Sie liegen am Mitnehmer.

    Also greifen, anheben, drehen und ablegen. Dazu muss der Aktor wohl mit dem Band fahren und abschließend zurück in seine Ausgangsposition fahren.

    Wenn das Teil auf dem Rücken liegt, bleibt der folgende Abschnitt frei. Somit klappt das mit dem Umwerfen.

    Man kann das Teil beim Drehen auch außerhalb der Mitte greifen, so dass es nach dem Drehen weiter in Fahrtrichtung des Bandes zu liegen kommt.


    Aber auch das ist alles nicht meine Frage. Es geht mir darum, wie ich die Ansteuerung der Motoren aufeinander abstimme. Macht euch um die Bewegungen an sich keine Köpfe - darum geht es gar nicht.

    Wenn das Band schneller läuft oder die Rampen und die Maximalgeschwindigkeit oder die Bewegungs- und Stillstandszeiten sich ändern (auch im Verhältnis zueinander), dann müssen alle anderen Antriebsbewegungen ggf. entsprechend anders ablaufen. Die Frage ist, wie man sowas (programmtechnisch oder sonst irgendwie) löst. Das ist ja in der Automation sicher eine alltägliche Aufgabe. Ich hab gesehen, dass SPS und Profiantriebe solche Sync-Funktionen integriert haben. Aber mit Pi oder Arduino sieht das anders aus. Was steckt (software)technisch hinter diesen Synchronisierungsmechanismen?

    Die Teile leigen alle längs. Aber die Lage (vorne/hinten) ist wichtig. Ein Sensor kann das leicht erkennen und die Dinger sollen dann um 180° gedreht werden. Derjenige, der die aufs Band legt, soll sich darum keinen Kopf machen müssen. Und wenn mal eins falsch liegt, soll es nicht zum Stopper kommen, deshalb die Drehung.

    Das Band hat in regelmäßigen Abständen Mitnehmer, die die Teile vor sich her schieben. Das Band ist also in feste Abschnitte geteilt und in jedem liegt ein Teil - die Teile können also nicht irgendwo hin gelegt werden und freie Stellen gibt es nicht.


    Aber auch das ist eigentlich nicht das Problem. Es geht um die Synchronisierung der Positionen von Band und anderen Antrieben. Wenn du schneller um de Kurve fährst, musst du auch das Lenkrad schneller drehen. Und du musst es auch im richtigen Moment zu drehen beginnen. Da kommt man mit Zeit nicht weit - du kannst nicht sagen, wenn ich an der Ampel losfahre, muss ich 5,8 Sekunden später das Lenkrad drehen, um in die Seitenstraße einzubiegen. Wenn du schneller fährst, stehst du nach 5,8 Sekunden schon auf der anderen Seite der Kreuzung. Wenn du langsamer fährst, krachst du nach 5,8 Sekunden in ein Schaufenster. Man muss wohl eher die genaue Position wissen, an der man ist.

    Fürs Band heißt das, ist muss wissen, an welcher Psoition das Band ist. Und die anderen Antriebe müssen sich synchron zum Ort des Bandes bewegen. Nur ist das rechnerisch wahrscheinlich ziemlich aufwändig, bei 800 Bandmotorschritten für jeden Schritt ich Echtzeit die Position von 5-10 anderen Motoren zu berechnen und anzusteuern. Mit einer Tabelle, die ich einmal berechne, geht das vielleicht besser.