mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welcher Bus zur Ansteuerung von sensoren


Autor: Jonas Kraus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI Leute,

ich möchte über ein bedient gerät  verschiedene sensoren von Aussen 
ansteuern.

Ich weiß aber nicht welcher Bus ich nehmen soll. Welce für die steuerung 
geeignet wäre.
Die sensoren sind in einem Abstand von max 2m und   im Anzahl von 20.

Könte mir jemand was sinnvolles empfehlen??

Danke

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen Sensor muss man in den seltensten Faellen ansteuern, allenfalls 
als Signalpegel messen. Um welche Art Sensoren geht es hier ?

Autor: Jonas Kraus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es sind kapazitive Ultraschallsensoren  , die mit der Steuereinheit 
kommunizieren sollen.Im sensor ist ein µC integriert für seine 
Auswertroutine.
 Nack erkennung sollen sie Daten zur Master (Steuereinheit) über den Bus 
schicken. genauso wie der Master auch den Datenschicken Kann , damit der 
Sensor Irgendeine interne Treiber schalte.

Hoffe ist nun etwas klarer

danke
Jonas

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würd CAN nehmen.

Autor: Mathias O. (m-obi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meinst du vielleicht IO-Link?

http://de.wikipedia.org/wiki/IO-Link

Autor: Jonas Kraus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der Nachteil der IO_link ist dass er ein Punkt zu Punkt system ist.
das würde bei mir bedeuten  für 20 Sensoren 20 eingänge und entsprechend 
20 Verkabellung (=>Kabelsalat).

Ich habe die Idee ein Bus gehabt um den Kabelsalat zu vermeiden

Danke für Inputs

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit CAN umgehst du das ganze Kabelsalatproblem. Machst einfach eine 
Leitung von Sensor zu Sensor und im Stecker den "Stich" in´s Gerät.

Und µC mit CAN gibt es in allen möglichen Variationen, Leistungs- und 
Preisklassen.

Autor: Mathias O. (m-obi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
20 Eingänge ist doch nix. Bei unseren Maschinen kommen wir auf gut 
100-150 Eingänge.

Was hast du denn für eine SPS?

Hast du mal ein Datenblatt von den Sensoren?

Autor: Jonas Kraus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte soweit es geht keine SPS benutzen. Zum anderen habe ich keine 
und kenne mich auch nicht mit SPS aus.

gern wäre eine Kommunikaionsart ohne vie zu 
Installation/Einichtungsaufwand.  etwas flexibles

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur zum Verständnis...

Du möchtest sowohl das Bediengerät, als auch die Sensormodule selbst 
entickeln (Hardware und Firmware) und bist dabei noch völlig frei in der 
Wahl der µC etc..?

Autor: Jonas Kraus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja genau.
Ich möchte zuerst gern wissen welche Bussystem für die Kommunikation am 
sinvollsten ist , und daraus  die µC die das Kommunikationsprotookol 
unterstützt wählen

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, dann hab ich dich schon richtig verstanden ;-)

Autor: Mathias O. (m-obi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso willst du denn das Rad neu erfinden und Arbeit reinstecken für die 
Entwicklung? Wieso nimmst du nicht bestehende Systeme

Autor: Route_66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...weil er nicht mal richtiges Deutsch kann!

Autor: Jonas Kraus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antworten.

Übrigens, wir sind alle Menschen und jeder macht Fehler.

Zum thema
ich möchte nichts neues erfinden, dazu wird es noch paar Jahren dauern.
Ich möchte nur ein Empfehlung für ein Bussystem , das für die Aufgabe 
passend wäre.

Wenn  ich zum beispiel I2C-bus nehme,   habe ich der Nachteil ,
- das die Sensoren eine feste Adresse  bei der Programmierung zugewiesen 
bekommen. Das führt dazu , dass 2 Sensoren  mit der selben Adressen 
innerhalb der Bus nicht auftretten können(=> ansprechen von mehr als 1 
Sensor obwohl nur ein gemeint war).
- Nicht möglich alle Sensore eine neue Adresse zu vergeben.


Bei der SPI-Bus ist der Nachteil :
- für jeder Slave braucht man ein  Slave Select-Leitung .  Bei der 
Auswahl einem Steuernden µC mit festem Anzahl an SS-Leitung, ist die 
flexibilität begrenz wenn man später noch weitere sensoren dranhängen 
möchte.


Ich möchte gern  ein Bus mit Master-Slave Prinzip.  ich hoffe ihr hat 
eine schlauere Idee.

Danke Jonas S.

Autor: Jonas Kraus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hat keiner eine Idee??

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die hast du oben überlesen...

Autor: Midi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jonas,

von I2C und SPI solltest Du für Dein Vorhaben Abstand nehmen, denke ich. 
So, wie ich Dich verstehe, handelt es sich um Sensoren, die auch 
räumlich von der Zentraleinheit (dem "Master") getrennt sind. Sicherlich 
kann man I2C und SPI auch elektrisch robust übertragen bekommen, aber 
gedacht sind diese beiden Kommunikationswege eher für die Übertragung 
auf kurzen Strecken, z.B. auf einer Platine oder höchstens innerhalb 
eines Gerätes / einer Baugruppe.

CAN ist von Hause aus elektrisch robust ausgelegt. Aber je nachdem, wie 
das von Dir erdachte Kommunikationsmodell aussieht, könntest Du auch 
einfach eine serielle Schnittstelle mit RS485 Übertragung verwenden. Je 
nachdem, wie die Daten strukturiert sind, die Du übertragen möchtest, 
und wie häufig dies geschehen soll, kann dies sogar für Dich die 
sinnvollere Lösung sein.

Das Kommunikationsmodell von CAN ist auf häufige, konkurrierende 
Übertragung kurzer (z.B. 8 Byte) Datentelegramme optimiert. 
Datentelegramme werden von den Sensoren "ungefragt" auf den Bus gegeben, 
und wer sich dafür interessiert, nimmt die Werte entgegen. Anderes geht 
freilich auch, aber das o.g. ist seine Stärke. Da ist CAN auch richtig 
gut. Und standardisiert, das mag ebenfalls ein Vorteil sein.

Wenn der Master die Busarbitrierung übernimmt und die Slaves nur auf 
Anfrage aktiv werden und ggf. mit umfangreichen Datenblöcken antworten, 
würde ich persönlich noch zu der RS485 Lösung tendieren.

Hoffe, dass Dir das weiter hilft.


Viele Grüße und viel Erfolg,

  Midi

Autor: Jonas Kraus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi  Midi

vielen dank für deine ausführliche Antwort. Es ist eine so wie ich es 
brauche.

Gibt es eine Möglichkeit der RS485-Bus , dass der Master am Anfang 
Adressen an die bestehenden slave zuweist oder muss jeder Slave vor dem 
Anschluss an dem Bus eine feste Adresse anprogrammiert haben ?

Danke

Jonas

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
darüber sagt RS485 nix aus. spezifiziert nur die unterste schicht.
wenn du es deinen sensoren beibringen kannst, gehts.

Autor: Midi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Jonas,

leider wirst Du um die vorherige Zuweisung der Adressen nicht 
herumkommen, auf die eine oder andere Art und Weise, denn Du musst ja 
die Messdaten den Messstellen zuordnen können. Da macht aber auch CAN 
keinen Unterschied, es sei denn, der Chiphersteller hat bereits eine 
Arbitrierung über eine ab Werk fest vorgegebene Seriennummer vorgesehen. 
Ist aber dann in der Umsetzung einigermaßen kompliziert: Broadcast "wer 
ist alles da?" und in Abhängigkeit der Seriennummer antworten die 
einzelnen Geräte verzögert. Bei Kollisionen muss z.B. der mit der 
niedrigeren Seriennummer nochmals später senden usw. Alles ziemlich 
spaßfrei :-)

Wenn Du die Sensoren anfertigst, könntest Du ja z.B. selbst 
Seriennummern in die einzelnen Exemplare einbrennen und diese dann zur 
Adressierung verwenden. Alternativ reichen aber auch fünf Steckbrücken 
oder DIP-Schalter, über die Du die Geräteadresse dann später bei der 
Montage der Sensoren einstellen könntest. Fünf reichen, da an einem 
RS485 Bus nur maximal 32 Teilnehmer hängen dürfen, aber Du sprichst ja 
von 20 Sensoren, das sollte bei sorgfältiger Verkabelung und 
Terminierung recht gut klappen.


Viele Grüße,

  Midi

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Midi schrieb:
> leider wirst Du um die vorherige Zuweisung der Adressen nicht
> herumkommen
doch. für sowas gibts fertige protokolle.

Autor: Midi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yep, dann her damit :-)

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst Dir als Alternative zu CAN auch mal den 1-Wire-Bus ansehen. 
Ist etwas einfacher (zumindest die elektronische Seite) als CAN, jedoch 
musst Du für eigeme Endgeräte etwas tricksen (8-Bit IO-Modul bzw 
A/D-Wandler einsetzen oder einen 1-Wire-Slave in einem AVR/PIC 
nachbilden).

