User-Projekt

Kani · July 17, 2009 at 2:16 PM

Ok, ich würde dann sagen, dass wir das Thema mit der Ist-Position erstmal offen lassen. Was soll es denn noch für Features geben?

**TiPpFeHlEr** · July 17, 2009 at 2:17 PM

idee

könnte mann nicht als inkremental geber nen anderen (kleineren)stepper nehmen??
der müsste die gleiche stepzahl haben, und funtioniert wie ein generator. die enstandene spannung an den strängen kann man doch messen und auswerten. somit wäre eine exakte position bestimmung (schritte mitzählen) möglich. ohne grossen selbstbau aufwand!!(lochrasterscheibe)

mfg maik

max · July 17, 2009 at 3:03 PM

mit einem zweiten Schrittmotor schritte zählen geht wenn ich mich richtig errinere nur im Vollschritbetrieb und das wollen wir ja auch nicht.

Features würden mir so einige einfallen!
Bei einem Modular aufgebauten System lassen sich die meisten aber im nachhinein noch über extra einschübe realiesieren.
z.B.

RDM: Überwachung der Spannungen an Netzteilen, Temperaturüberwachun Kritischer Bauteile, Blockierung der Stepper,....

Denn ganzen DMX Krempel rausschmeissen und durch TCP/IP ersetzen, müsste dann möglich sein unter berücksichtigung aller Sichhereitskreterien einen Laser mit Galvos in den Kopf zu setzen

Eigenes Modul mit On Borde Bewegungen, Kreise, etc.

Da kann dann so einige Spielerein machen

**dirk_e** · July 17, 2009 at 3:10 PM

Eine Positionsauswertung mit einem 2. Motor würde sehr sehr kompliziert.
Überleg nur mal was da ungefähr auf den Motorleitungen passieren würde wenn der einen Halbschritt macht. Das kann man messen aber nur mit viel Aufwand.

Da sind 2 Lichtschranken und eine passende Lochscheibe deutlich billiger.
Selbst ein fertiger Inkrementalgeber ist da billiger.

Außerdem braucht man nicht eine Absolutposition, da beim einschalten immer der Nullpunkt angefahren wird.

Für Inkrementalgeber gibt es fertige IC's oder man macht das in Software.
Je nach Prozessor und Verfahren bekommt man da auch ordentliche Geschwindigkeiten hin.

**TiPpFeHlEr** · July 19, 2009 at 9:58 AM

öhm

sachtmal, wo finde ich eine sog. "lochrasterscheibe" finde bei G...le nix. wie werden die dinger den richtig genannt??
weil selber bauen halte ich für eine schlechte idee, da die toleranzen doch arg klein sein müssen, bei einer 16bit auswertung. er soll ja nich ständig einen schritt vor und zurück korrigieren:D

mfg maik

**TiPpFeHlEr** · July 19, 2009 at 11:02 AM

soooo

hab was gefunden^^

