Hallo Michael,

Zitat von st-oldie

---

Ja, das ist klar das die UID das Gerät eindeutig identifiziert. Aber das war eigentlich nicht meine Frage. Wenn ein Gerät auf meinen Ping antwortet, woran erkenne ich deine Module? Eine Antwort auf einen Ping beinhaltet ja die Gerätekennung. Damit könntest du deine Geräte auch identifizieren.

---

Bisher habe ich die UIDs nur zufällig gewählt. Wenn die Statusdaten Konfiguration abgefragt wird, dann wird ja auch zu aller erst Gerätename, -Nummer, -Artikelnummer und -Versionsnummer übertragen (Statusdaten Konfiguration Antwort mit Index 0). Daran kann man dann eindeutig erkennen, worum es sich handelt. Aber ich habe auch vorgesehen, dass ich die UIDs nach einem System anlege, welches sich dann durch alle meine Komponenten durchzieht. Aber für die Funktionalität von Weichensteuerung und Konfiguration ist der Wert der UID erst einmal unbedeutend. Ebenso der Hash, der von meinem Baustein aus der festgelegten UID errechnet wird.

Hallo Zusammen,

Zitat von st-oldie

---

Zitat von ixam97

---

Würde die Software denn dann auch parallel zu Gerds can2lan, ms2wifi etc funktionieren?

---

Meine Software ersetzt can2lan, ms2wifi, ... Ich hatte vor 3-4 Jahren mit meinem BBB angefangen. Und dann auch mit einer "einfachen" Schleife genau wie can2lan angefangen, die CAN und Ethernet abfragt und auf das andere Interface weiterleitet. Und dann hab ich mich als Software Ingenieur etwas "ausgetobt" und das ganze umstrukturiert. Ich hab als zentralen Kern die drehscheibe, die die Daten zwischen den Clients weiterletet. Und dann für jede Schnittstelle bzw. Protokoll einen Client, der sich mit der drehscheibe über sockets verbindet. Dadurch lässt sich meine Software leicht an andere Schnittstellen oder Protokolle anpassen. Die Logik z.B. zur Verwaltung der cs2 Dateien steckt im client_zentrale. Meine Software integriet alles. Zusätzlich hab ich eine Webconfig, mit der ich die Konfigurationsdatei meiner Software anpassen kann. Das dazugehörige PHP Script hat mein Kollege, der sich das mal anschauen wollte, beigesteuert. Auch ein Mechanismus für Updates ist schon vorgesehen.

---

Irgendwie erinnert nicht das ein wenig an die Tannenbaum-Torvalds Diskussion , wobei die Positionen nicht eindeutig vergleichbar sind, zumal ich mich als Hobby-Entwickler nicht messen lassen kann . Bei der historisch belegten Diskussion ging es zum zum Teil auch um den monolistischen (can2lan) bzw. modularen (mrsystem) Ansatz.

Zitat

---

Man könnte meine Software auch als Weiterentwicklung von can2lan sehen. Gerd hat auch meine Entwicklung seit 3.4 Jahren mitverfolgt. Leider ist Gerd bei seinem can2lan geblieben, obwohl er seit 3-4 Jahren meine Arbeit kennt. Ich denke nämlich, daß meine Software durch die Umstrukturierung und der bisher vorhandenen Features mehr Potential hat. Und die Software läßt sich auf diversen System zum Laufen bringen, wenn die System unter Linux laufen. Eine Anpassung an verschiedene Busse dürfte immer recht einfach sein.

---

can2lan bzw. der Vorgänger can2udp ist schon etwas älter als Michaels Software. Ich habe mich damals insbesondere am gateway.arm der CS orientiert. Anfangs ging es mir auch nur darum, dieses gateway.arm auf einem eigenen Rechner (Dockstar bzw RPi der ersten Generation) laufen zu lassen. Das geht übrigens, wenn man ein paar Dinge beachtet. Rechtlich gesehen ist die Verwendung natürlich sehr fragwürdig. can2udp war die Konsequenz daraus.

Ich kenne Deine Arbeit Michael , würde aber ein paar Sachen anders machen bzw, habe sie anders gemacht.

Anfangs haben wir zusammen daran gearbeitet (naja, Michael hat über 99 Prozent der Arbeit gemacht, der Rest viel auf Daniel bzw. mich). Ich habe aber nie ein rechten Zugang zu Deinem Framework bekommen. Du hast auch sehr klare Vorstellungen, wie bestimmte Sachen umgesetzt werden sollen.