Das ganze ist aber nichts bei einer verseuchten (Störungsquellen) 
Umgebung.
Da ist CAN über RS485 eventuell besser (noch keine eigene Erfahrung).

Autor: Jonas Kraus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kann  man CAN und RS485  kombinieren ???
 Wie geht das?

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
n bisschen suchfaul bist du ja schon...

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>n bisschen suchfaul bist du ja schon...

Irgendwie auch etwas denkfaul.

MfG Spess

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jonas Kraus schrieb:
> kann  man CAN und RS485  kombinieren ???
>  Wie geht das?

CAN ist das Übertragunsprotokoll. RS485 die physikalische Übertragung.

(Oder habe ich da etwas nicht verstanden und erzähle Mist? Hatte noch 
nichts mit CAN zu tun.)

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian H. schrieb:
> CAN ist das Übertragunsprotokoll. RS485 die physikalische Übertragung.
can spezifiziert auch die hardware-ebene. z.b. bei der arbitrierung ist 
das wichtig.

> (Oder habe ich da etwas nicht verstanden und erzähle Mist? Hatte noch
> nichts mit CAN zu tun.)
ein klares: jein =)
man kann auch die oberen ebenen mit einer anderen physikalischen 
schnittstelle verwenden.

Autor: Midi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jonas,