[Blocked Image: http://www.shop.robotikhardware.de/shop/catalog/i…/GP1A038RBK.jpg]

http://www.shop.robotikhardware.de/shop/catalog/p…products_id=135

allerdings nur 120 impulse/umdrehung

denke mal das bei Stefan's MH keine 16bit auswertung besteht, encoderscheiben mit 16bit sind extrem gross und teuer. es werden zb. also nur alle 10 schritte gezählt.

etwas teurer aber besser bei Farnell

http://de.farnell.com/encoder-code-wheels

mfg maik

max · July 19, 2009 at 5:10 PM

der erste Link sieht ja schon mal ganz vielversprechend aus!

Bevor wir uns jetzt so auf den INkrementalgeber Fixieren sollten wir vieleicht erst mal noch grundlegende Sachen besprechen die das User-Projekt angehen.

Die meisten haben sich bis jetzt für ein Modularen Aufbau positiv geäusert. Also müssten wir uns zu allererst mal auf eine Komunikation unter den Modulen einigen. Könnte jemand der Sich mit den verschiedenen Bussystem auskennt vieleicht mal was dazu sagen. Ich habe mal ein bisschen im Internet gelesen, bin jetzt aber auch noch nicht wierklich schlauer geworden wie man das am besten machen könnte.

Mein vorschlag währe es in der ersten ausbaustuffe erst mal nur 4 Module vorzusen, der rest kann dann später noch kommen.

1. Modul: Transiver, Umwandlung DMX auf internen Bus
- Einstellung der DMX Adresse
- einstellung der auszuwertenden DMX Kanäle

2. Modul: Netzteil
- Entweder ein kleines Netzteil nur für die Elektronik oder direkt eins mit mehreren Spannungen und genug Pauer um Stepper und LEDs zu versoregn?
- eventuell Strom und Spannungs überwachungen vorsehen, für stäteren RDM oder ArtNet ausbau

3. Modul: Steperkarte
- ?

4. Modul: LED Treiber
- bei den LED Treibern würde ich zu getakteten Treibern greifen. Habe meine ersten Projekte mit den LM317 gemacht und hatte immer Probleme mit der Wärme.

Bei der Frage ob Backpanalesystem oder normale verdrahtung würde ich voschlagen, die Platinen so aufzubauen das beises Möglich ist.

ballrock2 · July 19, 2009 at 6:21 PM

Bin im Thema von Schnittstellen (zumindest in elektronischen Schaltungen) nicht so firm. Aber evtl. würde es Sinn machen, bei einem modularen Aufbau wie im PC Steckplätze am CORE vorzusehen.

Damit würden die wilden Verdrahtungen und Kabel-Stecker-Verbindungen entfallen und man könnte im Störungsfall ggf. sehr schnell einfach eine neue Erweiterungskarte einstecken.

(Der Gedanke kam mir gerade und ich stelle ihn einfach mal zur Diskussion, ob er gut ist, kann ich noch nicht so recht beurteilen. Pro ist in jedem Fall, das man schneller austauschen kann und keine falsch angeschlossenen Verbindungen Fehler auslösen könnten. Contra könnte sein, dass das gesamte Modulsystem dann auf jeden Fall eine Art Kasten braucht, da es nicht an Wänden o.ä. verteilt werden kann).

LCD-Anzeige halte ich auch für unnötig, hier reicht ein Mäuseklavier ganz gut aus. Lediglich eine Betriebs- und eine Störungs-LED (Blink-Codes) sollte es auf jeden Fall geben.

Viele Grüße von
Andreas

Kani · July 19, 2009 at 6:33 PM

Das Netzteil sehe ich nicht direkt als Modul an.

Hier das Datenblatt vom ATmega8515-16D
Zum Kommunizieren könnte man SPI (Seite 125) oder USART - Multi-processor Communication Mode (Seite 149).

Aber Hendrik kann uns da bestimmt mehr zu sagen.

EDIT:
Für die Adressierung kann man ja auch ein Modul machen. Normales Mäuseklavier oder halt 7-Segment-Anzeigen.

Hendrik Hölscher · July 19, 2009 at 7:07 PM

DMX braucht den USART.

Es bleibt SPI. Durch eine ringförmige Topologie könnte man einen Vollduplexbetrieb mit extremen Datendurchsatz realisieren. Es gibt auch einen Industriebus in dieser Art für Sensoren - der Name ist mir gerade entfallen...

Durch eine Standardisierung der Platinen und Anschlusspositionen lassen sich komfortable Systeme bauen. Allerdings:
- Mit der Anzahl der Slave-AVRs steigt die Komplexität des Gesamtsystems. (Viel Spaß beim Debuggen.)
- Verspricht jeder von Euch, sich an den beschlossenen Standard für alle zukünftigen Projekte in diesem Bereich zu halten? (Sonst können wir uns den Aufwand und die Kompromisse sparen.)
- Reicht das Wissen von uns allen, dass jeder die Features, die ihn interessieren, auch implementieren kann?

Das Kernmodul würde in Konkurrenz zu meinem Transceiver gehen, wofür der Markt zu klein ist. Der Wechsel hätte auf mich keine finanzielle Auswirkung mehr. Bei guten Argumenten wären auch die bisherigen User über die Umstellung auch nur mäßig verärgert. (Die FWs würden portiert, der Support der Transceiver beendet und die bisherigen Module in absehbarer Zeit reif für die Tonne...)

Von daher: Das Kernmodul muss unglaublich durchdacht und genial werden! (Größe, HW-Features, Zielkosten sind wichtige Parameter.)

Hendrik

Kani · July 19, 2009 at 7:23 PM

Also, für die Hauptplatine sollte schon ein großer Controller her. Nicht das man schon in absehbarer Zeit eine neute Platine machen muss, weil die vorherige zu klein ist oder so.

max · July 19, 2009 at 7:40 PM

verstehe ich das jetzt richtig das ihr jetzt an eine art motherboard denkt, auf dem der eigentliche Controler sitzt und X Slots hat?

Das sich entwickler von weiteren Modulen an den Festgelegten standarts halten, sollte eine Grundvorraussetzung sein! Ansonsten können wir uns das ganze Projekt hier sparen.

Kani · July 19, 2009 at 7:46 PM

Ja klar, die Standarts müssen eingehalten werden.

**Stefan** · July 19, 2009 at 10:31 PM

Quote

Original von Hendrik Hölscher
Durch eine ringförmige Topologie könnte man einen Vollduplexbetrieb mit extremen Datendurchsatz realisieren. Es gibt auch einen Industriebus in dieser Art für Sensoren - der Name ist mir gerade entfallen...

Vielleicht I²C? Sprechen einige Atmels auch nativ.

Quote

Original von Kani
Ja klar, die Standarts müssen eingehalten werden.

Bitte Standards

mar3kus · July 19, 2009 at 10:50 PM

hi leute,
habe leider erst jetzt diesen Thread entdeckt, hoffe aber das ihr noch offen für Interessenten an diesem Projekt seid Dann würde ich mich nämlich auch gerne anschließen.

Wieso nicht einfach serielle Signale? Sind einfach umzusetzten und es gibt ja AVRs mit 2 Hardware UARTs zB ATmega162

Gruß
Markus

Hendrik Hölscher · July 19, 2009 at 11:53 PM

Eine synchron serielle Schnittstelle hat den Vorteil, dass man nicht genau den Takt einhalten muss - also evtl. bei den Slaves auf Quarze verzichten kann. Zudem lassen sich bei geschickter Wahl der Parameter auch Schieberegister und andere Perepherie einbinden.

TWI ist auch etwas Feines - die Frage ist, wie der Durchsatz und der Nutzdatenanteil aussieht. Zudem sollte die Implementierung auch Anfängern möglich sein.

Weitere RS232-Verbindungen hätte ich ungern - es scheitern schon genug Leute an der Anbindung von DMX. Das muss man nicht noch potenzieren...

VG,
hendrik

**dirk_e** · July 20, 2009 at 12:10 AM

Hi,
ich würde das ganze so aufbauen:

- Hauptsystem für DMX, Anzeige, Knöpfe, Positions Berechnung und Verteilung der Daten an die Subsysteme.
Das ist der Teil der an jedes Gerät (Art, Ausstattung, ..) angepasst werden muss.
Das Ding braucht eigentlich nicht viel Rechenpower, da hier keine großartigen Dinge drauf passieren (ein ATMEAG32 sollte da schon reichen).
Ich würde auch gleich einen Ethernetcontroller mit drauf machen.

- Subsysteme (Stepper) wird extern Konfiguriert und empfängt dann nur noch die neuen Soll-Positionen. Alle Rampen und Reglungen laufen dadrauf.
Das Ding wäre dann ohne Änderung überall einsetzbar.

- Netzteil sollte getrennt von den anderen Modulen sein.

Das ganze bitte nicht auf eine Art Mainboard stecken, lieber alles mit Kabel machen (zB. Flachbandkabel). Das Sollte aber bei allen Modulen gleich aufgebaut sein.

Da wir hier nur über kurze Verbindungswege sprechen, würde ich I²C nehmen.
1. Alle ATMEGA AVR's können das.
2. Das Tempo reicht locker bei dieser Anwendung, selbst eine Software Lösung.
3. Es ist etwas sicherer wie SPI. Erst recht mit einem gesicherten Protokoll.
4. Das gezielte ansprechen eines Subsystems ist möglich
5. Parallel kann man fertige IC's mit einbauen (AD, DA, IO, Speicher, ....)
6. I²C kann man im Notfall auch Galvanisch trennen

Viele Grüsse,
Dirk

mar3kus · July 20, 2009 at 9:09 AM

was mit am I²C nicht so ganz gefällt ist, dass man nur sehr schwer an die ziemlich teuren Repeater und Multiplexer kommt. So ein Baustein kostet dann auch noch gerade mal 3-4€...und bei etwaslängeren Kabeln bzw. mehreren Clients wäre sowas durchaus sinnvoll, wenn nicht sogar nötig.

Hier noch ein schönes Projekt, dass die Kommunikation auch ziemlich nett gelöst hat: c't Lab

***Souko*** · July 20, 2009 at 9:17 AM

Quote

Original von Hendrik Hölscher
DMX braucht den USART.

Es bleibt SPI. Durch eine ringförmige Topologie könnte man einen Vollduplexbetrieb mit extremen Datendurchsatz realisieren. Es gibt auch einen Industriebus in dieser Art für Sensoren - der Name ist mir gerade entfallen...

Hendrik

Dieses Bussystem nennt sich ASI

Aktor
Sensor
Interface

Grüße, Souko

Hendrik Hölscher · July 20, 2009 at 9:19 AM

Yep - das wars.

Danke, souko.

We proudly present: The release of DMXControl 3.3.3!