Die Vorkommnisse in der jüngsten Vergangenheit haben mich letztendlich dazu bewogen, erst mal weiterhin can2lan einzusetzen und daran zu arbeiten.

Zitat

---

Ich versuche, meine Software so langsam weiter zu entwickeln, So, wie es gerade paßt. Aber auch, wie ich es brauche. Mein Ziel war es, im Gegensatz zu can2lan auch ohne einen Computer zu spielen

---

Ist der BBB kein Computer ? SCNR Irgendwie verstehe ich den Punkt hier nicht. Ein Smartphone ist doch nichts anderes als ein Mini-Computer. Oder meinst Du du Fähigkeit, jetzt z.B. mehrere Loks in der MS2 zu verwenden ?

Die CS2.exe wird nicht benötigt, um mit can2lan die Modellbahn zu steuern.

BTW: can2lan ist nicht nur Vermittler zwischen CAN und LAN.

Zitat

---

Damit gibt es einen Betriebsmodus, in dem ich die Lokliste von der MS2 abhole. Als "Abfallprodukt" gibt es aber einen Betriebsmodus, in dem meine Software als Proxy arbeitet, so wie es can2lan tut. Wenn ich die Grenze der 40 Loks der MS2 erreicht habe, muß ich wohl eine Modus in meine Software integrieren, in der meine Software auch die Anmeldung der Loks bearbeitet. Damit wäre meine Software eine CS2 ohen GUI. Die dazugehörige Webconfig wäre dann die Möglichkeit, meine Software zu konfigurieren.

Die Konfiguration externer Module wäre damit eine logische Erweiterung.

---

Das ist ein Punkt, den ich im Gegensatz zu Deiner Software, Michael, anders machen möchte. Schon ähnlich wie bei Dir über Web, aber nicht über PHP , sondern über Websockets mittels libwebsockets. Libwesockets ist wesentlich schlanker als PHP. Bei einem 7 Euro Router bzw Linux-Mini-Server fällt das schon ins Gewicht.
Aber da ist can2lan noch nicht so weit.

Eins möchte ich auf jeden Fall tunlichst vermeiden: Das es wie damals zu einer heftigen, öffentlichen Auseinandersetzung wie zwischen Tannenbaum und Torvalds kommt. Michael, Deine Software ist eine handwerklich hervorragend gemachte Arbeit (soweit ich das als Laie beurteilen kann), die durch die Modularität viel Potential hat; can2lan ist ein ausgereiftes, schlankes und smartes Tool um schnell mal was zu testen bzw. deren Funktionen für viele Bereiche schon jetzt völlig ausreichend sind. Rocrail, WDP und iTrain harmonieren prima damit.

Der Nutzer kann selbst entscheiden, was er einsetzen möchte. Wichtig ist nur eine OpenSource CAN Lösung

Gruß

Gerd

Hallo,

also eine Diskussion darüber, welche Lösung besser ist, brauchen wir jetzt wirklich nicht. Das führt zu nichts. Grade in diesen Thread passt das nicht unbedingt rein. Da muss jeder wissen, was einem persönlich besser gefällt.

Wenn ich irgendwann dazu komme, dann werde ich auch nochmal eine völlig eigenständige Lösung dafür zusammenschustern, die meine CAN-UDP-Bridge der kabellosen MS2 nutzt. Aber das dann auch erst, wenn Zeit dafür ist.

Hallo an alle Beteiligten

Zitat von Ixam97

---

... also eine Diskussion darüber, welche Lösung besser ist, brauchen wir jetzt wirklich nicht. Das führt zu nichts. Grade in diesen Thread passt das nicht unbedingt rein. Da muss jeder wissen, was einem persönlich besser gefällt.

Wenn ich irgendwann dazu komme, dann werde ich auch nochmal eine völlig eigenständige Lösung dafür zusammenschustern, die meine CAN-UDP-Bridge der kabellosen MS2 nutzt. Aber das dann auch erst, wenn Zeit dafür ist.

---

ich finde es super was da in der Vergangenheit durch Euch "gebastelt" wurde. Ich denke jetzt wäre der Zeitpunkt gekommen, diesen Themenkomplex zu verschlanken und mit einigen wenigen Plattformen (z. B. Raspi, Banana und BeagleBone) auszukommen. Die derzeitige Vielfalt verunsichert nur potentielle Anwender.

