Hallo, liebe MoBa-Freunde,
ich beschäftige mich gerade, nach jahrzehntelanger Abstinenz, wieder etwas mit dem Thema Modellbahn und lerne gerade diesbezüglich eine "digitale" Sichtweise aufzubauen.
Projektiert ist eine Märklin-H0-Anlage (Gleisbox, zwei MS2) mit kleinem Bahnhof, Gütersackgleis, Lokbahnhof und -an den Bahnhofsausfahrten- jeweils eine verdeckte Wendeschleife. Im Hinblick auf "narrensicheren" Betrieb, auch bei fahrdiensttechnischer Hilfe durch meine achtjährige Tochter ;o) , möchte ich den Schattenbetrieb in den Wendeschleifen automatisch ablaufen lassen. D.h. wenn die Züge in die nichteinsehbaren Bereiche einfahren, sollen sie keine manuellen Steuerbefehle mehr annehmen und mit einer "vernünftigen" Geschwindigkeit diesen Bereich befahren, bevor sie nach Wiedererscheinen vom hocherfreuten Bahnpersonal wieder manuell dirigiert werden können.
Früher, analog, ganz einfach durch einen getrennten Fahrstromkreis mit einem zusätzlichen, fest eingestellten und nicht manuell zu bedienenden Trafo realisierbar.
Im Digitalbetrieb ist das kein triviales Problem, denn die MS2 ist über die Gleisbox direkt mit dem Gleis verbunden und kann nicht mit dem Computer/ der Software kommunizieren. Vom Computer automatisch an Züge, Weichen, Signale gegebene Befehle können jederzeit durch Eingaben an der/ den MS2 ausgehebelt werden, wenn die passende Adresse eingestellt ist.
Im Zuge meines Bewusstwerdungsprozesses habe ich auch mit Herrn Freiwald (TC) kommuniziert, der mir die o.g. Zusammenhänge erklärt hat. Bei ihm kann man dazu ein Eingabegerät erwerben (+SmartHand), das -einstellbar- für bestimmte Blockabschnitte keine manuellen Eingaben akzeptiert. Dieses Gerät muss dann, für mich auch nachvollziehbar, direkt mit einem Interface an den Computer angeschlossen werden. Ans Gleis gehen dann nur Informationen, wenn sich das Eingabegerät und die Software über die Zuständigkeit geeinigt haben.
Eine solche Funktion scheint mir für den seltenen Fall ;o), dass jemand neben der Sicherung durch den Computer auch manuell "spielen" möchte äußerst wichtig.
Allerdings sind diese Geräte sehr teuer und hinken meiner Meinung nach in Design und Anzeige den mir sehr sympathischen MS2 hinterher.
Lange Einleitung, kurze Frage:
Ist es prinzipiell möglich, die MS2 in ähnlicher Weise funktionell (und falls möglich: in absehbarer Zeit) in das CAN-digital-Bahn-System einzubinden? vielleicht mit einer (versteckten) MS2 an üblicher Stelle als Datenbank?
Hallo!
Hier nochmal eine "Anfänger"-Frage zur ursprünglichen Forderung (keine Zugbeeinflussung durch MS2 in bestimmten Gleisabschnitten).
Ist es möglich, den von der Gleisbox ausgegebenen "Digitalstrom" durch einfache Filter (Dioden, Kondensatoren, Optokoppler) für isolierte Gleisstücke so zu filtern, dass er keine Steuerinformationen mehr enthält? Würde der Zug dann mit den letzten erkannten Steuerbefehlen weiterfahren? Und braucht man dann noch ein Übergangsgleisstück/ eine Wippe für den Schleifer?
Beiträge: 2257 Ort: in der Lampe Eingetreten: 03.06.10 Status: Offline
Eingetragen am 26.10.2013 11:38
Hallo Sascha,
ich habe da selber noch nichts probiert. Die Märklin-Bremsstrecke macht es mit einer negativen Spannung am Gleis, dann bleibt die Lok stehen. Denke mit einer positiven sollte es gehen. Vermutlich darf man analog dann aber nicht ausschalten... Einfach mal probieren.
mobajo schrieb:Dein vorhaben, ein CAN-Ethernet-Gateway zu schaffen ist sicher auch für viele hier interessant und ermöglicht erst die Anbindung mancher Bediengeräte ohne CS2. Das finde ich echt klasse! Dafür ist auch Deine Hardwarewahl sicher perfekt.
Danke. :-)
Bei dem Projekt sind noch weitere Leute im Boot. Ich selbst kann ja keine Hardware entwicklen. Hab aber ein schönes flexibles Framework erstellt. Wenn jetzt der Winter kommt, finde ich bestimmt auch wieder Zeit, dort weiter zu programmieren. Da das alles unter GPL steht, kann jeder unsere Lösung einsetzen. Mir würde es gefallen, wenn andere die Lösung so brauchbar finden, daß sie sie einsetzen.
Ich denke auch, daß das BBB dafür eine gute Lösung ist. Das hat einen CAN und einen Ethernet Controller und ist nur wenig teurer als ein RPI. Und mit Linux habe ich eine sehr komfortable und mächtige Basis für die Software. Das war deshalb der Vorschlag eines Bekannten, der das Tranceiverboard gebaut hat.
Quote
mobajo schrieb:Wenn es um präzises Steuern direkt über den PC geht, ist das über Ethernet nicht unmöglich, aber doch deutlich schwieriger um zu setzen, wie über USB. Man sollte dabei bedenken, dass nicht jeder Modellbahner hier auch IT-Profi ist. Und über Ethernet können viel mehr Dinge Einfluss auf die Laufzeiten der Meldungen habe.
Je nachdem, was wie gesteuert werden muß, würde ich bei mir auch Aufgaben auf dem BBB laufen lassen. Das Board hat genug Resourcen und ist direkt Teilnehmer am CAN Bus. Dann fällt der Weg über Ethernet weg. Für deine etwas komplexeren und dynamischen Filter läßt sich sicherlich so etwas wie eine Ablaufsteuerung entwicklen. Also einen Interpreter, der so etwas wie einen Ablauf für Filter aus einer Datei liest und dann in Abhängigkeit von Ereignissen, Rückmeldekontakten, ... gewisse Filterregeln anwendet. Wahrscheinlich braucht man dazu keinen eigentlichen komplexen Ablauf sondern nur entsprechend mächtige Regel. Ich wollte jetzt nicht ein solches System entwerfen und das vertiefen, aber so schwer klingt das für mich jetzt auch nicht.
Quote
mobajo schrieb: Das stimmt so nicht. Das Tranceiverboard für meinen BBB hat eine galvanische Trennung.
Dann ist das eine sehr positive Ausnahme. Bei Raspberry, Arduino und co. ist der CAN-Bus gegenüber dem Gerät normal nicht isoliert. Bei Deiner Anwendung ist das nicht so von Bedeutung, aber wenn beide CAN-Bus-Interfaces des Filterbausteins Verbindungen Richtung Modellbahn haben, birgt das sonst doch erhebliche Gefahren, dass Bausteine zerstört werden könnten.
Das Cape mit dem Tranceiver hat mein Bekannter gebaut. Das ist keine fertige Lösung. Und auf meinen Wunsch sitzt auf meinem Prototyp eine RJ45 Buchse für den CAN Anschluß. Damit läßt sich das wie ein weiteres Modul anschließen.
Quote
mobajo schrieb:Aber das bedeutet ein einfacheres Steuerprogramm unter einem WEB-Server integrieren zu müssen. Ist schon eine ganz schöne Herausforderung.
Nö eigentlich nicht. Ok, ich schreibe beruflich Software für Embedded Systems unter Linux. da empfinde ich das jetzt nicht mehr als Herausforderung. Solche Aufgaben sind quasi so etwas wie "täglich Brot". Und die für die Standard-Protokolle (Webserver) gibt es ja schon Lösungen. Da würde z.B. nur ein CGI-Script fehlen, das dann die neue Konfiguration an die laufende Software weitergibt oder auch nur Konfigdateien füllt. Kann eigentlich nicht mehr so schwer sein.
Quote
mobajo schrieb:Wenn es so einen Baustein in ausgereifter Version zu kaufen gäbe, wäre ich dabei. Solche Bausteine sind von dem Lebenszyklus viel passender zur Modellbahn, wie normale PCs (Lebenszyklus im Schnitt 3 Jahre). Ich habe aber etwas derartiges noch nirgends gefunden. Das selber zu programmieren verhindert zunindest im Moment die verfügbare Zeit.
Ja, von meiner beruflichen Seite und meiner Technikseite ist der schnelle Wechsel interessant. Als Anwender stört es mich teilweise schon. Ich hoffe, daß diese kleinen Boards etwas länger verfügbar sind bzw. der Nachfolger so kompatibel, daß Erweiterungen passen. Immerhin sind wir ja dabei näher an typischen Embedded Systems, die auch eine längere Lebensdauer haben. Zeit dafür ist leider immer ein Problem. Ich hätte auch mehr Ideen als Zeit. Aber die Entwicklung auf dem BBB für Linux ist recht einfach. Man kann bequem in einer Hochsprache entwickeln. Um die Hardware kümmert sich Linux.
ST-Oldie schrieb: Das stimmt so nicht. Das Tranceiverboard für meinen BBB hat eine galvanische Trennung.
Quote
mobajo schrieb: Dann ist das eine sehr positive Ausnahme. Bei Raspberry, Arduino und co. ist der CAN-Bus gegenüber dem Gerät normal nicht isoliert. Bei Deiner Anwendung ist das nicht so von Bedeutung, aber wenn beide CAN-Bus-Interfaces des Filterbausteins Verbindungen Richtung Modellbahn haben, birgt das sonst doch erhebliche Gefahren, dass Bausteine zerstört werden könnten.
Quote
ST-Oldie schrieb: Das Cape mit dem Tranceiver hat mein Bekannter gebaut. Das ist keine fertige Lösung. Und auf meinen Wunsch sitzt auf meinem Prototyp eine RJ45 Buchse für den CAN Anschluß. Damit läßt sich das wie ein weiteres Modul anschließen.
Wer den Nachbau scheut kann auch ein fertiges Modul (incl. galvanischer Trennung) für den
BeagleBone Black verwenden:
http://www.tigal.com/product/2734
Macht dann:
BeagleBone Black 39€
Canbus Cape 53€
Summe 92€
auch ich finde die angedeuteten alternativen Lösungen, die in den letzten Beiträgen diskutiert wurde, durchaus interessant. Habe ich irgendwelche direkt weiterführende Links übersehen? Wo finde ich die Beschreibung der "selber-Bastellösung"?
Aber um mal zur Eingangsproblematik dieses Themas zurückzukommen:
Ich schlage mich schon seit längerer Zeit mit einem ähnlich gelagerten Problem herum.
Bei den aktuell verfügbaren Steuerungsprogrammen müssen alle externen Eingabe-Geräte, mit denen die Loks gesteuert werden sollen, am selben Digitalsystem hängen, das auch die Fahrbefehle an die Anlage sendet. Damit ergibt sich ja auch das Problem im Eingangspost.
Ich habe Handregler für ein Digitalsystem, daß ansonsten nur das Feedback von der Anlage transportiert. Die Digitalsignale für Schalten der Magnetartikel und Loks laufen über ein anderes Digitalsystem. Das ist bei mir so historisch gewachsen. Leider verweigern aber alle Programmhersteller die Annahme von Handregler-Befehlen aus einem Digitalsystem, das nicht direkt die Loks steuert.
Das ist natürlich sehr fatal, da ja daraus auch das Problem aus dem Eingangspost resultiert. Jeder Handregler-Befehl wirkt direkt auf die Lok, ohne vom Steuerungsprogramm kontrolliert werden zu können.
Mein "Wunsch" würde auch hier Abhilfe schaffen, da ja jetzt erst das Programm den Steuerbefehl analysieren muß und somit die Möglichkeit hat, nur "zulässige" Fahrbefehle an das die Loks ansprechende Digitalsystem weiter zu leiten.
Mit der in den letzten Beiträgen genannten alternativen Hardware könnte das "zweite" System dargestellt werden. Allerdings müssen natürlich dann die Steuerungsprogramme auch noch die Erweiterung erhalten, meine oben genannte Anforderung zu erfüllen. Somit wären auch die in den ersten Beiträgen diskutierten Probleme gelöst.
Ich hoffe, ich habe die vorangegangenen Beiträge richtig interpretiert und Euch nicht all zu sehr verwirrt.
das Problem bei Deiner Frage "den Digitalstrom so filtern, dass die Lok einfach weiter fährt" ist, dass da jeder Decodertyp anders reagiert. -> Wenn Du nur eine begrenzte Zahl an Decodertypen in Deinen Fahrzeugen hast und ausschließen kannst, dass keine anderen Typen dazu kommen, kann man das ausprobieren. Dazu musst Du dann aber die Decoder auch entsprechend einstellen. Ein paar Beispiele dazu:
- Negative Spannung ans Gleis (Schienen +, Mittelleiter -), dann muss die Märklin-Bremsstrecke in den Decodern deaktiviert sein und auch DC-analog, dann könnte es klappen. Aber z.B. bei den Märklin-Decodern 6090x kannst Du die Bremsstrecke nicht deaktivieren. Wie sie auf DC-analog reagieren weiß ich nicht.
- Positive Spannung ans Gleis: Zumindest DC-analog muss deaktiviert sein. Es gibt dann aber auch Decoder, die bremsen, wenn sie kein Digitalsignal mehr sehen.
In beiden Fällen hast Du über eine Diode die Chance einen Übergangsbereich für den Schleifer zu machen, in dem nur die negative oder positive Hälfte des Digitalsignals an liegt. So wie das beim Bremsmodul von Märklin auch gemacht ist. Dadurch ist ein etwas besserer Schutz gegen das Zusammenbringen der beiden Spannungen gegeben, was durchaus die Gleisbox beschädigen könnte.
Alles was bipolare Signale in dem gefilterten Bereich verwendet ist doch sehr kritisch, bezüglich dass die beiden Stromkreise verbunden werden könnten. Da funktioniert so ein Übergangsbereich nicht wirklich. Das betrifft sowohl Wechselspannung, als auch ein anderes Digitalsignal, entweder mit definierten Fahrstufenbefehlen für die Loks, oder eben ein Digitalsignal ohne Lokbefehle (damit würden die Loks, abgesehen von bestimmten MFX-Decodern einfach mit der letzten Fahrstufe weiter fahren). So etwas würde ich bei mir aber nur einsetzen, wenn ich einen Gleisabschnitt umschalten könnte, der länger ist, wie der längste Zug. Ferner würde ich die Anordnung so aufbauen, dass zwischen den unterschiedlichen Digitalsignalen immer eine Schiene komplett stromlos ist. Dazu noch eine Überwachung, dass wenn in die stromlose Schiene eingefahren wird (z.B. mit einem geschobenen Zug), dass dann die Anlage auf Nothalt geht. Nur so kann man sich zuverlässig gegen Schäden schützen, die entstehen würden, wenn die beiden Spannungen zusammen kämen. -> Ist relativ aufwendig und man braucht ausreichend lange Streckenabschnitte ohne Weichen dazwischen, was für viele ein Problem sein dürfte.
auch ich finde die angedeuteten alternativen Lösungen, die in den letzten Beiträgen diskutiert wurde, durchaus interessant. Habe ich irgendwelche direkt weiterführende Links übersehen? Wo finde ich die Beschreibung der "selber-Bastellösung"?
Im Grunde braucht man nur 6 Kondensatoren, 4 Widerstände, ein ISO1050 Tranceiver, ein Linearregler und ein
BeagleBone Black. Und schon hat man ein netzwerkfähigen CAN Anschluss für kleines Geld. Zudem bietet das BBB
noch eine Menge andere Möglichkeiten. Ein zweites CAN Interface wäre auch möglich.
Es spricht nichts dagegen, das auch die CAN-digital-Bahn Komponenten laufen.
Das ganze ist (momentan) für Bastler gedacht. Ich habe leider momentan wenig Zeit und mangelnde Erfahrung eine
"professionelle" Platine zu erstellen bzw. fertigen zu lassen. Ich hätte nichts dagegen, wenn jemand das "Design"
überarbeitet und vertreibt. IMHO könnte man Michaels Drehscheibe erweitern und Filter, Umsetzer etc. pp bauen.
ich glaube Train-Controller geht diesen Ansatz, nur eben nicht mit beliebigem 2. Digitalsystem, sondern mit seinen eigenen Handreglern. Gut, bei Dir gibt es historisch bedingt ohnehin 2 Bus-Systeme, wenn der Aufbau aber etwas größer wird, möchte man das gerne vermeiden. Deshalb macht es für mich mehr Sinn direkt vor dem GFP zu filtern und die Möglichkeit zu haben, mehrere GFP mit unterschiedlichen Filtern im System zu haben (z.B. 2. GFP für Weichen und Signalsteuerung).
Ich denke auch, dass die Software-Hersteller das nicht anbieten, weil mit den neuen Protokollen Railcom+ und MFX eine Übertragung zwischen unterschiedlichen Digitalsystemen schwierig und fehleranfällig wird. Auch wenn Du das bei Dir nicht nutzt, so würden es viele andere Kunden reklamieren, warum dies oder jenes dann nicht richtig klappt. So dürfte auch Dein 2. Digitalsystem mit dem MFX-Adressmapping z.B. Probleme haben.
Einfach zu handhaben wäre das für die Softwareanbieter nur, wenn 2 mal das gleiche Digitalsystem verwendet werden würde. Dann stellt sich aber die Frage, was ist aufwendiger, ein Filterbaustein, oder einen 2. Bus über die Anlage zu verteilen und dabei nicht alle Vorteile der Filter zu haben.
also ein weiterer GFP für die Magnetartikel ist ja vollkommen problemlos.
Bzgl. der alternativen Schnittstelle habe ich schon simplere USBtoCAN Adapter gesehen.
Bei den Handreglern sehe ich die Lösung (vielleicht) etwas simpler.
Der Handregler liefert im Prinzip ja nur, welche Lok mit der Adresse x welchen Befehl y ausführen soll. Und im Falle mfx ist die Adresse (eigentlich) für den (unbedarften) User nicht sichtbar, also bleiben nur die konventionellen Protokolle für den Betrieb Märklin-fremder Protokolle. Das sollte in den Programmen easy zu behandeln sein.
Kann man also die Handregler-Befehle zuerst im Steuerungs-Programm filtern, hat man keine weiteren problematischen Baustellen.
- zumindest aus der Sicht eines Software-Architekten -
AndreasWB schrieb:
Bzgl. der alternativen Schnittstelle habe ich schon simplere USBtoCAN Adapter gesehen.
USBtoCAN Adapter gibt es sicherlich einfachere, aber das Ziel war Ethernet2CAN - möglichst stabil und insbesondere günstig. Zudem bietet das BBB noch reichlich andere Möglichkeiten …
Die CC-Schnitte und PC-Schnitte sind Klasse Produkte (und der Support ist hier Spitze), aber Sie benötigen noch einen Rechner, um etwas machen zu können. Beim BBB ist der Rechner quasi kostenlos dabei. Und die Unterstützung von SocketCAN führt dazu, das man die entwickelte Software durch einfaches Compilieren auf andere Linux-Plattformen portieren kann.
Eingetragen am 14.10.2013 16:39
v6.01.13 © 2003-2005