Hallo Zusammen, ich habe einen 3D Drucker (Ultimaker 2) und möchte daran einige Modifikationen machen. Wenn man das System vereinfacht, besteht es soweit ich es verstanden habe aus: - 3 Motoren (Aktoren) - 1 Endanschlag (Sensor) - 1 Temperaturerfassung des Extruders (Sensor) - 1 Ansteuerung - 1 Leistungselektronik Nun will ich jeden Sensor sowie Aktor "intelligent machen" um so einfacher einen Motor bzw. einen neuen Sensor einzusetzen ohne permanent diese komponenten hart anpassen zu müssen. Was als Schritt zwei ein abgespecktes Design der Leistungselektronik zur Folge haben wird, da jedes Modul als einzelnes voll funktionsfähig über einen Bus sein soll. Das Bedeutet: Der Motor ist aktuell hart verkabelt mit der Leistungselektronik-Platine. Im 1.ten Schritt: Ich nehme den Motor + dazugehörige Leistungselektronik (Allegro Treiberbaustein) + Mikrocontroller (vorzugsweise Arduino da riesen Community) und verbinde dieses "Modul" mit der Steuerplatine, die auch mit einem Arduino bestückt, auf dem Bus die Richtung und die Schrittweite für den Motor in Form eines Datenpaketes angibt. Sodass z.B. der Motor nur eine 12V Versorgung und den Bus als Anschluss hat. Bei den Sensoren das gleiche: 12V bzw. 5V Versorgung und ein Bussignal an dem der Sensor anliegt, ich bin gerade so heiß. D.h. ein Bus mit 12V, 5V, Datenleitung wird verlegt und alle Aktoren/Sensoren werden daran angeschlossen. Das Ganze soll mir dienen einzelne Komponenten anhand meines Druckers auszutesten, wie z.B. den mechanischen Endanschlag durch einen induktiven Endanschlag zu ersetzen und den Motor durch einen stärkeren / schwächeren, falls ich anstatt Drucken auch mal Fräsen will. Es soll quasi eine Spielwiese von Aktoren und Sensoren anhand meines X-Y-Z-Druck-Systems erfolgen. Nun die konkrete Frage: Ich willzu Beginn 5 Arduinos zu einem Bus verbinden und den Raspberry Pi als Steuerplatine verwenden und das ganze erstmal auf dem Tisch ohne Sensoren und Aktoren testen. Welchen Bus würdet Ihr mir hierzu empfehlen? Es sollte irgendwas sein, welcher auf 1m Distanz zu einem anderen "Modul" kommunizieren kann. CAN ist der Nachteil, dass die schwachbrüstigen Elektroniken (Arduino) nicht von Haus aus CAN können -> d.h. entweder ich weiche von der Community mit viel Support ab und neehme einen speziellen Controller oder ich bastel CAN über SPI oder I2C dran, was ich als erste Lösung nicht sehr elegant finde. SPI und I2C sind auch nicht wirklich für "lange Wege" geeignet. Von der Busstruktur wäre es Sternförmig, da alle Module an die Steuerung berichten. Ich steh gerade mit der Auswahl: günstige Elektronik mit großer Community und überschaubaren Bus etwas auf dem Schlauch. Vielleicht kann mir der ein oder andere von euch helfen. Vielen Dank Darvin
Irgendwie muss ich bei so was immer denken: Wer hier bei einem solch doch recht ambitionierten Projekt, derart allgemeinen Quatsch fragen muss, kann es einfach nicht umsetzen und sollte es lassen.
Irgendwie muss ich bei so was immer denken: Wer hier bei solch doch recht einfachen Fragen, derart allgemeinen Quatsch rauslassen muss, sollte es einfach lassen. Kleiner Spass, aber du weisst was ich damit sagen möchte.
Wie gesagt, ich habe versucht möglichst viel Background mitzuliefern und versuche das Problem Schritt für Schritt anzugehen. Bei der Auswahl des richtigen Datenbusses stehe ich etwas auf dem Schlauch. Ich würde mir gerne eine Art Matrix erstellen um anhand meinen Anforderungen den richtigen Bus auszusuchen.. genau das ist für mich gerade nicht greifbar wo ich ansetzen soll/muss.
Darvin D. schrieb: > Ich nehme den Motor + dazugehörige Leistungselektronik (Allegro > Treiberbaustein) + Mikrocontroller (vorzugsweise Arduino da riesen > Community) und verbinde dieses "Modul" mit der Steuerplatine, die auch > mit einem Arduino bestückt, auf dem Bus die Richtung und die > Schrittweite für den Motor in Form eines Datenpaketes angibt. > > Sodass z.B. der Motor nur eine 12V Versorgung und den Bus als Anschluss > hat. Das Problem bei solchen Systemen ist, daß die Teile zeitscharf, schrittgenau mit einander arbeiten müssen. Da wird das mit einem Bus recht anspruchsvoll. MfG Klaus
Operator S. schrieb: > Irgendwie muss ich bei so was immer denken: Wer hier bei solch > doch recht einfachen Fragen, derart allgemeinen Quatsch rauslassen > muss, sollte es einfach lassen. > > Kleiner Spass, aber du weisst was ich damit sagen möchte. Na dann hilf dem TE doch einfach. Das Problem: Der Datenbus ist nicht das Problem des TE. Bei 1m kann man so ziemlich alles nehmen. I2C geht, SPI geht, RS232, RS485, CAN, Ethernet was man will. Aber DANN fangen die Probleme doch erst an. DANN kommt das Protokoll. Und danach die "Intelligenz" in den einzelnen Modulen. Wer hier aber schon so rumeiert bevor er überhaupt angefangen hat, und wenn ich dann noch Arduino höre (und raushöre dass damit wenig Erfahrung vorhanden ist), dann weiß ich dass da Hopfen und Malz verloren sind. Die Frage nach dem Bus ist eigentlich die einzige die sich nicht stellt. > Das Problem bei solchen Systemen ist, daß die Teile zeitscharf, > schrittgenau mit einander arbeiten müssen. Da wird das mit einem Bus > recht anspruchsvoll. Darum gibt es IRT bei einigen Feldbussen. Also eine zeitliche Deterministik bis zu den IOs. Ein Arduino-Nutzer sollte mit so was viel Spaß haben.
:
Bearbeitet durch User
Hallo, Das hilft mir schonmal weiter mein Problem einzugrenzen/ zu verstehen. Danke. Was sind denn die Stichwörter wonach ich den uC aussuchen soll. Arduino sollte als Platzhalter für ein uC mit großer Community stehen. Dadurch, dass mein Vorhaben kniffelig ist will ich von vornherein nicht auf ein Nischenprodukt setzen, wo der Hauptteil meiner Arbeit nach dem Suchen von Support besteht. Zeitkritisch wäre nur die anstuerung von X-Z-Achsen Motoren. Die Y-Achse (bewegt sich einmal kurz nach unten und der Druck in der X-Z-Ebene geht weiter). Und die Sensoren (Endanschlag und Temperatur) werden am Start benötigt und während des Drucks eigentlich nicht ausgelesen. Wenn ich sie auslesen würde dann als nicht zeitkritische Info auf die reagiert werden kann/soll. D.h. das zeitkritische spielt sich nur an den zwei Motoren ab sehe ich das richtig? Darauf ist ein Bus auszulegen? Viele Grüße Darvin
Darvin D. schrieb: > Was sind denn die Stichwörter wonach ich den uC aussuchen soll. > Arduino sollte als Platzhalter für ein uC mit großer Community stehen. Genau das meine ich. Mit was hast du denn bisher gearbeitet? So was geht nicht von null auf hundert. Ich hoffe du hast schon einige Controllerprojekte abgeschlossen. > Zeitkritisch wäre nur die anstuerung von X-Z-Achsen Motoren. > Die Y-Achse (bewegt sich einmal kurz nach unten und der Druck in der > X-Z-Ebene geht weiter). Ich dachte die Z-Achse ist solchen Drucker die Achse die "nach unten" gehen kann. Also die Höhe des Druckkopfes. Oder hast du ein anderes Koordinatensystem? > > D.h. das zeitkritische spielt sich nur an den zwei Motoren ab sehe ich > das richtig? > Darauf ist ein Bus auszulegen? Nun du sprichst von einem modularen flexiblen System. Also musst du den Bus auf alle Eventualitäten also eben allgemein auslegen. Du brauchst ein allgemeines Konzept um zeitkritische Informationen zu übertragen. Dazu kann man auch die Schritte vor ab übertragen und auf ein Startsignal (per Broadcast) führen alle Baugruppen diese Befehle selbständig aus. Man kann sich an den Motion Modulen für Feldbusse orientieren. Du willst ja dezentrale intelligente Module. Also müssen die natürlich Teilaufgaben autonom lösen, sonst bräuchtest du das alles ja nicht.
:
Bearbeitet durch User
Darvin D. schrieb: > Nun will ich jeden Sensor sowie Aktor "intelligent machen" um so > einfacher einen Motor bzw. einen neuen Sensor einzusetzen ohne permanent > diese komponenten hart anpassen zu müssen. Was heisst denn für dich "hart anpassen"? Ein einzelner Raspi soll an sich schon reichen um dein Drucker anzusteuern. Da brauchst du wirklich keine separate Arduinos für jeden Sensor und Aktuator. Das macht das Ganze nur komplexer, nicht einfacher. Sinnvoller ist die Software für den Raspi so modular zu gestalten, dass die Softwareteile, die einen bestimmen Sensor oder Aktuator ansprechen, einfach austauschbar oder konfigurierbar sind.
Cyblord -. schrieb: > Darvin D. schrieb: >> Was sind denn die Stichwörter wonach ich den uC aussuchen soll. >> Arduino sollte als Platzhalter für ein uC mit großer Community stehen. > > Genau das meine ich. Mit was hast du denn bisher gearbeitet? So was geht > nicht von null auf hundert. Ich hoffe du hast schon einige > Controllerprojekte abgeschlossen. > Ja habe ich, bi gerade in einem Elektrotechnik Studium. >> Zeitkritisch wäre nur die anstuerung von X-Z-Achsen Motoren. >> Die Y-Achse (bewegt sich einmal kurz nach unten und der Druck in der >> X-Z-Ebene geht weiter). > Ich dachte die Z-Achse ist solchen Drucker die Achse die "nach unten" > gehen kann. Also die Höhe des Druckkopfes. Oder hast du ein anderes > Koordinatensystem? > Ok, das ist eine Koordinaten-System Frage: Bei den Druckern ist tatsächlich die Z-Achse die Achse die nach unten führt und die ich mit der y-achse meine. Ich habe das Koordinatensystem anders bezeichnet, da Standardmäßig Y hoch runter zeigt. Aber bleiben wir bei der gewohnten X-Y-Ebene = Druckerebene Z-Ebene = Hoch runter >> >> D.h. das zeitkritische spielt sich nur an den zwei Motoren ab sehe ich >> das richtig? >> Darauf ist ein Bus auszulegen? > > Nun du sprichst von einem modularen flexiblen System. Also musst du den > Bus auf alle Eventualitäten also eben allgemein auslegen. Du brauchst > ein allgemeines Konzept um zeitkritische Informationen zu übertragen. > Dazu kann man auch die Schritte vor ab übertragen und auf ein > Startsignal (per Broadcast) führen alle Baugruppen diese Befehle > selbständig aus. > Man kann sich an den Motion Modulen für Feldbusse orientieren. > Das ist ein sehr wichtiger Punkt! Eigentlich kenne ich ja jeden Schritt bis zum Ende, weil das Modell schon davor berechnet wird und nur die X-Y-Z-Koordinaten übertragen werden. Danke dass du das nochmal angesprochen hast.
:
Bearbeitet durch User
beric schrieb: > Darvin D. schrieb: >> Nun will ich jeden Sensor sowie Aktor "intelligent machen" um so >> einfacher einen Motor bzw. einen neuen Sensor einzusetzen ohne permanent >> diese komponenten hart anpassen zu müssen. > > Was heisst denn für dich "hart anpassen"? > Hart anpassen = hart verkabeln. Ich will mir jetzt den Aufwand machen den Drucker modular zu gestalten, damit ich mich nachher ausschließlich auf eine modulare Komponente konzentrieren kann, die dann an den Bus angeschlossen wird und sich für das restliche System nicht anders verhält wie die davorgehende. Sodass ich vorerst nichts an der SW anpassen muss. Bsp. Sensor: Aktuell ist ein Endlagensensor dran, der eben noch ausgewertet werden muss und danach erkannt wird, ob etwas anliegt oder nicht. Bringe ich jetzt die Auswerteelektronik räumlich zu dem Sensor hin und setzte danach einen uC hin der nur sagt Anschlag Ja/Nein kann ich diesen Sensor beliebig ersetzen, ohne dass ich irgend etwas an der SW, bzw, an der Auswertehardware im System selbst ändern muss. > Ein einzelner Raspi soll an sich schon reichen um dein Drucker > anzusteuern. Da brauchst du wirklich keine separate Arduinos für jeden > Sensor und Aktuator. Das macht das Ganze nur komplexer, nicht einfacher. > > Sinnvoller ist die Software für den Raspi so modular zu gestalten, dass > die Softwareteile, die einen bestimmen Sensor oder Aktuator ansprechen, > einfach austauschbar oder konfigurierbar sind. Das wäre der zweite Schritt, die SW modular anzupassen, sodass wenn ich meinen Druckraum vergrößern will ich drei strärkere Motoren einbinde und im system eine Variable ändere und der Drucker fährt weiter als er es bis jetzt tut. Aber erst einmal alles so belassen udn die komponenten ersetzen. Viele Grüße Darvin
Darvin D. schrieb: > Ich will mir jetzt den Aufwand machen den Drucker modular zu gestalten, > damit ich mich nachher ausschließlich auf eine modulare Komponente > konzentrieren kann, die dann an den Bus angeschlossen wird und sich für > das restliche System nicht anders verhält wie die davorgehende. Sodass > ich vorerst nichts an der SW anpassen muss. Du wirst aber Software anpassen müssen. Nämlich die SW in deiner "Komponente" die den Sensor ausliest und dessen Wert(e) auf dem Bus legt.Und dann ist es Wurscht ob das in der SW am zentralen Raspi ist oder in deiner Komponente.
Es gibt aber einen Unterschied: Anhand meines Sensor Bsp. Ein Sensor benötigt Zusatzelektronik damit dieser z.B. am ADC eingelesen werden kann. Der Andere eben keine weil er vielleicht schon digital ist. Das Bedeutet, bei einer zentralen Komponente wie dem PI, müsste ich bei Änderung eines Sensors, der eine andere Technologie besitzt: Sowohl die SW im PI als auch die HW verkabelung im System anpassen und evtl auch eine andere Spannung verlegen. Und zwar jedes Mal wenn sich ein Sensor in seiner Technologie mit dem gleichen Aufgabenbereich ändert. Das umgehe ich indem ich den Sensor und Aktor nach außen immer die selbe Schnittstelle gebe und Sensor/Aktorintern die Anpassung mache. Z.B. immer 12V hinführe und intern im Modul über einen DCDC Wandler die benötigte Spannnung generiere. Ich kann mich also nur auf die Komponente begrenzen und muss nicht immer das ganze System anfassen. Aber unterm Strich gebe ich dir recht ist es das gleiche. Aber anders umgesetzt. Ich könnte auch im ersten Schritt damit leben, dass ich nur die Sensorik (Endanschlag, Plattenbeheizung und Extruderheizung) modularisiere und in einem zweiten Schritt mich an die zeitkritischen Motoren rantraue. Dazu müsste ich aber jetzt schon wissen auf welchen Bus ich setzen muss. Das will ich eben vorab nachhaltig klären und deshalb dieser Thread. Danke um jede Hilfe
Das wird nicht so einfach machbar sein.
Jeder Antrieb hat zum Beispiel ein anderes Timing-Verhalten. Du kannst
nicht einfach einen kleinen Motor durch einen großen ersetzen, ohne die
zentrale Steuerung anzupassen.
Jeder Sensor hat einen anderen Erfassungsbereich und Auflösung. Der eine
Sensor liefert zum Beispiel eine Distanz als analoge SPannung. Der
andere liefert eine Distanz in 1mm Schritten. Und der dritte liefert die
Distanz in nicht linearer Form.
All diese Unterschiede muss die zentrale Steuerung berücksichtigen. Denn
der Drucker soll ja auch mit angemessenem Tempo arbeiten.
Wenn das alles so einfach wären, dann würden unsere KFZ Hersteller schon
lange ihre Fahrzeuge nach dem Baukasten-Modell zusammenstecken.
> Dazu müsste ich aber jetzt schon wissen auf welchen Bus ich setzen muss.
Das ist vollkommen egal. Mach Dir eher Gedanken zur
Zeit-Synchronisation. Man kann bei jedem noch so unpassendem Bus für
Synchrone Zeit sorgen - NTP beweist es.
>Wenn das alles so einfach wären, dann würden unsere KFZ Hersteller schon >lange ihre Fahrzeuge nach dem Baukasten-Modell zusammenstecken. Es geht so einfach. Softwaremodule liefern normierte Signale ab und gut. So kannst du die Softwaremodule austauschen.
Stefan U. schrieb: > Das wird nicht so einfach machbar sein. > > Jeder Antrieb hat zum Beispiel ein anderes Timing-Verhalten. Du kannst > nicht einfach einen kleinen Motor durch einen großen ersetzen, ohne die > zentrale Steuerung anzupassen. Natürlich geht das. Darum geht's ja. Du sagst der Motoreinheit WAS sie tun soll. Das WIE entscheidet sie selber. Darum ist sie ja dann Austauschbar. > > Jeder Sensor hat einen anderen Erfassungsbereich und Auflösung. Der eine > Sensor liefert zum Beispiel eine Distanz als analoge SPannung. Der > andere liefert eine Distanz in 1mm Schritten. Und der dritte liefert die > Distanz in nicht linearer Form. Siehe oben. Ich will von dem Sensor nur den Abstand wissen. WIE er den bekommt ist sein Problem. Darum Intelligent. Deshalb kann man Sensoreinheiten austauschen. Die zentrale Steuerung will eben die Details nicht wissen. Das nennt man übrigens Abstraktion.
:
Bearbeitet durch User
> Softwaremodule liefern normierte Signale ab und gut.
Nein, so einfach ist das eben nicht. Stell Dir mal vor, deine Normierung
sieht so aus, dass eine Dinstanz in Millimetern ausgegeben wird. Und
dann hast du einen Sensor, der nur im 3,58mm Raster messen kann. Wie
normierst du dessen Wert? Dein Ergebnis wird nicht nur Sprünge >1mm
ausweisen, sondern auch Abweichungen vom realen Wert. Dennoch kann
dieser Sensor unter umständen genauer sein oder besser geeignet sein,
als ein Sensor, der exakte 1mm Raster misst.
Und bei den Antrieben wird es noch schwieriger. Der eine Motor kann zum
Beispiel die Druck-Düse auf ein tausendstel Millimeter genau
positionieren, aber ist sehr langsam.
Der andere Motor kann gar nicht an bestimmten Stellen gestoppt werden,
aber ist imstande, die Druckdüse sehr schnell genau berechenbar über
einen bestimmten Bereich hinweg zu bewegen (Machen übrigens viele
Drucker so).
Die iddee, alles mit 12V zu Betrieben, halte ich auch für Quatsch. Was
ist, wenn ich mit diesem System eine große Statue drucken will, was
Motoren mit einigen hundert Watt Leistung erfordert? Da wären 12V eher
ein Ärgerniss.
Stefan U. schrieb: >> Softwaremodule liefern normierte Signale ab und gut. > > Nein, so einfach ist das eben nicht. Stell Dir mal vor, deine Normierung > sieht so aus, dass eine Dinstanz in Millimetern ausgegeben wird. Und > dann hast du einen Sensor, der nur im 3,58mm Raster messen kann. Wie > normierst du dessen Wert? Entweder Runden oder Fehlerausgabe. > Dein Ergebnis wird nicht nur Sprünge >1mm > ausweisen, sondern auch Abweichungen vom realen Wert. Dennoch kann > dieser Sensor unter umständen genauer sein oder besser geeignet sein, > als ein Sensor, der exakte 1mm Raster misst. Na und? Der Sensor kann seine Daten vorher bekannt machen. Die zentrale Steuerung entscheidet dann ob die Werte ausreichen oder nicht. > Und bei den Antrieben wird es noch schwieriger. Der eine Motor kann zum > Beispiel die Druck-Düse auf ein tausendstel Millimeter genau > positionieren, aber ist sehr langsam. > > Der andere Motor kann gar nicht an bestimmten Stellen gestoppt werden, > aber ist imstande, die Druckdüse sehr schnell genau berechenbar über > einen bestimmten Bereich hinweg zu bewegen (Machen übrigens viele > Drucker so). Alles eine Frage des Interfaces. Was sage ich dem Motor? Was will ich? Je abstrakter der Befehl, desto allgemeiner kann die Umsetzung sein. > Die iddee, alles mit 12V zu Betrieben, halte ich auch für Quatsch. Was > ist, wenn ich mit diesem System eine große Statue drucken will, was > Motoren mit einigen hundert Watt Leistung erfordert? Da wären 12V eher > ein Ärgerniss. Bisschen Konstruiert alles. Deine Einwände finde ich nicht stichhaltig.
Hallo Zusammen, danke für den guten Input. Was das Anliegen bezüglich der unterschiedlicher Sensoren / Aktoren angeht: Es geht hier immernoch um ein geschlossenes System bestehend aus konkreten Sensoren und Aktoren. D.h. : Es muss natürlich ein Sensor ausgewählt werden, der den Anforderungen des Gesamtsystems entspricht. D.h. Auflösung etc. muss passen. Durch die Intelligenz garantiere ich nur, dass ich mich durch die Technologie des Sensors nicht mehr beeinträchtigen lasse. Da nach außen die Schnittstelle und der Wert gleich bleibt. Im Best Case sagt der Sesnor: Ich bin ein Endanschlag (somit weiß das System dann dass es High und low in z.B. 5V0 Pegel erhält) Bei den Motoren dasselbe (soweit ich mir gedanken gemacht habe) Es gibt NEMA Motoren die durch den Allegro Treiber sich lediglich auf Vor / Zurück und Stepperweite begrenzen. Diese Schnittstelle muss eben nach außen definiert werden und dann kommen nur diese Motoren der Nema Baureihe zum einsatz die eben genau diese Eigenschaft haben. Also: Ich bin ein Motor: Ich will den Befehl: Richtung Schrittweite (schnelligkeit bzw. Genauigkeit). Damit könnte ich stand heute einen Miniaturdrucker mit kleinstem Bauraum realisieren und einen größeren als den jetztigen Ultimaker, da das NEMA Programm der Motoren sehr groß ist und sie sich alle auf diese zwei Parameter Richtung und Schrittweite reduzieren lassen. In sofern sehe ich gerade kein Problem darin. Das Datenpaket müsste eigentlich auch so aussehen: z.B. 1 = Motor 2 = Sensor Endanschlag 3 = Sensor Temp Extruder ... -> Datenpaket |1|Vor/Zurück + Schrittweite| bzw. |2..n|Sensorwert (Temperatur, Endanschlag erreicht ja / nein) etc.
Darvin D. schrieb: > Bei den Motoren dasselbe (soweit ich mir gedanken gemacht habe) > Es gibt NEMA Motoren die durch den Allegro Treiber sich lediglich auf > Vor / Zurück und Stepperweite begrenzen. > > Diese Schnittstelle muss eben nach außen definiert werden und dann > kommen nur diese Motoren der Nema Baureihe zum einsatz die eben genau > diese Eigenschaft haben. Und wozu brauchst du dann jetzt ein Bussystem. Du brauchst einen Stecker/Buchse zwischen Rechner und dem Leistungstreiber. Der kommt von der Hauptplatine runter, wandert auf seine eigene Platine und dazwischen kommt Kable mit einem Stecker/Buchse. Selbiges für die Endlagensensoren. In der Informatik versteht man unter einem 'Bus' ein bischen etwas anderes als nur Art des Kabels und Form der Stecker.
:
Bearbeitet durch User
Da ich die endliche Anzahl an Sensoren/Aktoren kenne kann ich mir auch Gedanken machen welche Konkrete Schnittstelle es geben muss, da ich nicht wie bei einer Automatisierten Fabrikkette damit rechnen muss dass ein neuer mir unbekannte Sensor hinzu kommt. Könnte ein Feature irgendwann mal sein.. aber wie hier viele schon gesagt haben. Das ganze ich nicht ohne und ich will den Ball flach halten. Wie würdet Ihr vorgehen? Erst einmal die Sensoren modularisieren und im zweiten Schritt die Motoren, da die aufwändiger sind? Alles auf einmal angehen, was das alles ziemlich komplex macht? Nur die Motoren und die Sensoren erstmal lassen, sodass das zeitkritischte zuerst erledigt wird? Wie ich schon sagte, will ich zu beginn diesen Aufbau auf dem Tisch zusammenstecken OHNE Sensoren/Aktoren um nur die Kommunikation zu testen. Ich habe schon oft uC programmiert, allerdings nie ein Netzwerk gestaltet. Daher auch die Startschwierigkeiten. Danke schonmal.
> In der Informatik versteht man unter einem 'Bus' ein bischen etwas > anderes als nur Art des Kabels und Form der Stecker. Die angeschlossene Elektronik soll ja über Datenpakete mit der Systemelektronik kommunizieren. Dafür benötigt man in meiner Welt einen Datenbus, an dem geschickt werden kann: Motor1 mach das Motor 2 mach das ...
Darvin D. schrieb: > Das Bedeutet, bei einer zentralen Komponente wie dem PI, müsste ich bei > Änderung eines Sensors, der eine andere Technologie besitzt: > Sowohl die SW im PI als auch die HW verkabelung im System anpassen und > evtl auch eine andere Spannung verlegen. Um wieviel Aufwand sprechen wir dann? Wie oft willst du Sensor/Aktuator austauschen? Der Aufwand, den du treiben werden musst um dein distribuiertes System aufzusetzen, wird höher sein als der für 10 mal Kabel wechseln! Darvin D. schrieb: > Es geht hier immernoch um ein geschlossenes System bestehend aus > konkreten Sensoren und Aktoren. > > D.h. : Es muss natürlich ein Sensor ausgewählt werden, der den > Anforderungen des Gesamtsystems entspricht. Dann soll eine deiner Anforderungen sein, dass ein neuer Sensor die vorhandene Verkabelung benutzen kann :-) Darvin D. schrieb: > Wie würdet Ihr vorgehen? Ich würde das ganze lassen, eine einzelne Raspi als Steuerzentrale nehmen und nur Kabel wechseln wenn es sein muss.
Darvin D. schrieb: >> In der Informatik versteht man unter einem 'Bus' ein bischen etwas >> anderes als nur Art des Kabels und Form der Stecker. > > Die angeschlossene Elektronik soll ja über Datenpakete mit der > Systemelektronik kommunizieren. Dafür benötigt man in meiner Welt einen > Datenbus, an dem geschickt werden kann: Motor1 mach das Motor 2 mach das > ... In meiner Welt benötigt ein Schrittmotor eine Buchse auf der "Richtung" und "Schritt" und "Masse" liegen. Nicht mehr. Ob da dann tatsächlich ein Schrittmotor angeschlossen ist, oder ein Brushless, der von einer Elektronik so angesteuert wird, dass er sich nach aussen hin wie ein Schrittmotor verhält interessiert die Zentralplatine nicht. Die definiert: was auch immer da angeschlossen wird, muss sich wie ein Schrittmotor verhalten. In meiner Welt benötigt ein digitaler Eingan eine Buchse auf der "SIgnal" und "Masse" liegen. In meiner Welt benötigt ein analoger Eingang eine Buchse, auf der "Signal" und "Masse" liegen. Sinnvoll wird es sein, auf jeder Buchse noch einen zusätzlichen Pin für +5V zu spendieren, damit das daran anghängte Sensormodul eine Spannungsversorgung für eventuelle Elektronik hat, die die Aufbereitung auf die Zentralplatine macht. Dann ist es auch kein Problem ob der Endschalter ein Reed Kontakt, ein Taster oder doch eine Lichtschranke ist. An der Zentralplatine liegt an der Signalleitung immer 0V an, wenn der 'Schalter' geschlossen ist und 5V wenn er nicht geschlossen ist. Was am Ende des Kabels sitzt und welche Elektronik den eigentlichen Sonsor auf dieses Verhalten hin trimmt, interessiert die Zentralplatine nicht. Da haufenweise Arduinos einzusetzen, ist doch mit Kanonen auf Spatzen schiessen. Die Dinge werden immer dann aufwändig und teuer, wenn sie allgemein gehalten sind. Sobald man davon weggeht, wird es auch einfach habdhabbar. Sieh dir Modellbau-Fernsteuerungen an. Da wird seit 40 Jahren derselbe Stecker mit derselben Schnittstellendefinition benutzt. Und trotzdem kann man dort alle möglichen Arten von Servos, Kreiseln, Segelwinden, Lichtschalter etc. anschliessen, weil sich alles dem Empfänger gegenüber wie ein Servo der ersten Stunde verhält. Der Stecker hat 'Masse', 'Puls' und 'Versorgungsspannung'. Der Puls ist genormt (na ja). Was dann auch immer die daran angeschlossene Elektronik damit macht interessiert die restliche Fernsteuerung nicht. Und wenn mit dem Puls die Schleusenstellung eines Kraftwerks gesteuert wird, dann wird das eben so gemacht. Dann ssteht eben der Schleusenwärter mit der Fernsteuerung aus dem Modellbauladen am Fluss. Was solls. Es würde funktionieren.
:
Bearbeitet durch User
Nachtrag.
Zumal ....
> Von der Busstruktur wäre es Sternförmig, da alle Module an die Steuerung
berichten.
... du sowieso jeden Systemteilnehmer an einen eigenen Eingang
anschliessen willst.
Was dir gerade vorschwebt, das ist möglichst kompliziert die notwendigen
Informationen von der Zentrale zu den Aktuatoren zu bringen. Das macht
Sinn, wenn die Zentrale hier bei dir steht, die Motoren aber auf der ISS
um die Erde kreisen. Aber den Fall hast du nicht. Kein Mensch hat damit
ein Problem wenn ein 4 poliges Kabel von der Zentrale zu einer
Satellitenplatine geht, die Schritt und Richtung mittels
Leistungselektronik auf den Schrittmotor bringt. Niemand braucht für
diese Distanz dazu eine Ethernetverbindung. Das sind alles nur wieder
weitere mögliche Points of Failure.
:
Bearbeitet durch User
Hallo, da vom TO ja Arduino und Communiy angesprochen wurde: ich spiele im Moment ziemlich viel mit Arduino-Zeugs rum. Hat einen einfachen Grund: China-Kram. Ein Nano oder ein ProMini kostet kein Geld, ist schon mit seinen Zutaten aufgelötet und spielt. Sensoren, Motortreiber, Displays, was-weiß-ich, alles spottbillig, schon steckfertig vorbereitet, eine zum mal Testen. Die Community, die ich bisher gefunden habe, besteht aus genau diesen Leuten. Zusammengesteckt, Sketch gefunden geht. Zweite Sache genauso. Nun "mal schnell" den Motortreiber mit dem Ultraschallsensor verheiratet. Nichts geht. Jetzt kommt die Community: ich habe da das geändert, jetzt geht es. Warum? keine Ahnung... Ich habe die Lib gegen die getauscht, jetzt geht es. Warum? keine Ahnung... Mich stört das nicht, wenn mein China-Display sich gespiegelt meldet, such ich mir eben das Datenblatt, schau in die Funktionen der Lib und passe mir die .ccp eben an. Hat mir trotzdem erstmal die Lötarbeit gespart. Das Problem, daß z.B. eine Sieben-Segmet-Multiplex-Lib eine eierlegende Wollmilchsau sein will, löst das nicht. Was nutzen mir 20 Funktionen und frei definierbare Pinbelegungen usw., wenn das Teil allein dann locker 10k Flash belegt und dabei nichtmal die Funktion besitzt, bei Ausgabe der Uhrzeit bestimmen zu können, ob bei Stunden und Minuten die führende Null nun angezeigt werden soll oder nicht. Für mich heißt Arduino also: ja, einfache und billige Testmittel, um festzustellen, ob eine Komponente für sich allein hält, was ich von ihr erwarte. Dann sowieso selber machen, es gibt im Zusammenspiel zuviel Abhängigkeiten, die mehr stören als nutzen. Keine wirklich vorhersehbares Zeitverhalten mangels sauberer Dokumentation der Libs und Komponenten. Man muß alles selber raussuchen, die Community ist nur zu gebrauchen, wenn man stur etwas nachbaut, was ein anderer schonmal zum Laufen bekommen hat. Und wenn ich jede Lib-Source selber anschauen muß, kann ich auch jede andere nehmen oder meine eigene. Gruß aus Berlin Michael
OMG. Was für ein Irrsinn, die Hardware abstrahieren zu wollen, anstatt der Software. Das macht nur beides kompliziert. Aber vom Bastlerischen her ist das zugegebenermaßen irgendwie interessant. Die Maschine als Memory-mapped IO zu sehen oder ... Schau Dir mal die VHDL-Sourcen zu den Mesa-Karten (Hostmot2) an, damit kannst Du das Beste aus beiden Welten vereinen.
Hallo Zusammen, zu dem Arduino Thema, hat mein Vorredner genau den Punkt getroffen um was es mir bei der Aussage auch ging. Mit Arduino habe ich nicht viele Kosten und kann die Realisierung in einer Machbarkeitsstudie testen ohne nachzudenken wieviel HW ich davon benötige da der Preis stimmt. Habe ich das einmal bewiesen, wird der nächste Schritt eingeleitet und eigene HW mit aus der Erfahrung des Projektes abgeleiteten MustHave entwickelt. Es ist mir durchaus bewusst dass ein uC pro Sensor / AKtor zu spendieren mit Kanonen auf Spatzen geschossen ist. Allerdings will ich mir anhand das für mich interessante System des 3D Druckers eine Spielwiese aufbauen, an der ich alle Komponenten einzeln optimieren kann. Wieso? Weil´s eben spaß macht. In SW sollte das gleiche passieren, sodass ich zu jedem Baustein auch eine dazugehörige SW abstrahieren kann. Das erlaubt es mir jedes einzelne Modul einzeln auszutauschen und z.B. einen Raspberry Pi als Steuerung zu nehmen, ein Arduino Board oder auch eine selbst entwickelte HW. Sollte etwas nicht funktionieren kann ich es dann auf eine Komponente reduzieren. Es geht mir hier nicht wirklich um den Sinn der Sache, der ist mir nämlich ziemlich klar. Es geht mir darum anhand meines 3D Druckers einen Baukasten an Sensoren und Aktoren zu entwickeln, um damit auch in anderen Projekten rumspielen zu können. Da ich schon des Öfteren gehört habe, dass Arduino anscheinend unzureichend ist, die Frage an euch: Welche HW würdet Ihr mir denn für soetwas empfehlen? Pro Komponente ein Raspberry Pi und wenn das alles mal funktioniert dann die Peripherie des Raspberry Pis auf den ARM Prozessor reduzieren? Oder gibt es optimiertere HW die ich hierzu verwenden kann? Im Zweifel starte ich wie schon erwähnt nur mit den Zeitunkritischen Sensoren als Module und die Motoren werden dann wie gehabt gemeinsam angesteuert. Bevor mein Projekt gar nicht realisiert wird, mache ich das eben auf einer Stufe drunter. Ich binn für jeden Tipp, der mich nicht von der Idee abringt dankbar.
Ich meine Lego Mindstorms NXT macht ja genau das gleiche. Ich will nur ein schwachbrüstigen abklatsch davon generieren. Mehr nicht :)
Hallo, es spricht doch nichts gegen Arduino, spezeill die 8Bit-AVR, es ist letztlich doch nur ein ATMega drauf, mit dem man machen kann, was man will. Man kann die Arduino-IDE nehmen, man kann statt setup() und loop() eben auch main() reinschreiben und alles selber machen. Man kann AVR-Studio nehmen, man kann den Bootloader nutzen oder per ISP programmieren usw. Ich für mich würde Arduino + Arduiono-IDE eben nicht als endgültige Basis eines größeren Projektes nehmen. PS: im Puppenhaus-Radio meiner Frau ist ein UKW.FM-Modul gelandet, mit einem Tiny45, programmiert mit 2 Sketchresten in der Arduino-IDE, geflasht mit dem AVR-Dragon per ISP aus der IDE. Es stört mich garnicht, daß das jetzt ein Tiny45 macht, es hätte auch kein Ram und 1k Flash dafür gereicht, so sind es 2,5kB, na und? Gruß aus Berlin Michael
Nee, bei Lego Mindstorms NXT befinden sich die drei Motortreiber im Computer-Modul. Und die meisten Sensoren von Lego enthalten keinen Mikrococontroller, sondern haben analoge und digitale Ausgänge. Dass die vier Sensor-Ports auch I2C sprechen können, ist lediglich ein optionales Feature, welches in der Grundausstattung ausschließlich vom Ultraschall-Sensor verwendet wird. Der wiederum spricht jedoch kein generisches universelles Protokoll. Jedes Zubehör mit I2C hat seine eigene spezifische Kommunikation. Du kannst noch nichtmal einen Ultraschall Sensor durch einen anderen ersetzen, ohne das Programm anzupassen. Gleiches gilt auch für alle anderen Sensoren mit I2C Schnittstelle. Außerdem wird bei Lego die I2C Schnitstelle nicht als Bus verwendet. Jeder der vier Anschlüsse ist ein eigener "Bus", aber an jeden Port schließt man nur einen Sensor an - so zumindest hat Lego es geplant.
Michael U. schrieb: > Hallo, > > es spricht doch nichts gegen Arduino, Natürlich nicht. SO habe ich das auch nicht gemeint. Was ich in Frage stelle, das ist, ob man unbedingt
1 | +------------+ +-----------+ |
2 | | | Bus | | |
3 | Schalter COmputer <--------> Computer Lampe |
4 | | | | | |
5 | +------------+ +-----------+ |
benötigt, wenn man seinen Kleiderschrank mit Beleuchtung ausstatten will, oder ob es ein
1 | +----------------------+ |
2 | | | |
3 | Schalter Lampe |
4 | | | |
5 | +----------------------+ |
auch tut. Verschiedene Lampen kann man immer noch ausprobieren, wenn man die Lampe sockelt.
Ja ich zumindest benötige das, weil ich dadurch eine saubere Abtrennung zur Lampe habe und ich mir wenn das System einmal modular steht, keine Gedanken um die Verkabelung mehr machen muss, sondern per Plug and Play einen Schalter, Taster, Lichtschranke oder übergreifend Schließer/Öffner installieren kann. und somit ziemlich schnell ein System weiter Clonen kann.. Auch kann ich dann eine LED, LED Stripe, RGB LED oder welche Lichteinheit auch immer anschließen die immer nur dern Befehl An/Aus ,Farbe, Helligkeit benötigt. Einmnal ausgiebig nachdenken, n Mal einsetzen ohne das System von neuem zu verdrahten..
Darvin D. schrieb: > Auch kann ich dann eine LED, LED Stripe, RGB LED oder welche > Lichteinheit auch immer anschließen die immer nur dern Befehl An/Aus > ,Farbe, Helligkeit benötigt. Einmnal ausgiebig nachdenken, n Mal > einsetzen ohne das System von neuem zu verdrahten.. Ohhh. Du musst noch viel lernen. :-) Aber mach mal.
Karl H. schrieb: > Darvin D. schrieb: > >> Auch kann ich dann eine LED, LED Stripe, RGB LED oder welche >> Lichteinheit auch immer anschließen die immer nur dern Befehl An/Aus >> ,Farbe, Helligkeit benötigt. Einmnal ausgiebig nachdenken, n Mal >> einsetzen ohne das System von neuem zu verdrahten.. > > Ohhh. Du musst noch viel lernen. :-) > Aber mach mal. Also deine Haltung verstehe ich hier absolut nicht. Das PRINZIP ist auf jeden Fall sinnvoll und kann Vorteile bringen. Allein die Umsetzung ist nicht ganz einfach. Aber deine pauschale Ablehnung wirkt gerade etwas borniert.
Ich vesreteh auch nicht wieso ich mich permanent erklären muss. Mir ist bewusst, dass es eine einfachere Lösung gibt indem man die SW modularisiert. Da gebe ich den Vorrednern recht. Mir ist auch bewusst, dass es hart verkabelt einfacher ist. Diese Lösung habe ich ja schon in meinem Drucker implementiert. Ich will eine nachhaltige Lösung für mich selbst generieren umd die komponenten dann wenn das system einmal steht auch woanders nutzen zu können. Das System soll auch nicht morgen fertig werden und es darf ruhig anspruchsvoll sein. Ich will nicht von Beginn an pfuschen, da ich das als meine eigene Rapid Plattform nutzen will um Projekte nachhaltiger angehen zu können. Als Startschuss habe ich nunmal mein geschlossenes System des 3D Druckers genommen. Falls der ein oder andere mir einige Denkanstöße geben kann wie ich diese Lösung anpacken kann wäre ich sehr dankbar.. Und ja ich muss noch viel lernen.. Aber dazu sind wir menschen da.. Lernen -> Erfahrungen sammeln -> weiterlernen. Und um das ganze zu beschleunigen frage ich hier im Forum nach den ein oder anderen Experten der mir auf diesem Weg einen guten Rat geben mag :) Trotzdem hat mir die Diskussion bis jetzt sehr geholfen mein eigenes Bild zu schärfen über das was ich machen will. Danke
Hallo, Ich versuche mal, Karl Heinz zu interpretieren. Man kann beliebig weit abstrahieren. Man muß dann aber den ungünsten zukünftigen Fall einplanen. Also so schnell wie möglich, soviele Daten wie möglich, so kurze Latenz wie möglich usw. Man weiß ja vorher nicht, was einem irgendwann in seinem Baukasten mal einfällt. Würde ich nie machen, bei mir wäre es immer so schnell usw. wie nötig. Alles andere ist zu aufwändig, soll Randbedingungen berücksichtigen, die man noch garnicht kennt oder nichtmal ahnt. Wenn das jetzt runtergebrochen wird auf: erstmal ja nur Schrittmotore und ein paar Sendoren, dann sind wir bei Karl Heinz und auch mir: die Zentraleinheit hat ein paar Ein- und Ausgänge mit GND/Signal/+Ub. Gruß aus Berlin Michael
Michael U. schrieb: > Hallo, > > Ich versuche mal, Karl Heinz zu interpretieren. 100% ins Schwarze getroffen. Ich seh hier ganz einfach nicht den geringsten Grund, warum man sich ein Bussystem mit all seinen möglichen Problemen einhandeln soll. Ein Endlagensensor ist ein Endlagensensor. Er hat genau einen digitalen Ausgang, egal mit welcher Technologie er arbeitet. Selbiges mit den Motoren. Man kann an der Schnittstelle für einen Schrittmotor natürlich einen stärkeren Motor anbringen, wenn man will. Nur: Das hat natürlich auch Einfluss auf die Programmierung. Die Start-Stop Rampen müssen anders berechnet werden. Klar kann man dann einfach Motor abstecken und neuen Motor anstecken, die Zentrale fragt beim Motor-Modul nach den aktuellen Parametern an und plant entsprechend um. Nur: Ob ich jetzt dem Motor-Modul die Motor Parameter konfiguriere, oder ob ich das bei der Steuerung mache, schenkt sich nichts. Gemacht werden muss es so und so. Und so oft wechselt man jetzt die Motoren dann auch wieder nicht. Aber: Ein Bus System schafft ganz neue Probleme, die man vorher so nicht hatte. Hatte man vorher das zu vernachlässigende Problem, dass man 2 Motoren koordiniert steppen lassen muss, was im zentralen µC problemlos bis auf die Port-Schaltzeiten möglich ist, so hat man jetzt ein ganz neues Problem. 2 Satelliten müssen mit der Schritt Information versorgt werden, was nur hintereinander möglich ist, und sollten trotzdem möglichst gleichzeitig ihren Schritt machen. Plötzlich ist es notwendig sich komplizierte Mechanismen einfallen lassen zu müssen, wie mehrere Satelliten synchron arbeiten obwohl sie ihre Befehle hintereinander bekommen. Viel Aufwand. Und wofür?
:
Bearbeitet durch User
Hallo, naja.. schade.. irgendwie komme ich heute nicht mehr hier im Forum weiter :)
> Viel Aufwand. Und wofür?
Um eine Nachhaltige Lösung für mich zu generieren. Was passiert wenn ich
jetzt 3 Sensoren anschließen will? Wieviel Aufwand benötigt dieser Umbau
mit der hart verdrahteten Lösung und wiviel mit der Bus Lösung?
Will ich ein System Clonen..
Habe ich die komponenten werden diese an einen Bus angeschlossen und das
System ist bertreibsbereit. Brauche ich noch einen Sensor kommt er
dazu.. brauche ich keinen.. wird er abgesteckt.. alles an ein und
demselben Bus.
Klar kann ich alles hart verdrahten.. ob das nachhaltig ist ist die
andere Frage.. Ich will ein Fundament schaffen nicht ein konkretes
Problem lösen.. ich glaube dass kommt nicht so ganz durch.. Ich habe
meinen Drucker und der tut seinen Job.. an sich gibt es also werde
Zeitdruck noch sonst etwas.. es wäre nur coll wenn ich den über die Zeit
modularisiere.. ob das sinnvoll ist oder aufwändig sollte bis dahin
denke ich einmal mein Bier sein :)
Wenn ich danach Probleme schneller lösen kann durch fertig Komponenten,
spar ich mir die Zeit wieder ein.. Das ist meine Denke.
Das kommt sehr darauf an, welche Bewegungen bei welcher Geschwindigkeit Du ermöglichen willst. Eine Kreisbewegung mit 2 getrennt an einem Bus sitzenden x/y Motoren dürfte je nach Auflösungs- und Geschwindigkeitsanforderung nicht ganz einfach werden. Selbst bei 1Mbaud wirst Du mit 50 - 100us pro Msg rechnen müssen. Das wird je nach Anforderung zu langsam sein, um jeden Step einzeln zu adressieren. Bei komplexeren Beschleunigungs- und Bewegungsbefehlen wird es aber schnell sehr aufwendig. Wenn ein einziger mc die Bewegungen aller 3 Achsen verwaltet und über Step/Richtungspins ausgibt, wird die Firmware wesentlich einfacher und effizienter. Oder: alternativ die Bewegungen schneller. Gruß, Stefan
Karl H. schrieb: > möglichst gleichzeitig ihren Schritt machen. Plötzlich ist es notwendig > sich komplizierte Mechanismen einfallen lassen zu müssen, wie mehrere > Satelliten synchron arbeiten obwohl sie ihre Befehle hintereinander > bekommen. > Viel Aufwand. Und wofür? Selbst wenn ich hinterher zb die Techologie der Endschalter gegen eine andere austauschen will, dann kann ich das immer noch problemlos machen, wenn ich einfach nur definiere, wie die 3 Pins am Anschluss für einen Endlagesensor belegt sind und welche Funktion sie haben. Dagegen hab ich nichts, das ist sinnvoll und auch gut so. Aber wo liegt denn der Vorteil, wenn die Zentrale erst mal per (angenommen) I2C eine Nachricht an den Endlagensensor schickt "Bist du betätigt" und der Sensor antwortet mit "Nein, bin ich nicht". Der Endlagensensor wird (egal in welcher Technologie) nie irgend etwas anders antworten als 'Ja' oder 'Nein'. Er ist ein digitaler Sensor, unabhängig davon, wie er technologisch realisiert ist. Ich seh da keinen Vorteil, solange sich alles in räumlicher Nähe zueinander abspielt. Ich seh aber jede Menge Probleme, die man erst mal aus dem Weg räumen muss, damit das System überhaupt funktionieren wird. Und jeder aus dem industriellen Umfeld wird mir bestätigen: je komplexer ein System, desto anfälliger. Was kann bei einem an einem Port angeschlossenen Taster gross passieren? Das Kabel kann brechen. Was kann an einem per Bussystem angeschlossenem Taster passieren? Eine ganze Menge!
:
Bearbeitet durch User
Hallo Stefan, Danke! Das sind die Inputs die ich haben mag. Wenn das mit den Steppern ein Problem darstellt, dann bilden eben alle 3 Motoren ein Modul und gut ist. Darum frage ich ja. Ursprünglich wollte ich alle Modularisieren. Wenn das im ersten Schritt nicht geht, dann gibt es ein Aktormodul bestehend aus allen 3 Steppern und eben eigene Sensor Module. Aber der Ansatz: zu umsändlich lass es, bringt mich eben leider nicht weiter :) Tschüssi
Kommt ein Mischsystem für Dich infrage? x/y und vielleicht z-Motor direkt angesteuert, die Sensoren über einen Bus? In jedem Fall kann ich Dir den CAN-Bus für Dein Projekt empfehlen: Der CAN-Bus ist ein Multi-Master-Bus. Jeder Sensor kann sich bei einem aufgetretenen Ereignis also selbstständig melden (z.B.: Endanschlag). Bei einem Single-Master-Bus muss der Master dagegen alle Sensoren der Reihe nach abfragen, was eine um ein Vielfaches höhere Latenzzeit bedeutet. Gruß, Stefan
Darvin D. schrieb: >> Viel Aufwand. Und wofür? > > Um eine Nachhaltige Lösung für mich zu generieren. Was passiert wenn ich > jetzt 3 Sensoren anschließen will? Da du sowieso von einem Sternsystem ausgegangen bist, bleibt es dir nicht erspart, an der Zentrale dafür einen entsprechenden Eingang nachzurüsten. Oder wie hast du dir gedacht, wie ein sternverkabeltes 'Netzwerk' funktioniert? Am Knotenpunkt werden die Kabel einfach alle aufeinander gelötet?
Hallo Karl, ich gebe Dir recht, dass es vielleicht nicht Sinnvoll erscheint wenn alles in der Nähe liegt. Aber wenn ich jetzt ein weiteres Projekt habe, wo die Sensoren und aktoren entfernt leieg, schreib ich dann einen neuen Thread? Und ab dann gibt es hier konstruktive Vorschläge? Ich starte mit einem geschlossenen System und ende wenn das Fundament besteht mit einer einfachen Hausautomation, wo der Temp-Sensor meine Raum Temp. Anzeigt und der Motor meine Heizung regelt... Aber um dahin zu kommen backe ich erstmal kleine Brötchen.. das ist alles.. Wie gesagt ich will kein Problem lösen.. sondern ein Fundament bilden. Viele Grüße
Darvin D. schrieb: > Auch kann ich dann eine LED, LED Stripe, RGB LED oder welche > Lichteinheit auch immer anschließen die immer nur dern Befehl An/Aus > ,Farbe, Helligkeit benötigt. Einmnal ausgiebig nachdenken, n Mal > einsetzen ohne das System von neuem zu verdrahten.. Hmja, das einmal ausgiebig nachdenken fehtl anscheind noch.
Hallo, eine Sterntopologie kann auch durch ein 10 adriges Flachbandkabel realisiert werden ;) Jede Ader = eine Verbindung zum konkreten Teilnehmer.. jeder Teilnehmer hat aber ein 10 adrigen Stecker mit welchem er genau eine Ader abgreift.. reicht das als Erklärung?
Darvin D. schrieb: > Hallo Karl, > > ich gebe Dir recht, dass es vielleicht nicht Sinnvoll erscheint wenn > alles in der Nähe liegt. Aber wenn ich jetzt ein weiteres Projekt habe, > wo die Sensoren und aktoren entfernt leieg dann haben wir eine andere Situation. > Aber um dahin zu kommen backe ich erstmal kleine Brötchen. Das ist auch gut so. Damit rennst du mir sowieso immer offene Türen ein. Wobei die Koordinierung mehrerer Motoren schon nicht mehr unter den Begriff 'kleine Brötchen' fällt. Ich denke du unterschätzt das. > alles.. Wie gesagt ich will kein Problem lösen.. sondern ein Fundament > bilden. Das ist auch ok so. Und das verstehe ich auch. Aber es macht einen Unterschied, ob ich heute am Hausbus mit ein paar Schaltern und Zeitschaltuhren und Motoren ein paar Rollos ansteuere, oder ob ein Fräser sich in den Stahl bohrt. Wobei: Selbst für Schalter und Rollos gibt es unzählige Bussystem für den Hausgebrauch.
:
Bearbeitet durch User
Darvin D. schrieb: > Hallo, > > eine Sterntopologie kann auch durch ein 10 adriges Flachbandkabel > realisiert werden ;) Schön. Und was machst du, wenn die 10 Aderen nicht mehr ausreichen? > Jede Ader = eine Verbindung zum konkreten Teilnehmer.. jeder Teilnehmer > hat aber ein 10 adrigen Stecker mit welchem er genau eine Ader > abgreift.. reicht das als Erklärung? Das hast du dir jetzt aber nicht gut überlegt. Das bedeutet nämlich, dass du mit deinem Flachbandkabel zum Beispiel durchs ganze Haus fahren musst. Von der Zentrale in den Keller (denn dort steht die Heizung) und von dort weg Stockwerk für Stockwerk wieder hoch, bis dann letzten Endes auch noch der Windsensor am Dach seine Ader kriegt. Welchen Vorteil hat da jetzt noch mal deine logische Stern-Topologie? :-) Schnellschüsse bringen dich nicht weiter. Sieh es so wie bei der Verteidigung deiner Diplomarbeit. Du präsentierst deine Ideen und die Prüfer wollen wissen, wie gut du dir das alles überlegt hast.
:
Bearbeitet durch User
Zwischen > ich habe einen 3D Drucker (Ultimaker 2) und möchte daran einige > Modifikationen machen. und > wenn das Fundament besteht mit einer > einfachen Hausautomation ist aber ein kleiner Unterschied, oder? Während beim ersteren eine Synchronisation der Motoren im 10-100us-Bereich notwendig ist, ist es bei einem Hausbus relativ egal, ob der Heizungssteller im Dach 100ms nach dem im EG angesteuert wird. Stefan
Darvin Schau. Ich will dir das doch alles nicht auf Biegen und Brechen ausreden. So ein Bussystem kann schon eine tolle Sache sein. Ich fand es beeindruckend, wie ein amerikanischer Chirurg eine Operation per Aktuator und Netzwerk an einem ganz anderen Punkt der Erde durchgeführt hat. Aber da steckt eine Unmenge an Aufwand dahinter! Und da darf auch nichts auf dem Weg dazwischen schief gehen. Letzten Endes gibt es die eierlegende Wollmilchsau nicht. In deinem Beispiel: es gibt nicht die eine Technologie, die implementiert man und alles ist gut. D.h. es gibt schon Technologien, die das Zeug dazu haben. Aber sowohl der finanzielle als auch der logistische Aufwand dahinter rechtfertigen nicht den Einsatz um damit die Kühlschrankbeleuchtung zu steuern (salopp gesagt). Manchmal ist "keep ist simple" die wesentlich bessere Lösung. (und das hab ich mit 'du musst noch viel lernen' gemeint)
:
Bearbeitet durch User
Hi Wenn ich denn auch mal darf... Ein Bussystem hab ich jeden Tag direkt auf Arbeit vor mir. Profibus. So schön eine dezentrale Lösung für die verschiedenen Anwendungen sind, so haben sie auch ihre Tücken und am Anfang stand ja der 3D Drucker. Da kommt es schon auf Genauigkeit an. Wenn da dein Schrittmotor auch nur eine 10tel Sekunde zu spät seinen Referenzpunkt gesagt bekommt ist die vielgelobte Genauigkeit zum Teufel und erst recht die Wiederholgenauigkeit. Bei einem Hausbussystem, ja, da hätte ich vielleicht gleich am Anfang meinen Senf dazu gegeben. Wie lange wird ein Taster betätigt? Selbst wenn ich mich bemühe, nur einen kurzen Impuls auszulösen, wird mein Controller diesen bemerken. Auch wenn da erst mal auf einem Bus die Information geschoben werden muss, liegt die Reaktionszeit im unbedenklichen Bereich. Gut, Software macht schon einiges, aber es ist halt immer die Anwendung, die das tempo vorgibt und wenn ich einen Bus habe mit vielen teilnehmern, komme ich nicht umhin, wesentlich größeren Aufwand zu betreiben, herauszubekommen, wer da grad was wollte. Und modular, um später ein OpenEnd-System zu haben, welches einfach ohne große Mühen erweitert wird, na ja, das kann gehen. Mit einer Datenbank in der Hinterhand und vorgefertigten Routinen. So kann natürlich ein Modul mitteilen: "ich bin ein Schalter" oder "ich bin ein Analogwertgeber". Aber dann muß ja auch der Zentralcontroller wissen, was er mit der Information anfangen soll. Also bleibt eine weitergehende Programmierung ja nicht aus. Wie gesagt, Bussysteme sind keine Allheilmittel. Wenn es dein Studiumprojekt ist, gut, warum nicht. Aber bedenke, wenns denn mal schnell gehen muss, ist es der Boss, der sofort Infos braucht, um eine Entscheidung zu treffen. Wenn da erst ein Bote durch die Büros flitzen und nach infos fragen muss, kann die Messe schon gelesen sein. Na ja, der Vergleich hinkt etwas. Aber im Prinzip haben es dir die anderen ja schon gesagt. Schau auf die Laufzeiten. Gruß oldmax
Hallo Zusammen, Was kann ich bis zum jetzigen Punkt zusammenfassen.. Zeitkritische Aufgaben über einenBus anzusteuern ist zu komplex. D.H: Motoren über einen Bus Steuern -> lass es, ist zu komplex D.h. Ich werde die Motoransteuerung aus den 3 Motoren auf eine Leiterplatte setzten und diese dann hart verdrahten mit dem Steuersystem. Dann bleiben noch die zeitunkritischen Komponenten übrig.. Endanschlag, heizbett, Display zur Anzeige der Menü Struktur und Sensoren die ich noch nicht kenne und trotzdem im Drucker verbaut sind.. Will ich diese nun intelligent machen.. Müsste ein Arduino reichen, denn ich vollbestückt im Massen kaufen kann ohne viel lötaufwand zu haben.. Hier kommt wieder die Anfangsfrage auf: Wie kann ich extrahieren welcher Bus für diese Anwendung im Drucker mit nicht zeitkritischen Komponenten der beste ist? Vielen Dank schon mal für die Geduld. Darvin
Hallo, da ja jetzt Hausbus aufgetaucht ist: ich habe seit 1979 im schönen Kaufhaus am Ostbahnhof hier in Berlin (Prestigeobjekt, gebaut von den Schweden). Wir bekamen eine Gebädeautomatisatzionsanlage. Delta 1000 von Honeywell, es gab damals in Deutschland 3 oder 4 Stück davon, 2 davon in der DDR. Zur Technik: einzelne Unterstationen mit einem 6800 mit 256Byte Ram und 4k Rom. Statuskarten (digitale Eingänge), Analogkarten (analoge Eingänge) und Schaltkarten (Relaisausgang). Ich glaube 8 Unterstationen ein Datenstrang mit 30mA Stromschleife zur Zentrale. Die Zentrale ein 4x4Bit Bit-Slice-System mit 48k(Word? weiß ich nicht mehr) Ram, davon 16k für das Betriebssytem von Kassette geladen, Eproms waren auf der Embargoliste. Standard war Polling, Zykluszeit im Sekundenbereich, so 3-6 Sekunden, jenachdem wieviele Unterstationen im Kanal waren. Ansonsten Kommandos (von der Zentrale zu den Unterstationen) und Alarme (von den Unterstationen zur Zentrale). Es wurden die gesammte Beleuchtung des Hauses, das Klima, Einbruchssicherung damit gesteuert. Bei Ausfall der Zentrale behielten die Unterstationen ihren Status bei, es gab außerdem dort Automatik/Handschalter für wichtige Sachen. Die Klimasteuerung war autonom und bekam nur Meßwerte und Sollwerte von der Honeywell. Warum ich das schreibe? Es wird heute gern gemacht, was möglich ist. Ich brauche keine Raumtemperatur im Sekundentakt, auch nicht auf 0,1 Grad genau. Ich muß nicht ständig wissen, was wo passiert. Wenn ich abends am Gartenweg das Licht einschalte sollte es angehen, sofort. Das erledigt das Kommando. Entweder stehe ich am Garetnweg dabei, dann wundere ich mich, was bei meiner Technik klemmt. Sehe ich das Ergebnis nicht und kommt der Ausalarm 4s später beim Polling (Status von Kommando und Rückmeldekontakt stimmt nicht überein) passiert real garnichts. Ob ich sofort merke, das mein Boiler im Keller nicht anging oder ein paar Sekunden später, es schafft keine zusätzlichen Probleme. Ich habe hier seit 2009 meine Sensorspielerei laufen. Temperatur, teilweise Feucht und Luftdruck. Die Funkmodule senden ca. alle Minute ein Telegramm ohne jede Rückmeldung. Egal, ob mal 1 oder 2 ausfallen, weil 2 Sensoren zeitgleich gesendet haben oder ein anderer Störer da war. Wenn nach 5 Minuten kein gültiges Telegramm empfangen wurde, ist was ausgefallen. Real nur passiert, weil eine Batterie endlich leer war und ich zu faul war. die Überwachung auszuwerten... Es passiert auch in den 5 Minuten nichts. Die Zimmertemperatur fällt nicht plötzlich um 30 Grad, der Luftdruck steigt nicht aus dreifache und es wird auch nicht im Wohnzimmer zu regnen anfangen. Für mich ist das immer der Kompromiß zwischen Aufwand und Nutzen und letztlich immer eine spezielle Lösung. Gruß aus Berlin Michael
Hallo, @Darvin Duster: was ist intelligt beim Sensor? Ein AVR hat digitale Schnittstellen mit 0V/5V, anagloge Eingäne mit 0V-5V usw. Die Sensoren müssen letztlich also ihre Meldungen in diesen Bereich konvertiren und ausgeben. Das kann ein Tiny oder auch ein Mega328 gern erledigen. Zur "Zentrale" gehen dann trotzdem nur +Ub/Signal/GND. Warum sollte man das jetzt mühsam in ein Protokoll packen und am anderen Ende wieder auseinanderbasteln, um letztendlich einen Draht von 1m Länge zu ersetzen? Gruß aus Berlin Michael
Hallo, ich mache es deshalb, weil ich dann als Anzeige eine LED, ein LCD oder ein TFT nehmen kann und alle interpretieren den Text "Hallo Welt" über genau einen Bus und eine definierte Schnittstelle. Keine Extra Verkabelung kein weiteren schnick schnack. Nur die Anzeige muss in sich zusammengebaut werden und eine definierte Schnittstelle erhalten. Dann kann aus dem Text "Hallo Welt" die LED ein Grünes Licht generieren. Das LCD das als Text darstellen und das TFT das als Bild. Aber alle kommunizieren über ein und den gleichen Bus. Darum :)
Darvin D. schrieb: > Hallo, > > ich mache es deshalb, weil ich dann als Anzeige eine LED, ein LCD oder > ein TFT nehmen kann und alle interpretieren den Text "Hallo Welt" über > genau einen Bus und eine definierte Schnittstelle. Ja. Da spricht ja auch nichts dagegen. Das macht man seit 60 Jahren so. Genau das ist der Hintergedanke bei einem Terminal. Aber, und das ist der springende Punkt: Was hat das jetzt mit einem Endschalter zu tun? Oder anders rum gefragt: Hast du irgendeinen Vorteil davon, dann du einen Endschalter an genau der gleichen Buchse anstecken kannst, an der vorher dein LCD gesteckt ist? > Keine Extra > Verkabelung kein weiteren schnick schnack. Nur die Anzeige muss in sich > zusammengebaut werden und eine definierte Schnittstelle erhalten. > Dann kann aus dem Text "Hallo Welt" die LED ein Grünes Licht generieren. > Das LCD das als Text darstellen und das TFT das als Bild. Aber alle > kommunizieren über ein und den gleichen Bus. Was du in meinen Augen übersiehst, das ist dass es verschiedene 'Klassen' oder 'Arten' von Busteilnehmern gibt. Dein letztes Beispiel kann man getrost in eine Klasse Benutzerinterface zusammenfassen. Ein Endschalter ist aber eine ganz andere Kategorie. Macht es irgendeinen Sinn, dem den Text 'Hallo World' senden zu können? Möchte man das überhaupt können? Welchen Preis zahle ich dafür, das ich das kann, auch wenn es in keinster Weise sinnvoll ist? (Mit Preis ist sowohl Hardware als auch Software Aufwand gemeint, in Kombination mit natürlich dem entsprechenden finanziellen Aufwand.)
Karl H. schrieb: > (Mit Preis ist sowohl Hardware > als auch Software Aufwand gemeint, in Kombination mit natürlich dem > entsprechenden finanziellen Aufwand.) Insbesondere letzters, der finanzielle Aufwand, kann sich nämlich auch ganz schnell ausarten. Ein Hausbussystem klingt erst mal toll. Und vor dem geistigen Auge entstehen dann auch ganz schnell die tollsten Steuerungen innerhalb eines Hauses. Das böse erwachen kommt dann meistens ganz schnell, wenn das erste mal abgerechnet wird, was das alles kosten würde. Dann ist die automatische Abschaltung des Flurs von einer Zentrale aus gleich gar nicht mehr soooo verlockend und ein normaler Zeitschalter tuts auch. :-) Gut. Ein paar Ardunios kosten in deinem Fall jetzt sicherlich nicht die Welt. Aber immerhin.
:
Bearbeitet durch User
Um mich einmal auf deinen 3d Drucker zurück zu kommen. Wenn du alle Motoren an ein Board klemmst, dann ist dein nächstes Problem der Endschalter. Den du solltest nach jedem Schritt kontrollieren ob er ausgelöst und dann den Motor sofort stoppen können. Nebenbei ist der extruder auch kritisch ;) Das gelingt dir mit einem Bus nicht -> Endschalter auch ans Board. Dann gibt es noch das Heizbett und Hotend. Und die beiden Sensoren dazu... Warum nicht alles an ein Arduino klemmen, ein Ramps oder was es da mittlerweile neueres gibt nehmen und dein Drucker funktioniert. Soviel zum Thema Drucker. Ein Hausbus ist ein komplett anderes Thema. Das ganze spielt auch hier um den Faktor 10000 langsamer ab. Und es ist idr. nicht wichtig, was in welcher Reihenfolge geschaltet wird. Wuchtig ist, das es in annehmbarer Zeit schaltet und annehmbar schnell auch Sensoren reagiert wird. Überleg dir nochmal was du genau willst und dann kann man dir auch helfen. Btw. Das mir der LED die auf Hallo Welt hört ist ziemlich ineffizient ;) . Der Befehl heißt an/aus...
Ein 3D-Drucker ist ein in sich geschlossenes System, bestehend aus aufeinander abgestimmten Komponenten. Du kannst Motor X nicht einfach so durch einen anderen Motor Y ersetzen, ohne irgendwelche Dinge an der Software zu ändern (und seien es Kalibrierungswerte). Den Motor durch einen Endlagenschalter, eine LED oder ein Display zu ersetzen, wäre sogar zu 100% sinnfrei, denn danach funktioniert dein 3D-Drucker nicht mehr als 3D-Drucker. Du willst ein System bauen, bei dem du durch einfachen Austausch von Modulen einen 3D-Drucker in ein Puppenhaus umwandeln können willst, und wieder zurueck - ohne Änderung der Software. Das lohnt nicht. Ein Hausbus ist eine ganz andere Sache. Da hast du vollkommen andere Voraussetzungen, ganz andere Möglichkeiten und ganz andere Anforderungen. Ab einer gewissen Größe möchtest du dort auch nicht mehr alle Sensoren und Aktoren an ein Bussystem anschließen, sondern (halbautonome) Untersteuerungen einbinden (pro Raum, pro Geschoss, pro Gebäude eines Komplexes). Und dann plötzlich auch redundant, gerne auch durch verschiedene Sensortypen fuer die gleiche Messgröße. Statt deinen 3D-Drucker kaputtzupfuschen, nutze ihn lieber fuer ein kleines Projekt: - drucke dir einen kleinen 3-stöckigen Aufzug als Modell aus - fuer jeden Stock brauchst du 2 Taster (hoch/runter) und 1 LED (unterwegs), einen Sensor (Aufzug da) und 1 Motor (Tuer auf/zu) - und einen Aufzug, der hoch/runterfährt und die Sensoren betätigt Dann kannst du jeden Sensor und jeden Aktor an ein Bussystem anknoten (z.B. mit I2C, das ist aber unkritisch) und dich einmal bei einem kleinen Teil einer Automatisierung austoben. Sowas ähnliches gab es an meiner alten Uni fuer verteilte Systeme (Sensoren/Aktoren waren autonom), um die Probleme solcher Systeme zu studieren.
Deine Nachhaltige Baukastenlösung ist nicht wirklich anchhaltig. Denn wann immer du einen anderen Sensor oder Aktuator anschließen wilst, wirst du dazu passend einen Mikrocontroller programmieren müssen. Und zwar für jedes einzelne neue Teil. Wenn du hingegen den klassischen Ansatz wählst, hast du einen 10x einfacher programmierbaren Computer (zum Beispie einen PC) für die Steuerung, sowie ein universelles I/O Interface mit "dummen" analogen und digitalen Anschlüssen. So oder so musst du für jede neue Hardware programmieren. Dein "nachhaltiger" Ansatz sieht vor, dazu jedesmal Mikrocontroller mit einem komplexen Bus zu programmieren. Mein "herkömmlicher" Ansatz bestände darin, nur einen Computer zu programmieren, bei dem das auch noch viel einfacher und komfortabler geht. Hinzu kommt: Jede Komponente erhöht das Ausfallrisiko. Dazu zählen aus Softwarekomponenten. Komplizierter bedeutet IMMER auch Fehlerträchtiger. Was genau ist nun an deinem "nachhaltigen" Modell nachhaltiger? Ich verstehe es nicht. Denk mal darüber nach: Warum haben das nicht schon andere vor Dir so umgesetzt? Du solltest nicht nur die Vorteile deiner Idee betrachten, sondern auch die Nachteile und möglich Gründe, es doch nicht zu tun.
Hallo S. R. schrieb: > Den Motor durch einen Endlagenschalter, eine LED oder ein Display zu > ersetzen, wäre sogar zu 100% sinnfrei, denn danach funktioniert dein > 3D-Drucker nicht mehr als 3D-Drucker. Wer hat das behauptet? Ich will eine Anzeigeeinheit durch eine Anzeigeeihnehit, einen Motor durch einen Motor einen Sensor durch einen Sensor ersetzen. Bitte keine eigenen Folgeschlüsse ziehen. > Du willst ein System bauen, bei > dem du durch einfachen Austausch von Modulen einen 3D-Drucker in ein > Puppenhaus umwandeln können willst, und wieder zurueck - ohne Änderung > der Software. Das lohnt nicht. Auch das will ich nicht, Ich will ein System bauen anhand des Beispiels eines Druckers bei dem ich das wissen über den einzelnen Kompoinenten clonen kann und eine Anzeige und einen Sensor übernehmen kann, nocheinmal nachbauen und dann für ein anderes Projekt bauen. Das ist ein wesentlicher Unterschied. > Dann kannst du jeden Sensor und jeden Aktor an ein Bussystem anknoten > (z.B. mit I2C, das ist aber unkritisch) und dich einmal bei einem > kleinen Teil einer Automatisierung austoben. Sowas ähnliches gab es an > meiner alten Uni fuer verteilte Systeme (Sensoren/Aktoren waren > autonom), um die Probleme solcher Systeme zu studieren. Genau das war meine Grundfrage. Welchen Bus kann ich nehmen? Ob ich nun alle Motoren modularisiere oder nur die Sensoren haben wir ja hier ausdiskutiert und ich bin zum enstchluss gekommen, nur die Sensoren und ALLE Motoren als ein Modul zu sehen. und tschüss
Hallo nochmal, Stefan U. schrieb: > Deine Nachhaltige Baukastenlösung ist nicht wirklich anchhaltig. > Denn > wann immer du einen anderen Sensor oder Aktuator anschließen wilst, > wirst du dazu passend einen Mikrocontroller programmieren müssen. Und > zwar für jedes einzelne neue Teil. Wenn ich jetzt Studenten kenne die örtlich nicht hier in D leben, dann sage ich denen .. Baut euch ersteinmal die ganze Infrastruktur auf und dann können wir eine gemeinsame Basis finden um zu entwickeln? Mit dem modularen Ansatz benötigen die nur eine Steuereinheit und die Schnittstelle nach aussen die das Modul haben muss und sie können loslegen. Aber da denken wir anscheinend unterschiedlich. > > So oder so musst du für jede neue Hardware programmieren. Dein > "nachhaltiger" Ansatz sieht vor, dazu jedesmal Mikrocontroller mit einem > komplexen Bus zu programmieren. Der Bus wird genau einmal in SW in Betrieb genommen und der SW-Teil auf alle uC draufgeflasht. Was bleibt ist lediglich die digitalisierung / anpassung des Sensors. Ja das ist nachhaltig. > Hinzu kommt: Jede Komponente erhöht das Ausfallrisiko. Dazu zählen aus > Softwarekomponenten. Komplizierter bedeutet IMMER auch Fehlerträchtiger. Da gebe ich dir recht. Aber wie du auch von redundanz schreibst müsste diese Komponente in einen späteren Schritt redundant aufgebaut werden. > Was genau ist nun an deinem "nachhaltigen" Modell nachhaltiger? Ich > verstehe es nicht. > Wenn die Elektronik eine einheitliche Schnittstelle nach außen hat... Wenn der Bus als SW implementierung einmal gemacht wird und auf jeden uC übertragen wird Wenn die SW Komponenten in der Steuereinheit modularistert werden, sodass jedes Modul ein dazugehöriges SW Paket hat und bei einer änderung auch NUR dieses angefasst werden muss... Dann ist es in meinen Augen nachhaltig. Da ich elektronik auf einer Basis entwickeln kann ohne das ganze System kennen zu müssen. > Denk mal darüber nach: Warum haben das nicht schon andere vor Dir so > umgesetzt? Du solltest nicht nur die Vorteile deiner Idee betrachten, > sondern auch die Nachteile und möglich Gründe, es doch nicht zu tun. Ich denke weil es aus kosten sicht kein Vorteil gebracht hat zu früheren Zeiten, da uC viel gekostet haben. Heute kostet das nichts mehr und auch namhafte Laborequipmenthersteller statten ihre Oszis VOLL aus und begrenzen diese nur durch die freiuschaltung von softwarelizenzen. Warum? Weil eine Vollausstattung billiger ist. Viele Grüße
und nocheinmal hallo, in Foren sagt man immer, dass man den Usern das ganze Projekt nennen sollte, damit diese auch genügend Background haben um eine kompetente Antwort zu liefern. Ich sehe das in diesem Thread eindeutig als Fail. Meine Grundfrage war es : Mehrere Sensoren und Aktoren über einen 1meter langen Bus miteinander kommunizieren zu lassen und jeden davon intelligent zu machen. Das ist die Frage der ich immernoch nachgehe. Stattdessen haben wir hier um die Sinnhaftigkeit der Idee einen 3D Drucker zu modularisieren geredet.. Wenn es für euch keinen Sinn macht, dann muss ich das verstehen. Für mich macht es das. Da ich darin eine Nachhaltigkeit sehe. Ich habe rausgezogen dass ein Motor zu zeitkritisch ist das ist ok. Aber wenn ich die X-Y-Z Ansteuerung des Druckers für ein Lasercutting oder eine Fräse nutzen mag, macht es durchaus sinn die Sensoren die zusätzlich hinzukommen als Module anzubinden. Da ich dadurch flexibler bin und im Best Case, mir den Sensor kurz testen kann ob er tut was er soll und dann in n-Facher Ausführung zu klonen um diesen in anderen Anwendungen einzusetzen. Weder im HAUSBUS noch im 3D Drucker.. Einfach in weiteren Projekten. Also habe ich gelernt, dass ich das nächste Mal NUR mein Problem ohne die Randparameter beschreiben werde, sodass ich auch nur auf technischer Basis mit euch Diskutieren kann. Ich schätze dieses Forum sehr, weil viel Kompetenz drin steckt, aber dieses: das macht keinen Sinn darum gibt es auch keine Antwort, finde ich etwas traurig. Da ich vielleicht diese Lösung nicht in meinem 3D Drucker implementieren werde. Aber es in einem Anderen System ausprobieren könnte. So stehe ich immernoch in der Grundsatzdiskussion ob es Sinn macht oder nicht. Und die technischen Fragen sind immer noch offen. Trotzdem möchte ich mich für das ganze Feedback bedanken. Viele Grüße Darvin
Hi >So stehe ich immernoch in der Grundsatzdiskussion >ob es Sinn macht oder nicht. Nö. Du hast dich doch schon längst entschieden. Also mache es. Oder brauchst du die Absegnung vom Forum? MfG Spess
spess53 schrieb: > Nö. Du hast dich doch schon längst entschieden. > > Also mache es. Oder brauchst du die Absegnung vom Forum? > > MfG Spess Nein. Er möchte vom Forum den für seine Zwecke am besten geeigneten Datenbus empfohlen bekommen. Er hat seinen Zweck beschrieben, das Forum kann dazu keinen Bus empfehlen, weil es keinen Sinn macht: er ist beleidigt. Daraufhin will er eine allgemeine Busempfehlung für einen unbeschriebenen Zweck und da ist eine Empfehlung ebenfalls nicht möglich. Es gibt halt keinen Eierlegenden-Wollmilchsau-Bus.
Route 6. schrieb: > Es gibt halt keinen Eierlegenden-Wollmilchsau-Bus. Suche ich auch gar nicht! So weit sind wir hier im Thread ja gar nicht gekommen ;) Ich habe wie oben beschrieben keine Erfahrung mit der Kommunikation von Mikrocontrollern über einen Bus und würde gerne wissen wie man den richtigen Bus dafür findet. Was die Kriterien sind die ich zu beachten habe um diesen richtig auszulegen am von mir genannten Beispiel. Da hier gar nicht darauf eingegangen wird, sondern nur um die Sinnhaftigkeit des Anwendungsfalls diskutiert wird, fällt es mir auch schwer technisch weiter zu kommen. Viele Grüße
Hallo, Anforderungen? Geschwindigkeit, Latenz, Datenmenge, Anzahl Busteilnehmer und deren Adressierbarkeit, Länge der Busabschnitte, Zuverlässigkeit, Umgebung (störbehaftet oder nicht), keine Ahnung, was ich jetzt vergessen habe. In Deinem Beispiel mit dem 3d-Drucker wurde doch schon geklärt, das für diesen Anwendungsfall eine Busstruktur ein sehr ungünstiger Lösungsanstz ist. Auch die Gründe wurden schon genannt. Gruß aus Berlin Michael
:
Bearbeitet durch User
Wie ich bereits geschrieben habe: Um eine schnelle Reaktionszeit für Sensorwertänderungen zu erreichen, empfehle ich Dir einen Multi-Master-Bus, bzw. den CAN-Bus. Ok, das ist mit Arduino-Platinen nicht zu erreichen. Aber mit den bei Arduino vorhandenen Schnittstellen muss Dein master alle Sensoren pollen, mit je nach Poll-Intervall entsprechend schlechter Latenzzeit. Wenn Du das in Kauf nimmst, kannst Du I2C (bei 1m Entfernungen) oder RS485 (Entfernung egal) benutzen. Falls Du nicht auf ATmega fixiert bist, gibt es übrigens auch günstige mc und Boards mit integriertem CAN in der ARM-Welt (STM32F042), z.B. das hier für 10€ mit bereits integriertem Debugger: http://www.st.com/web/en/news/n3742 ... oder das Gegenstück von TI, da gibt es einen mc mit bereits integriertem CAN-Treiber (k.A. wegen Demo-Board). Gruß, Stefan
> Aber wie du auch von redundanz schreibst müsste diese > Komponente in einen späteren Schritt redundant aufgebaut werden. Willst du im Ernst Teile des 3D Druckers redundant aufbauen? Ich glaube, du hast keine Vorstellung davon, wie aufwändig das wird. Bzw wie wenig sinnvoll es wird, wenn man nicht alles redundant macht. Andere Leute stellen sich einfach zwei gleiche Drucker hin. Oder zwei Unterschiedliche Drucker mit USB Anschluss und Treiber - da hast du deine Bus-Empfehlung. Baue deinen Drucker so, dass er über USB angesteuert werden kann und einen Hardwareunabhängigen Befehlssatz hat (so wie Postscript bei 2D Druckern). Dann kannst du den Drucker jederzeit durch einen anderen austauschen ohne die Steuerung zu ändern, nämlich das Programm, dass dem Drucker sagt, was er tun soll. Folge dem Beispiel anderer Produkte, die sich seit zig Jahren bewährt haben.
Darvin Duster schrieb: > Wer hat das behauptet? Ich will eine Anzeigeeinheit durch eine > Anzeigeeihnehit, einen Motor durch einen Motor einen Sensor durch einen > Sensor ersetzen. Bitte keine eigenen Folgeschlüsse ziehen. Und plötzlich ist dein Bussystem nicht mehr so universell, wie du es urspruenglich mal definiert hattest. Denn nun hast du "Motoranschluesse", "Sensoranschluesse", "Displayanschluesse" - ob die elektrisch kompatibel sind, bleibt erstmal außen vor. Frage: Soll dein "Anzeigeeinheitsanschluss" grafische LCDs verwalten, oder HD44780-artige Text-Displays? Oder sogar beides? > Auch das will ich nicht, Ich will ein System bauen anhand des Beispiels > eines Druckers bei dem ich das wissen über den einzelnen Kompoinenten > clonen kann und eine Anzeige und einen Sensor übernehmen kann, > nocheinmal nachbauen und dann für ein anderes Projekt bauen. Das ist ein > wesentlicher Unterschied. Ja. Und du vergisst dabei eine klitzekleine Kleinigkeit: "ein 3D-Drucker" und "ein anderes Projekt" arbeiten mit höchstwahrscheinlich unterschiedlichen Voraussetzungen und haben unterschiedliche Anforderungen. > Welchen Bus kann ich nehmen? Jeden beliebigen und keinen einzigen. Du musst in der Lage sein, N verschiedene Busteilnehmer /möglichst gleichzeitig/ anzusprechen. Das heißt, hohe Bandbreite und geringe Latenz; oder hoher Aufwand in der Softwaresynchronisierung. Da du oben eine Sternverkabelung vorausgesetzt hast, wäre ein Point-to-Point-Bussystem äußerst gut geeignet. Du verbindest also jeweils einen Sensor oder Aktor mit jeweils einem Busanschluss der Steuerung... > Ob ich nun alle Motoren modularisiere oder nur die Sensoren haben wir ja > hier ausdiskutiert und ich bin zum enstchluss gekommen, nur die Sensoren > und ALLE Motoren als ein Modul zu sehen. Also quasi den gesamten Drucker minus die Anzeige? Das macht vieles einfacher, weil dein Bussystem jetzt nicht mehr hart echtzeitfähig sein muss. Dann wäre Ethernet ein mögliches Bussystem zwischen verschiedenen Modulen (d.h. zwischen verschiedenen Druckern und Displays). Oder auch USB. Fertige Protokolle gibt es genug.
Darvin Duster schrieb: > Ich habe wie oben beschrieben keine Erfahrung mit der Kommunikation von > Mikrocontrollern über einen Bus und würde gerne wissen wie man den > richtigen Bus dafür findet. Hallo! Du hast den Zweck eine Bussystems nicht verstanden. Busse werden eingerichten/konzipiert um Leitungen einzusparen, nicht um Funktionalitäten zu standardisieren. Das ist so bei parallelen Bussen (ECB, ISA...) aber auch bei seriellen (I²C, RS485, ASi, CAN...). Für Bussysteme gibt es das OSI-Schichtenmodell. Das wurde nicht aus Langeweile oder Spaß am Schreiben dokumentiert. Jede Schicht hat Ihre Besonderheiten. Du musst Dich -je nach Deinem Anwendungsfall- von "oben" (applikation layer) nach "unten" (physikal layer) durchwursteln (sorry Conchita!). Dabei wird Dir die Erleuchtung kommen: je nach Buszweck ist eine andere Lösung, mit weniger Kompromissen und anderer Physik, sinnvoll. Auch im PKW gibt es nicht nur CAN - und zuhause hat man Ethernet10/100/1000, WLAN, Blauzahn, NFC, ISDN, I²C, RS485, CAN, K1520, IFSS... Jedes für den dort am besten passenden Zweck. Was war doch gleich mal Dein Zweck?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.