Daher: zwingend an einen runden Tisch, die Aufgaben sinnvoll verteilen und gemeinsam an der modellbanhsteuerungstechnische "Eierlegenden Wollmilchsau" zu arbeiten

Gruß

Alf

Hallo Maxi,

Zitat von Ixam97

---

Bisher habe ich die UIDs nur zufällig gewählt. Wenn die Statusdaten Konfiguration abgefragt wird, dann wird ja auch zu aller erst Gerätename, -Nummer, -Artikelnummer und -Versionsnummer übertragen (Statusdaten Konfiguration Antwort mit Index 0). Daran kann man dann eindeutig erkennen, worum es sich handelt. Aber ich habe auch vorgesehen, dass ich die UIDs nach einem System anlege, welches sich dann durch alle meine Komponenten durchzieht. Aber für die Funktionalität von Weichensteuerung und Konfiguration ist der Wert der UID erst einmal unbedeutend. Ebenso der Hash, der von meinem Baustein aus der festgelegten UID errechnet wird.

---

Ich hatte mich auf die Gerätekennung bezogen, die in der Antwort auf einen ping drinsteht und den Typ des Gerätes kennzeichent. Aber so wie du das erklärt hast, macht es wohl keinen Sinn, im ersten Schritt eine "Abkürzung" zu suchen.

Zitat von Ixam97

---

Dass deine Software eine Alternative für Gerd's darstellt, ist mir klar. Es wäre nur schön gewesen, wenn das Webtool zur Konfiguration sozusagen eigenständig arbeiten würde. Dann könnte jeder sie einsetzen, unabhängig von der sonstigen verwendeten Soft- und Hardware.

---

Sorry, da hab ich wohl deine Frage falsch interpretiert.

Die Webkonfig arbeitet zur Zeit völlig eigenständig, da ich nur die Konfigurationsdatei meiner Software schreibe bzw. einen Neustart auslösen kann.

Eine Erweiterung, mit der ich z.B. deine Module konfigurieren könnte, würde aber nicht selbstständig laufen. Ich hab ja schon kurz mein Konzept beschrieben. Ich würde wahrscheinlich den client_zentrale nehmen, der dann die Statusdaten Konfiguration abfragt und das passende Webformular erzeugt bzw. dessen Parameter. Und die Webconfig würde dann meinen Inject Client aufrufen der die CAN Nachrichten an die drehscheibe schickt. Mein Konzept sieht ja vor, daß das Verschicken über CAN vom dafür vorgesehenen Client gemacht wird. Damit muß die Webconfig für deine Module nicht wissen, wie die Anbindung an CAN ist. Das System könnte z.B. mit einer CC-Schnitte (über USB statt integriertem CAN Controller) genauso funktionieren.

Tschüß
Michael

Hi Gerd,

Zitat von bertr2d2

---

Zitat von st-oldie

---

Meine Software ersetzt can2lan, ms2wifi, ...

---

Irgendwie erinnert nicht das ein wenig an die Tanenbaum-Torvalds Diskussion ...

---

Nö, ich wollte nur Maxi erklären, wie mein System funktioniert. Damit erklärt sich nämlich, ob eine Webconfig für Maxis Module eigenständig läuft oder nicht.

Tschüß
Michael

Hallo Michael,

Zitat von st-oldie

---

Ich hatte mich auf dei Gerätekennung bezogen, die in der Antwort auf einen ping drinsteht und die Typ des Gerätes kennzeichent. Aber so wie du das erklärt hast, macht es wohl keinen Sinn, im ersten Schritt eine "Abkürzung" zu suchen.

---

Ah, jetzt verstehe ich was du meinst. Derzeit benutze ich für den Schaltdecoder den Kenner 0x0050. Ich weiß aber nicht, ob M*rklin da möglicherweise schon was anderes angesiedelt hat. In dem Bereich ist die Doku nicht ganz vollständig. Das könnte sich im Laufe der Zeit also noch ändern.

So, auch hier nochmal ein Lebenszeichen.