(nochmal ich), 1-wire ist ebenfalls ursprünglich eher für die 
Kommunikation innerhalb von Baugruppen konzipiert worden, also in die 
Liga I2C und SPI einzuordnen.

CAN mit RS485 Übertragung wäre, wie Michael M. richtig anmerkt, eher 
esoterisch und eigentlich sogar kontraproduktiv, weil eine der Stärken 
von CAN in dessen Art der elektrischen Übertragung liegt. Der Vorteil, 
dass -egal ob zwei Geräte gleichzeitig senden- mindestens eines der 
Datentelegramme unversehrt (!) über den Bus geht, ginge dann verloren.


Viele Grüße,

  Midi

Autor: Midi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, nicht "mindestens" sondern "wenigstens"... ;-)

Autor: B e r n d W. (smiley46)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für CAN braucht man spezielle CAN-Schnittstellen oder CPUs mit 
integriertem CAN plus Bustreiber. Ich bin mir nicht sicher, ob nach dem 
Ersetzen eines CAN Bustreibers durch RS485 die Kollisionserkennung noch 
richtig funktioniert.

Vorteile von CAN:  Eingebaute Kollisionserkennung und Fehlersicherheit. 
Mehrere Master möglich.
Nachteil: Es haben nur 8 Datenbytes Platz. Spezielle Hardware notwendig.

RS485: Diese kann über den UART betrieben werden. Für das Protokoll hat 
man jegliche Freiheiten, d.h. es kann selbst definiert werden. 
Reichweite 1km. Größere Datenpakete möglich. Dafür muß man aber für die 
Korrektheit der Daten per Checksumme CRC ... selbst sorgen.

Gruß, Bernd

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.