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
Einen Sensor muss man in den seltensten Faellen ansteuern, allenfalls als Signalpegel messen. Um welche Art Sensoren geht es hier ?
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
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
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.
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?
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
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..?
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
Wieso willst du denn das Rad neu erfinden und Arbeit reinstecken für die Entwicklung? Wieso nimmst du nicht bestehende Systeme
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.
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
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
darüber sagt RS485 nix aus. spezifiziert nur die unterste schicht. wenn du es deinen sensoren beibringen kannst, gehts.
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
Midi schrieb: > leider wirst Du um die vorherige Zuweisung der Adressen nicht > herumkommen doch. für sowas gibts fertige protokolle.
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).
Hi
>n bisschen suchfaul bist du ja schon...
Irgendwie auch etwas denkfaul.
MfG Spess
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.)
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.
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
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
Bitte 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.