Die ersten Leute werden Demnächst ihre Bausätze erhalten.
Allerdings stehe ich derzeit vor dem Problem, dass ich den Decoder nicht mehr wirklich ausgiebig testen kann. Meine letzten Versuche haben ergeben, dass es irgendwie ein Problem mit der Lagerückmeldung gibt und die Weichen manchmal nicht vernünftig durchschalten. In meinem Schaltplan habe ich aber keinen Fehler gefunden. Um die Software noch einmal zu überprüfen hatte ich bisher keine Zeit, das werde ich aber auch noch machen. Ich vermute, dass am ehesten meine Weichenantriebe nicht ganz i.o. sind. Zumindest bei einem ist vermutlich die Endabschaltung defekt. Da ich aber keine Spulenantriebe mehr verwenden möchte in Zukunft werde ich mir da auch keine Neuen anschaffen. Da bin ich dann auf euch und eure Beobachtungen angewiesen.

Und nochmal in anderer Sache, um das ganze noch einem größeren Publikum schmackhaft zu machen :
Der Decoder kann ja auch Dauerstrom liefern. Lichtsignale sollten also auch problemlos angesteuert werden können, sofern die Polarität der LEDs stimmt. Zumindest zweibegriffige Signale sind auch ohne weitere Softwareanpassungen ansteuerbar. Demnächst werde ich mich auch mal dran setzen und eine Software für den Decoder schreiben, womit dann mehrbegriffige Signale gesteuert werden können (z.B. Langsamfahrt in Abhängigkeit von bestimmten Weichenadressen, Halt wenn der nachfolgende Belegtmelder aktiv ist usw. ) und auch Vorsignale am Mast. Habe da schon ein paar Ideen.

Die Geschwindigkeit wird sich aber etwas reduzieren im Vergleich zu vorher. Uni wird demnächst wieder etwas Zeitintensiver. Aber nichts desto Trotz wird es demnächst wieder die ein oder anderen Fortschritte zu sehen geben

Hallo, nur mal ein kleines Update, was ich grade so treibe:


Da Port und IP frei einstellbar sind, wird auch meine CAN-UDP-Brücke verwendet werden können, falls keiner der beiden benannten Einplatinencomputer vorhanden ist. Diese wäre dann für Einsteiger, die nicht unbedingt die erweiterten Funktionalitäten eines Einplatinencomputers nutzen wollen, eine kostengünstigere Alternative.
Näheres gibts dann, wenn das Programm fertig ist. Derzeit kann es nur auslesen aber noch nicht schreiben.

Nachtrag: Auch hier zeigt sich mal wieder, dass der WiFi-Broadcast irgendwie eine gewaltige Latenz verursacht. Wenn ich im Interface nur eine bestimmte Target-IP festlege, dann gibt es so gut wie keine Latenz. Beim Broadcast werden Pakete teilweise völlig verschluckt. Sehr seltsam...

Hallo allesamt,

lange habe ich hier nichts mehr interessantes von mir hören lassen. Aber die Klausuren sind vorbei und so langsam ist wieder ein wenig zeit zum Basteln da

Viel zu zeigen habe ich noch nicht, aber ich habe schon mal einen kleinen Teaser, was es so in den nächsten Tagen zu sehen geben wird


Die Grundfunktionen funktionieren schon, ich muss nur noch die Software etwas glatt bügeln und das Interface für die CS2 zusammenbasteln. Aber die Servos laufen schon jetzt sehr viel zuverlässiger als die Magnetantriebe. Bisherige Einstellmöglichkeiten für die Servos: Geschwindigkeit, Winkel und Adresse (DCC und MM). Ein Decoder kann acht Servos steuern. Zur Zeit benutze ich abgewandelte Hardware der Magnetarktikeldecoder, die aber bald von der MäCAN-Universalplatine abgelöst werden soll.

Aber dazu später mehr, wenn es etwas zu gucken gibt. Seid euch gewiss, das Thema ist auf jeden Fall nicht tot

So, auch hier kann ich ein wenig was neues Berichten.

Zunächst etwas für diejenigen, die auch selber etwas an meiner Hardware herumprogrammieren wollen: Ich bin derzeit dabei, die Bibliothek, die die Basis für alle Bausteine bildet, umfangreich zu erweitern. Damit sollte es auch anderen außer mir möglich sein, den Code besser zu verstehen. In der nächsten Zeit werden noch einige weitere Funktionen hinzu kommen, aber schon jetzt kann man da denke ich einiges mit anstellen. Vor allem steht nun bei Jeder Funktion halbwegs ausführlich dabei, was sie macht.
Besonders die Funktion, die sich um die Kommunikation mit der CS2 kümmert, ist eine große Erleichterung. Ich glaube, ich wäre verrückt geworden, wenn ich das bei einem Servodecoder mit später mal 45 Konfigurationskanälen alles von Hand hätte machen müssen. Jetzt habe ich einen Algorithmus, dem ich nur noch ein paar werte geben muss und der Rest passiert automatisch.
Für die Interessierten, hier könnt ihr euch die Bibliothek ansehen.


