Hallo zusammen So einen ähnlichen Thread gabs schonmal hier: Beitrag "Multiplexer für CAN-Bus" Aber da ganz unten steht: >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. Also hier die Frage: Ich will einen CAN-Bus (eigentlich zwei, aber das tut nichts zur Sache) zwischen mehreren Leitungen umschalten, will aber auf keinen Fall Relais verwenden. Das Umschalten soll natürlich per Software geschehen. Was für Möglichkeiten hab ich da? Analogschalter vielleicht? Wie siehts da mit Strom aus? Digital wirds nicht gehn, da die Spannungen beim CAN-Bus ja um 2,5V liegen. (Wie CAN funktioniert weiß ich schon, also dazu bitte keine Erklärungen) Zusätzliche Infos: CAN Tranceiver: TJA1040 Baudrate: 1Mbit/s Maximale Anzahl Busteilnehmer: 110 (Aus dem Datasheet vom TJA1040, werden whs nur so um 30 bis 40 aber vorsehen will ichs trotzdem)
An jeder Leitung einen TJA1040 und dahinter einen Multiplexer zum Controller. Das mit dem Analogschalter wird so wahrscheinlich nicht funktionieren weil die zu hochohmig sind. Was spricht gegen Relais ?
Wenn Du es so machen möchtest, würde ich Dir unbedingt ein Multiplexing hinter dem Transceiver anraten, d.h. auf der TTL-Ebene. Das ist dann ja relativ einfach mit Logikgattern bzw. Analogschaltern zu realisieren. Analogschalter auf der physikalischen Busebene (d.h. vor dem Transceiver) müssten immer gewisse Störfestigkeiten aufweisen und die gleichen Common-Mode Eigenschaften wie der Transceiver-Baustein aufweisen. Außerhalb des Labortisches würde ich das auf keinen Fall mit Analogschaltern o.ä. machen. Höchstens mit Relais, aber das scheidet ja aus.
Kann man denn die Notwendigkeit der Umschaltung nicht durch geeignete Adressierung vermeiden? Wenn man Tranceiver verwendet, um die Pegel auf CMOS zu bekommen, sollte eine Umschaltung kein Probkem sein. Warum sollen eigentlich keine Relais verwendet werden? Grüße, Peter
Problem bei der Lösung mit den mehreren Tranceivern ist, dass ich dann statt zwei Tranceiver 14 Tranceiver benötigen würde. Umschalten mit Relais fällt aus dem selben Grund flach --> 14 Relais. Zur Notwendigkeit des Umschaltens: Wir entwickeln zur Zeit ein System, das intern über 7 CAN-Bus-Systeme kommunizier. Sieben weil so zum einen mehr Datenrate zur Verfügung steht und zum anderen die Bussysteme nach Funktionsbereichen der einzelnen Busteilnehmer aufgeteilt werden können. Die Adressierung ist festgelegt (Seriennummer des einzelnen Busteilnehmers als Identifier) Was ich vermeiden will ist dass die Karten nachdem sie hergestellt worden sind noch manuell (per Lötbrücke oder Jumper) konfiguriert werden müssen. Das stellt einen zusätzlichen Prozessschritt dar und kostet, meiner Meinung nach, unnötig Geld.
Hi Sven, so richtig kapier ich noch nicht warum ihr Multiplexen wollte. Du schreibst: Sven H. schrieb: > Sieben weil so zum einen mehr Datenrate zur Verfügung steht > und zum anderen die Bussysteme nach Funktionsbereichen der einzelnen > Busteilnehmer aufgeteilt werden können. Die Datenrate wird doch durch das Mux nicht größer. Man bekommt nicht mehr Bits hintereinander auf die Leitung als wenn alle Teilnehmer gleichberechtigt am Bus teilnehmen. Die Datenrate wird sogar noch kleiner, weil du Zeit zum Umschalten benötigst. Wie ich gerade schon schrieb, kann man die Funktionstrennung auch durch mehrere Busteilnehmer erhalten (dafür ist ja ein Bus da). Das einzige Argument was ich verstehen kann ist, dass du die Anzahl der Transceiver reduzieren möchtest. Aber die werden wohl nur einen kleinen Teil der Gesamtkosten einnehmen. Bitte erklär mal etwas genauer: >Wir entwickeln zur Zeit ein System, das intern über 7 CAN-Bus-Systeme >kommunizier. So hab ich es bisher verstanden: Es gibt in eurem Gerät eine unbekannte Anzahl an Baugruppen die in sieben Funktionsbereiche unterteilt werden. Jede Baugruppe eines Funktionsbereiches kommuniziert über einen eigenen CAN-Bus. Also hat doch jede Baugruppe ihren eigenen Controller und Transceiver. Und umschalten/multiplexen willst du nun den Bus der aus eurer Hardware nach außen geht? Wie wäre es mit einem Gateway? Weil eben nicht mehr Bits auf die Leitung passen. Ok ein Gateway-Controller mit acht Kanälen ist schwer zu finden, aber für sechs würde mir sofort einer einfallen. Aber zur Not würde es ein FPGA auch schaffen. Gruß, TManiac
Wir haben mehrere Bussysteme, weil das System insgesamt mehr Rate benötigt. Die verschiedenen Teilnehmer werden also je nach Funktion auf den ein oder anderen Bus geschaltet. Da die Karten sich nur durch die Software unterscheiden müssen wir die Verbindung zum Gesamtsystem dynamisch umschalten können.
Angehängte Dateien:
-
CAN_System.png
2,8 KB
Noch einmal fragend. Deiner letzten Beschreibung entnehme ich das eurer System ähnlich meiner Skizze aussieht? Das sind dann aber doch in meinem Beispiel drei (in eurem sieben) sperarate System. Es fließen ja keine Informationen von einem System in das Andere. Oder hast du daher von Anfang an immer zwei Umschaltern geredet weil jeder Teilnehmer auf zwei Busse aufgeschaltet werden soll. Soll die Umkonfiguration auf die verschiedene Systeme auch im Betrieb ablaufen? Wenn nicht ließe sich doch das ganze wesentlich günstiger in der Verkabelung realisieren. TManiac (vor der Lösung eines Problems muss dieses erst einmal vollständig erkannt und verstanden werden)
Sven H. schrieb: > Wir haben mehrere Bussysteme, weil das System insgesamt mehr Rate > benötigt. Die verschiedenen Teilnehmer werden also je nach Funktion auf Und warum habt ihr euch dann für einen CAN-Bus entschieden? Kommt mir irgendwie so vor als soll jetzt mit einer Krücke ein Konzept gerettet werden das von Anfang an nicht zur Aufgabenstellung passte. CAN ist nicht gerade ideal für hohe Datenraten. Was spricht denn gegen Ethernet? Matthias
Sven H. schrieb: > Problem bei der Lösung mit den mehreren Tranceivern ist, dass ich dann > statt zwei Tranceiver 14 Tranceiver benötigen würde. Welche Multiplex-Lösung soll denn effektiv weniger Platz benötigen (pro Kanal) als ein SO-8 Gehäuse. Und welche Lösung soll preislich günstiger werden als 14 einzelne CAN-Transceiver? Nebst Schutzbeschaltung wird jede Umschalterei mit MOSFETs oder was auch immer im Endeffekt teurer. Sven H. schrieb: > Wir haben mehrere Bussysteme, weil das System insgesamt mehr Rate > benötigt. Auch das mit der höheren Rate verstehe ich (auch) nicht.
Über welche Buslängen unterhalten wir uns denn gerade?
Μαtthias W. schrieb: > Sven H. schrieb: >> Wir haben mehrere Bussysteme, weil das System insgesamt mehr Rate >> benötigt. Die verschiedenen Teilnehmer werden also je nach Funktion auf > > Und warum habt ihr euch dann für einen CAN-Bus entschieden? Kommt mir > irgendwie so vor als soll jetzt mit einer Krücke ein Konzept gerettet > werden das von Anfang an nicht zur Aufgabenstellung passte. CAN ist > nicht gerade ideal für hohe Datenraten. Was spricht denn gegen Ethernet? > > Matthias Das Problem bei Verkabelung ist, dass ein weiterer Prozessschritt eingeführt werden muss. Das führt zwangsläufig zu weiteren Fehlern. Also will ich das vermeiden. Gegen Ethernet spricht nur einer meiner Kollegen, der nicht zu überzeugen ist. Das war auch mein erster Ansatz. Frank K. schrieb: > Über welche Buslängen unterhalten wir uns denn gerade? Die Teilnehmer kommunizieren innerhalb eines 19'' Gehäuses miteinander. Vielleicht kommt noch ein zweites Gehäuse oben drauf. Die Maximale Buslänge sollte somit zwei bis drei Meter von Tranceiver zu Tranceiver nicht überschreiten. Und, natürlich wird die Rate durch das verwenden mehrerer paralleler Bussysteme insgesamt größer. Ein Beispiel: Karte 1 kommuniziert mit Karte 2. Dabei werden Haufenweise AD-Werte übertragen. 250KS/s mit 16 Bit. Da wirds mit einem 1Mbit-Bus schon arg eng. Jetzt muss aber Karte 1 noch unbedingt mit Karte 3 kommunizieren um irgendeinen digitalen Ausgang zu setzen. Dieser Befehl "passt" aber schlicht und einfach nicht mehr auf den ersten Bus und muss somit "ausgelagert" werden. Unter anderem aber auch auf Grund der Tatsache, dass einige Karten schon entwickelt sind sind wir an den CAN-Bus (und zwar sieben, von denen einer auf alle Client-Karten geführt wird und die anderen je nach Funktion oder Auslastung verteilt werden) gebunden.
voll dämliches Konzept. Hat sich niemand vorher darüber Gedanken gemacht? Wie wäre es denn mit einer Art Switch-Karte, die dann die Datenleitungen zwischen den einzelnen Slave verbindet.
Klingt nach fast vollendeter Punkt zu Punkt Verkabelung, bei der jede Node grad versucht, eine Node anzusprechen, die z.Zt. nicht zuhören kann, weil sie grad auf einem anderen Kanal versucht, eine andere Node anzusprechen, die z.Zt. nicht zuhören kann, weil sie grad auf einem anderen Kanal ...
Nunja. Mein Problem ist, ich muss damit leben und versuchen das beste drauß zu machen. Es gibt halt Kollegen, die erstellen ein Konzept, schmeißen einem den Kram vor die Füße, ziehen sich zurück, wenns knifflig wird und verkaufen es dann am Ende, wenn alles funktioniert, als ihr eigenes tolles Konzept und realisiert haben die natürlich auch alles alleine.
A. K. schrieb: > Klingt nach fast vollendeter Punkt zu Punkt Verkabelung, bei der jede > Node grad versucht, eine Node anzusprechen, die z.Zt. nicht zuhören > kann, weil sie grad auf einem anderen Kanal versucht, eine andere Node > anzusprechen, die z.Zt. nicht zuhören kann, weil sie grad auf einem > anderen Kanal ... Das wäre wohl so, wenn nicht zwei Punkte dagegen sprechen: 1. Ein Bus geht zu allen Teilnehmern. Über diesen kann eine Synchronisation stattfinden. 2. Es gibt eine "Master-Karte" von der aus sämtliche Kommunikation in die Wege geleitet wird.
Sven H. schrieb: > Es gibt halt Kollegen, die erstellen ein Konzept, schmeißen einem den > Kram vor die Füße, ziehen sich zurück, wenns knifflig wird und verkaufen > es dann am Ende, wenn alles funktioniert, als Ihr eigenes tolles Konzept > und realisiert haben die alles alleine. Klassische Team-Arbeit... ;) Sven H. schrieb: > Unter anderem aber auch auf Grund der Tatsache, dass einige Karten schon > entwickelt sind sind wir an den CAN-Bus (und zwar sieben, von denen > einer auf alle Client-Karten geführt wird und die anderen je nach > Funktion oder Auslastung verteilt werden) gebunden. Eine Karte hat 7 CAN-Schnittstellen? Wieviele Karten stecken den in dem ganzen System? Ich würde auch zentrale Multiplex-Karten aufbauen, die eine gewisse Menge Eingänge wahlfrei auf eine gewissen Menge Ausgänge schalten kann. Eine Schaltmatrix...
Für solche Sachen könnte man vermutlich auch solche fertigen Systeme wie PXI verwenden.
> Ein Beispiel: Karte 1 kommuniziert mit Karte 2. Dabei werden Haufenweise > AD-Werte übertragen. 250KS/s mit 16 Bit. Da wirds mit einem 1Mbit-Bus > schon arg eng. > Jetzt muss aber Karte 1 noch unbedingt mit Karte 3 kommunizieren um > irgendeinen digitalen Ausgang zu setzen. Dieser Befehl "passt" aber > schlicht und einfach nicht mehr auf den ersten Bus und muss somit > "ausgelagert" werden. Aha, und nach dem Umschalten kommuniziert Karte 1 mit Karte 3 und nicht mehr mit Karte 2 oder wie ? Deine Beschreibung des Systems ist für die Tonne !
Das Konzept ist ungeeignet. FlexRay währe eine Option. http://de.wikipedia.org/wiki/FlexRay Aber zurück zum Thema: Nimm z.B den sn65hvd254 als Transceiver. Der hat einen Enable-Eingang. http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65hvd253&fileType=pdf Du must nur noch die R-Pins verodern. Also 7 Transceiver und ein 8-Fach-Oder-IC. Billiger wirds nicht. ciao Volker
Oder nimm ein Controller von Luminary http://www.luminarymicro.com/products/product_selector_guide.html Die haben bis zu 3 CAN-Controller onboard. Nimm zwei Busse für das Daten schaufeln und einen für Verwaltungszwecke.
Angehängte Dateien:
-
system.png
1,2 KB
Ich versuch nochmal das System zu erklären. Es laufen im 19'' Gehäuse 7 CAN-Bussysteme parallel. Ein Teilnehmer (Master) ist fest mit allen Bussystemen verbunden. Jeder Slave ist fest mit dem ersten CAN-Bus (schwarz) verbunden. Jeder Slave soll mit der gleichen Software laufen. (!!!) Je nach Funktion des Slaves (Spannungen messen, digitale Ausgänge schalten, Spannungen ausgeben...) soll er mit einem anderen CAN-Bussystem verbunden werden. Die Funktion des Slaves wird in einem EEPROM auf der Karte selber abgelegt. Die Software weiß also, was die Funktion der Karte ist. --> Klare Trennung der Bussysteme nach Funktion. --> Fehlersuche vereinfacht sich, da ich, wenn ich den Fehler bei der digitalen Ausgabe sehe, nicht auf sieben Systemen schnüffeln muss, sondern nur auf einem. Ich hätte gerne nachträgliche Lötarbeit vermieden, da das, wie schon öfters gesagt, einen zusätzlichen Prozessschritt dar stellt. Bei ein, zwei Karten und bei Prototypen sicherlich kein Problem, allerdings sollen die Karten vom Lieferanten direkt ans Lager gehen und von dort aus in der Fertigung eingesetzt werden.
Geht es jetzt nur um die Slaves oder auch um den Master? Was ist die maximale Anzahl der gleichzeitig betriebenen Busse an den Slaves? Was ist die maximale Anzahl der gleichzeitig betriebenen Busse beim Master? Wie viele CAN-Controller haben deine jetzigen µC on-board? 250KS/s mit 16 Bit = 4MBits/s. + Overhead >= 5 MBits/s. Du must also min. 5 Busse gleichzeitig betreiben. Das Konzept geht nie auf!!!
Sven H. schrieb: > Ich hätte gerne nachträgliche Lötarbeit vermieden, da das, wie schon > öfters gesagt, einen zusätzlichen Prozessschritt dar stellt. Bei ein, > zwei Karten und bei Prototypen sicherlich kein Problem, allerdings > sollen die Karten vom Lieferanten direkt ans Lager gehen und von dort > aus in der Fertigung eingesetzt werden. Anders ausgedrückt: Das Kommunikationssystem wird kurz mit 2 Karten getestet und anschliessend ohne Realtest sofort im Vollausbau produktiv beim Kunden eingesetzt? Na denn, viel Vergnügen. Hoffentlich nimmt niemand Schaden.
Ich frage mich, warum ihr euch den Kopf über das Konzept zerbrecht, wenn die Frage doch recht eindeutig formuliert war. Das Konzept ist in Zement gegossen und steht hier nicht zur Diskussion. Es tut mir Leid, dass ich euch mit den Einzelheiten konfrontiert habe, was offensichtlich dazu geführt hat, dass die eigentliche Frage aus dem Blick geraten ist. Also nochmal die Frage: Wie schalte ich CAN-Busse um. Ohne Relais. Offensichtlich gibt es zwei Lösungen: 1. Lass es sein. 2. Schalte die digitalen Signale vor den Tranceivern um. -> Erhöhte Tranceiveranzahl. Ich denke, die Diskussion kann damit als beendet angesehen werden. Vielen Dank für die Hilfe.
>Offensichtlich gibt es zwei Lösungen: >1. Lass es sein. >2. Schalte die digitalen Signale vor den Tranceivern um. -> Erhöhte >Tranceiveranzahl. >Ich denke, die Diskussion kann damit als beendet angesehen werden. >Vielen Dank für die Hilfe. >Jeder Slave ist fest mit dem ersten CAN-Bus (schwarz) verbunden. Wieviele Schnittstellen hat denn jeder Slave? 2? 3? 7?
...ruf doch einfach mal bei irgendwem der distris oder transceiver-hersteller an? ich habe da auch so meine bedenken, aber wenn ihr nicht die ganz harten CAN specs erfüllen müsst, geht es ggf mit analog-schaltern (die im übrigen teilweise auch nur wenige ohm haben) und einem GEEIGNETEN layout. ich hoffe vielmehr, dass ihr noch die zeit habt, das sauber testen/stressen zu können...sonst wars das mit der ersparnis :) Klaus.
STK500-Besitzer schrieb: > Wieviele Schnittstellen hat denn jeder Slave? 2? 3? 7? Jeder Slave hat 3 Schnittstellen von denen eine fest verbunden ist und die anderen eben, je nach Funktion anders verbunden wird. Ich bin parallel mit dem Hardwareentwickler unseres Lieferanten in kontakt getreten und er sieht auch keine andere Möglichkeit als die beiden schon genannten. Ich werde dann wohl doch Lötjumper verwenden, die aber vom Lieferanten löten lassen. Somit erübrigt sich die Fehlerquelle und der Prozessschritt bei uns im Haus.
>Jeder Slave hat 3 Schnittstellen von denen eine fest verbunden ist und >die anderen eben, je nach Funktion anders verbunden wird. Ihr habt vermutlich keine Möglichkeit, noch eine Art CAN-Routing MAtrix mit zu entwickeln bzw. einzubauen. Da würde man dann die "freien" CAN-Anschlüsse draufführen und entsprechend der angeforderten Verbindung routen. Das wäre vermutlich noch mal eine eigene 19"-Kiste ;)
STK500-Besitzer schrieb: > CAN-Routing MAtrix Ein Routing nützt Ihm nichts. Seine Busse sind voll ausgelastet. Du kannst nicht den Verkehr über einen Bus zum anderen routen. Was noch helfen könnte, ist die Anlyse ob jeder CAN-Controller auf jeden BUS zugreiffen mus. Dies könnte im besten Falle dazu führen das beide CAN-Controller jeweils nur auf drei Busse schaltbar sein müßten. Diese Analyse würde auch die Anzahl der Lötjumper, und damit die Fehlerwahrscheinlichkeit reduzieren.
Volker Zabe schrieb: > Was noch helfen könnte, ist die Anlyse ob jeder CAN-Controller auf jeden > BUS zugreiffen mus. Das ist auf jeden Fall eine gute Idee. Ich werd das alles nochmal durchspielen. Vielen Dank!
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.