Aber nun zu dem interessanten Teil:
Mein Plan für die Zukunft ist, dass ich nur noch eine Platine für alles Habe. Also eine Art "MäCAN-Universalplatine". Diese soll dann auf das nötigste reduziert werden: Kein Spannungswandler (Speisung direkt mit 5V, z.B. aus einem USB-Netzteil), keine Leistungsausgänge (bis auf einen). Ohne Zusätze soll das ganze dann einzelne LEDs (z.B. Lichtsignale) und Servos Steuern können sowie als Stellpult verwendet werden können. Damit sind schon mal drei (und die für mich wichtigsten) Funktionen abgedeckt. Daran solldann relativ einfach Zusatzmodule angeschlossen werden können. Unter anderem Gleisbelegtmelder und Transistoren, um größere Lasten steuern zu können.
Durch diese universelle Herangehensweise sollte das ganze dann wesentlich flexibler verwendet werden können. Unter anderem sollen dadurch an einem Decoder sowohl Rückmelder, Servos als auch Schaltausgänge gleichzeitig verwendet werden können, sodass keine spezialisierten Decoder gebraucht werden und die Zahl der insgesamt benötigten Platinen minimiert wird.

Jetzt wäre auch die richtige Zeit noch Wünsche zu äußern, was so ein Universaldecoder noch können sollte. Lasst einfach hören, was ihr schon immer haben wolltet, und ich werde mal schauen, ob sich das realisieren lässt

Und nun noch ein Bild meines derzeitigen Versuchsaufbaus:


Ganz links ist der Prototyp der Universalplatine zu sehen (derzeit ein modifizierter Magnetartikel-Decoder). Diese ist zur Zeit so Konfiguriert, dass vier Servos gesteuert werden können. Die CdB-Spezifische Rückmeldung wird erst gesendet, wenn der Servo seine Bewegung abgeschlossen hat. Dadurch werden Fahrstraßen in Rocrail erst dann freigegeben, wenn auch alle Weichen wirklich gestellt wurden. Der Servodecoder ist an meine CAN-UDP-Bridge angeschlossen, die als WLAN-Interface zu Rocrail fungiert, welche wiederum an die Gleisbox angeschlossen ist (meines Wissens nach ist das die zur Zeit günstigste WLAN-fähige "Zentrale"). Jetzt fehlen nur noch die Gleisbelegtmelder und man hat alles, was man braucht, um die Modellbahn per Rocrail vollautomatisch zu steuern.

Wie immer bin ich gespannt auf Kritik und Anregungen

Hallo,

kann man die Universalplatine auch ganz normal an den CAN Bus (Netzwerkkabel) anschließen?
Was bei einer Universaplatine sehr wichtig wäre, eine große Bibliothek. So kann man x beliebige Signalbilder der verschiedenen Länder erstellen.

Grüße
speedy

Hallo Maxi,

da ich nun meine ersten MäCAN Decoder fertig habe, hier meine Wunschliste:
* Magnetartikel,
* Servos,
* Schaltdecoder (Relais analog m84/k84),
* Stellpult (für GBS),
* LED Anzeigen (für GBS),
* Printklemmen mit RM3,5 (die aktuellen sind für meine Leitungen zu klein - 1mm2 bzw. 1,5mm2).

Bin gestern und heute bei Flaschen des atmega fastverzeifelt. Am Ende hat sich herausgestellt, dass einer von 5 atmega wohl kaputt ist, nach tausch des atmega ging alles fast von allein. Da muss man erstmal drauf kommen.


Gesendet von iPhone mit Tapatalk Pro

Zitat von speedy200

---

Kann man die Universalplatine auch ganz normal an den CAN Bus (Netzwerkkabel) anschließen?
Was bei einer Universaplatine sehr wichtig wäre, eine große Bibliothek. So kann man x beliebige Signalbilder der verschiedenen Länder erstellen.

---

Die Platine verfügt dann wie das jetzige Modell über RJ-45 Buchsen und Anschlüsse für 3-Polige Schraubklemmen. Ich denke ich werde auch noch für gewinkelte Stiftleisten Anschlüsse vorsehen, damit man mehrere Platinen direkt aneinander stecken kann.
Die Bibliothek für die Universalplatine soll sich zunächst erst mal um den CAN-Teil kümmern. Für Servos, H/V- und Ks-Lichtsignale sowie normale Schaltausgänge werde ich denke ich auch etwas vorfertigen. Das braucht dann aber natürlich etwas Zeit, habt da bitte etwas Geduld Für den Rest hoffe ich die Bibliothek so simpel gestallten zu können, dass sich da jeder selber etwas zusammenbasteln kann. Für etwaige Fragen stehe ich dann aber natürlich gerne zur Verfügung.

Zitat von Clooney

---

* Magnetartikel,
* Servos,
* Schaltdecoder (Relais analog m84/k84),
* Stellpult (für GBS),
* LED Anzeigen (für GBS),
* Printklemmen mit RM3,5 (die aktuellen sind für meine Leitungen zu klein - 1mm2 bzw. 1,5mm2).

---

Die ersten 5 Punkte sind ja schon umgesetzt bzw geplant. Die Klemmen sind wirklich etwas fummelig, da hast du recht. Ich werde mal gucken, dass ich größere mit einplane.

Zitat von Ixam97

---

Die ersten 5 Punkte sind ja schon umgesetzt bzw geplant. Die Klemmen sind wirklich etwas fummelig, da hast du recht. Ich werde mal gucken, dass ich größere mit einplane.

---

Ich weiß, dass die mehr oder weniger fertig sind
Für die Erweiterung hab ich Dir ja auch schon Ideen Input geliefert.
Die Klemmen an den Märklin Decoder habe soweit ich weiß ein RM von 3,5. Die sind eigentlich recht optimal von der Größe. Als Stromverteiler hab ich welche mit RM5, die wären für den Decoder aber etwas oversized.


Gesendet von iPhone mit Tapatalk Pro

Hallo Allesamt, hier ein kleiner Zwischenbericht.

Die Universalplatine habe ich jetzt soweit fertig. Die Platine verfügt jetzt über einen Mini-USB-Anschluss, über den er mit 5V-Spannung aus einem USB-Netzteil versorgt werden kann. Ein Spannungsregler ist nicht mehr vorhanden! Mehrere Module können über die 7-Poligen Anschlüsse direkt aneinander gesteckt werden und teilen sich damit die eingespeisten 5V. Die übrigen Signale aus dem CAN werden ebenfalls durchgeschleift.

Ohne weitere Zusatzmodule lassen sich dann mit dem Modul 10 Servos, 10 LEDs oder 10 Schalteingänge betreiben. Wenn man etwas Erfahrung mit Arduino-Programmierung hat, dann können diese Anwendungsarten an einem Modul auch gemischt genutzt werden. Wenn es die Zeit zulässt, dann werde ich vielleicht auch einen Universal-Sketch schreiben, bei dem man jeden Ausgang frei konfigurieren kann.

Hier schon mal ein kleiner Vorgeschmack:


Um die 5x10cm voll auszunutzen habe ich noch eine kleine Platine mit RJ-45 Buchsen zusammengebastelt. Den kann man dann als Verteiler, Einspeisung o.ä. nutzen.

Sobald ich die neue Version der CAN-UDP-Platine fertig habe wird das ganze in Auftrag gegeben, das Spart etwas Versandkosten

Falls noch wer Anregungen hat, immer her damit

Hi!

Könnte man nicht noch eine Messfunktion einbauen, die bei Spulenantrieben von Weichen misst, welche Stellung die zur Zeit haben - Induktionserkennung, wo das Eisen gerade ist?

Ansonsten bin ich schon voller Vorfreude bald Platinen ordern zu können

Danke und beste Grüße!

Micha

Hallo Micha,

Zitat von MTB-Ontour

---

Könnte man nicht noch eine Messfunktion einbauen, die bei Spulenantrieben von Weichen misst, welche Stellung die zur Zeit haben - Induktionserkennung, wo das Eisen gerade ist?

---

Der begriff der Induktionserkennung ist mir fremd. Aber es besteht die Möglichkeit, die tatsächliche Lage eines endabgeschalteten Spulenantriebes zu erkennen. Auf meinem Prototypen (siehe Video am Anfang des Threads) und auf der Weichendecoder-Platine ist diese Erkennung hardwareseitig auch schon vorgesehen. Anfangs hat das auch recht gut funktioniert. Nur hat das in meinen Versuchen dazu geführt, dass einige meiner Weichenantriebe abgeraucht sind. Vermutlich war bei denen die Endabschaltung nicht mehr ganz in Ordnung.

Die Universalplatine wird von sich aus auch keine Spulenantriebe schalten können. An den Ausgängen sind lediglich die IO-Pins des Microcontrollers herausgebrochen. Für größere Lasten als einzelne LEDs muss noch ein Treiber zwischengeschaltet werden. Wenn es bei dir ums schalten von Spulenantrieben geht, dann ist die Weichendecoder-Platine die bessere Wahl. Davon habe ich auch noch ein paar wenige hier herumfliegen. Weitere herzustellen wäre aber auch kein Problem.

Zitat von Ixam97

---

Hier schon mal ein kleiner Vorgeschmack:

---

Hallo Maxi,
wie Du weißt arbeite ich gerade an ein paar I2C AddOns, daher meine bitte: Belege den I2C identisch zur bisherigen Platine.
Wenn ich das jetzt recht gesehen ist auf dem Magnet Decoder Pin1 = 5V und auf der Universalplatine ist Pin4 = 5V.
Ist jetzt kein großes Problem, muss man aber bei der Verkabelung beachten.

Hallo Jochen,

Zitat von Clooney

---

wie Du weißt arbeite ich gerade an ein paar I2C AddOns, daher meine bitte: Belege den I2C identisch zur bisherigen Platine.
Wenn ich das jetzt recht gesehen ist auf dem Magnet Decoder Pin1 = 5V und auf der Universalplatine ist Pin4 = 5V.
Ist jetzt kein großes Problem, muss man aber bei der Verkabelung beachten.

---

Der Anschluss war nur um 180° gedreht. Man hätte deine Module also nur andersherum anstecken müssen. Ich habe den Anschluss aber mal gedreht, damit auch nichts auf dem Kopf steht

Hallo Maxi,
Hallo Stummis,

konnte heute meine erste AddOn-Platine für den MäCAN Weichendecoder fertig stellen.
Es handelt sich dabei um ein Relais-AddOn und Gleise stromlos bzw. größere Lasten zu schalten.
Leider hatte ich beim planen der Platinen wohl ein paar Tomaten auf den Augen, und so einen IC in der falschen Bauform verbaut.


Zum Glück ließ sich das leicht beheben. Ist zwar nicht schön, funktioniert aber auch


Andere würden das ganze wahrscheinlich in die Tonne werfen, das seh ich aber mal garnicht ein. Und außerdem hab ich nicht gerade wenig Platinen bekommen:


In Summe 10 Relais Platinen bestellt ( 11 bekommen ) und 30 I/O Platinen (32 geliefert bekommen) - dazu später mehr.

Fertig bestück sieht die Relais Platine dann so aus:



Das ganze sieht dann angeschlossen an den Weichendecoder so aus:


An der Software hatte ich die letzten Abend schon gearbeitet und dann eigentlich gehofft, dass Theorie und Praxis funktionieren - leider war das wie immer nicht der Fall.
Also musste ich nochmals einige Stunden investieren um Bugs und Denkfehler auszubügeln. Auch musste ich das ganze dann noch etwas Speicher optimieren.
Nach einigen dutzenden Änderungen hatte ich es dann endlich geschafft und das Teil funktionierte prinzipiell.
So musste ich nur noch ein paar Kleinigkeiten für das CS2 Setupmenü anpassen. Jetzt muss sich das ganze nur noch im Anlageneinsatz bewähren.

Als nächstes kommt dann das I/O AddOn dran.

Hier habe ich mir 2 verschiedene Softwareversionen ausgedacht.
Einmal um die Rückmelder zu visualisieren und einmal als Stellpult. Zusammen soll das dann ein GBS werden.
Aber hier kommen schon die Ersten Probleme hoch. Dass S88 Anzeigemodul macht mir hier aktuell die größten Probleme, da mir der Speicher des AtMega328 ausgeht, wenn ich 8 AddOn Module anschließe, was dann 128 LED Anschlüsse böte - Bin mal gespannt ob ich das noch soweit optimiert bekomme, dass ich den Vollausbau fahren kann.
Beim Stellpult ist das interessanter weise nicht ganz so gravierend.

Hier mal die Übersicht über den Speicherverbrauch der einzelnen AddOns:
Relais:

Der Sketch verwendet 14.700 Bytes (45%) des Programmspeicherplatzes. Das Maximum sind 32.256 Bytes.
Globale Variablen verwenden 1.420 Bytes (69%) des dynamischen Speichers, 628 Bytes für lokale Variablen verbleiben. Das Maximum sind 2.048 Bytes.
 

S88-Anzeige:

Der Sketch verwendet 14.036 Bytes (43%) des Programmspeicherplatzes. Das Maximum sind 32.256 Bytes.
Globale Variablen verwenden 1.750 Bytes (85%) des dynamischen Speichers, 298 Bytes für lokale Variablen verbleiben. Das Maximum sind 2.048 Bytes.
Wenig Arbeitsspeicher verfügbar, es können Stabilitätsprobleme auftreten.
 

Hier könnte es durchaus zu Problemen kommen.

Stellpult:

Der Sketch verwendet 14.302 Bytes (44%) des Programmspeicherplatzes. Das Maximum sind 32.256 Bytes.
Globale Variablen verwenden 1.401 Bytes (68%) des dynamischen Speichers, 647 Bytes für lokale Variablen verbleiben. Das Maximum sind 2.048 Bytes.
 

@Maxi:
Soll ich Dir den Code zukommen lassen, damit Du Ihn dann auf GitHub online stellen kannst, oder soll ich selbst ein Repository aufmachen?


So, wünsche Euch noch einen Guten Abend.

Hallo Jochen,

das sieht ja echt schon ganz gut aus soweit. Ich bin gespannt darauf, wie sich das ganze dann in deiner Anlage bewährt.

Deinen Code kannst du mir gerne zuschicken und ich lade den dann bei mir auf GitHub hoch. Dann ist alles an einem zentralen Ort

Hallo Zusammen,

Nur mal eine Frage ob ich den groben Aufbau richtig verstanden habe:


Die Module in der Mitte sollen meine Märklin C-Gleis Nord - Module darstellen. Der Banana PI soll das Image von Michael Bernstein bekommen.
Legende:
Trafo = USB Schaltnetzteil
U-CAN = CAN-Universalmodul bzw. CAN-Weichendecoder
Addon = CAN Input bzw. CAN Relais
CAN-V = CAN Verteiler
6604 und 6647 = Delta Booster

Viele Grüße aus Hessen

Ist das Projekt MaCAN schon wieder Tot oder warum bekommt man nach einer Woche immer noch keine Antwort ?

Hallo Orgel,

Zitat von orgel

---

Ist das Projekt MaCAN schon wieder Tot oder warum bekommt man nach einer Woche immer noch keine Antwort ?

---

Nein, das Projekt ist nicht tot, und es war wohl gemerkt auch keine ganze Woche ... Ich betreibe das ganze hier nur als Hobby und dementsprechend in meiner Freizeit, welche in den letzten Wochen nicht sehr ausgedehnt war. Desweiteren sind einige Weiterentwicklungen auch von meinen kargen Studenten-Geldmitteln abhängig. Da bitte ich doch um etwas Verständnis!

Den Grundaufbau hast du soweit richtig verstanden. Die Module können untereinander entweder mit Netzwerkkabeln oder einfach mit drei Drähten verbunden werden. Entscheidet man sich für das Netzwerkkabel, so wird auch das Gleissignal mitgeschleift, sofern es an der Gleisbox eingespeist wird. Mit einem entsprechend ausgeführtem Verteiler (Welcher bei der zukünftigen Universalplatine enthalten sein wird) lässt sich dort also das Gleissignal für die Booster abgreifen. Wenn noch die Möglichkeit bestehen soll, eine MS2 an das Modul anzuschließen, dann habe ich noch einige kleine Adapterplatinen RJ-45 <-> MINI-DIN-10, wodurch das möglich wird.
Zu beachten ist allerdings, dass die Module nur mit Gleichstrom funktionieren! Was passiert, wenn man einen Trafo anschließt, weiß ich nicht, führt aber vermutlich zur Zerstörung des Moduls. Um Wechselstrom zu schalten wären vermutlich Jochens Relais-Addons eine gute Ergänzung. Wenn die Relais mit 5V schalten, dann könnte jedes Modul mit einem günstigen 5V-Netzteil ausgestattet werden, wie es zum Handy aufladen üblich ist