Hallo zusammen,

die letzten zwei Tage habe ich etwas mit dem USB-Interface gekämpft. Ich hatte bereits vorher provisorisch das Datenprotokoll, das auch die CC-Schnitte verwendet, implementiert. Die fehlende Begrenzung der Frames war mir jedoch ein Dorn im Auge und hat immer wieder für Schluckauf in Rocrail gesorgt. Daher habe ich nun das SLCAN-Format für Extended CAN-Frames implementiert. Dabei hat sich gezeigt, dass die von mir bisher verwendete Software für den ATmega16u2 nicht leistungsfähig genug war. Nun habe ich dort die Software drauf, die auch der Arduino verwendet. 500000 Baud sind damit auch mit dem internen 8MHz-Takt kein Problem mehr.

Um auch wirklich alle Frames zu erwischen und über das Interface zu übertragen habe ich meiner CAN-Bibliothek nun auch einen Ringpuffer spendiert, der CAN-Frames zwischenspeichert. Zudem werden SLCAN Frames und "echte" CAN-Frames gleichwertig behandelt. Das eigentliche Programm unterscheidet also nicht, woher die Frames kommen. Zudem wird in beide Richtungen eins zu eins durchgereicht, unabhängig vom Hauptprogramm. Erste Tests sehen sehr vielversprechend aus. Als Stresstest habe ich meinen Updater verwendet, der ca. 1300 Frames in zwei Sekunden über den Bus jagt. Davon ist kein einziger Frame verloren gegangen.

So funktioniert die Schnittstelle anstandslos mit Rocrail zusammen, vorausgesetzt man sendet nicht auch noch ein "New Line" nach dem [CR] jedes Frames. Das habe ich eingebaut, um in einem Terminal den Datenverkehr beobachten zu können. Rocrail verschluckt sich dabei ganz böse und meckert wegen Timeouts. Warum [NL] nicht einfach ignoriert wird ist für mich nicht ganz nachvollziehbar. Ohne das [NL] funktioniert aber alles Wunderbar.

Falls für sowas mal Bedarf bestehen sollte kann ich mir auch vorstellen eine kleinere Platine zu entwickeln, die lediglich als Interface fungiert.

Hallo Maxi und alle MaeCAN-Anwender,

Zitat von Ixam97 im Beitrag Gleisbox als Zentrale

---

Für den MäCAN-Server selber gibt's kein eigenes Thema, aber du kannst deine Anregungen gerne im MäCAN-Reborn-Thread äußern.

---

Hallo Rainer,

[quote="Rainer Müller" post_id=2239724 time=1611855960 user_id=1332]
wie schon angekündigt, habe ich Ideen, Vorschläge und Wünsche zum MaeCAN-Server, der bei mir auf einem BananaPi mitläuft.
[/quote]

danke für deine Anmerkungen!

- Race Condition:
Solche Probleme habe ich tatsächlich selber nie festgestellt. Mangels älterer Endgeräte habe ich auch nie Tests in diese Richtung durchgeführt. Sobald du da eine funktionierende Lösung hast baue ich die natürlich gerne ein.

- Zweiter Websocket:
Dass ich diese Grundfunktionen erstellt habe ist nun schon sehr lange her. Warum ich manche Dinge so umgesetzt habe, wie ich sie umgesetzt habe, kann ich nicht mehr genau sagen. Aber ich meine mich zu erinnern, dass es einen Grund gab, warum die Loksteuerung von den anderen Komponenten der Bedienoberfläche getrennt ist. Ich werde mir diesen Teil bei Zeiten nochmal ansehen und überprüfen, ob hier eine andere Lösung anwendbar ist. Probleme habe ich deswegen bisher aber keine feststellen können.

- Funktionssymbole:
Statt der Textbezeichnungen waren Symbole auch schon von Anfang an auf meiner Wunschliste. Jedoch waren diese nie eine so hohe Priorität für mich, um mir die Arbeit zu machen, eigene Symbole zu erstellen. Gib mir bitte bescheid, wenn du die SVGs zusammen getragen hast. Dann werde ich mal schauen, dass ich den Loklisten-Dialog entsprechend erweitere, damit man Funktionstasten entsprechende Symbole zuweisen kann.

- Höhere Funktionen bei MM
Dass meine Umsetzung nicht ganz korrekt ist, war mir nicht bewusst (Habe selber keine entsprechenden Decoder). Nach meinem Kenntnisstand ist diese Funktion aber durchaus notwendig, Wenn man unter MM entsprechend höhere Funktionen ansteuern will. Ich werde mal schauen, dass ich diese Funktion konfigurierbar mache, damit man dies bei Bedarf ausschalten kann und sich Nachbaradressen nicht stören.

Hallo Maxi,

- Race Condition:
der Test sieht bisher gut aus, auch wenn man die von mir angesprochene "Angstsekunde" bis zum Absenden von getKeyboard und getLocolist auf 100ms vermindert; sie wird wohl nicht mehr benötigt.


- Zweiter Websocket:
vorwiegend habe ich mit einem gemeinsamen Websocket getestet, aber funktional sehe ich beim Test mit zweien keinen Unterschied. Lediglich die Theorie sagt mir, dass einer weniger Bandbreite im Netzwerk braucht und es sichergestellt ist, dass auch die Loksteuerung beim Start erst wach wird, wenn alles geladen ist.
Ich werde aber im ersten Wurf dir die Lösung mit zwei Websockets zusenden, sonst müssten die Änderungen in lococontrol_grid.php auch gleich mit rein, da bin ich aber noch am Feinschliff.


- Funktionssymbole:

Zitat

---

Statt der Textbezeichnungen waren Symbole auch schon von Anfang an auf meiner Wunschliste. Jedoch waren diese nie eine so hohe Priorität für mich, um mir die Arbeit zu machen, eigene Symbole zu erstellen. Gib mir bitte bescheid, wenn du die SVGs zusammen getragen hast. Dann werde ich mal schauen, dass ich den Loklisten-Dialog entsprechend erweitere, damit man Funktionstasten entsprechende Symbole zuweisen kann.

---

Die Arbeit, die Symbole zu erstellen, schien mir auch hoch, deshalb die Übernahme aus einem "Konkurrenzprodukt". Ein zusätzlicher Dialog zur Zuweisung der passenden Funktionen wäre natürlich toll. Ich erzeuge die locolist.json bisher mit einem Tool aus meiner "Master-Datenbank", damit geben die Funktionseinträge die Anzahl der Funktionen und ihre Symbole an und sehen dann beispielsweise folgendermaßen aus:

MM1 mit 1 Funktion:
"functions": [ 1 ],

MM2 mit 5 Funktionen:
"functions": [ 1, 7, 90, 12, 5 ],

mfx mit 16 Funktionen, davon 10 genutzt:
"functions": [ 1, 7, 82, 5, 8, 12, 19, 26, 20, 13, 0, 0, 0, 0, 0, 0 ],

Beim Anzeigen blende ich dann die Funktions-Knöpfe ohne Funktion aus.


- Höhere Funktionen bei MM

Zitat

---

Nach meinem Kenntnisstand ist diese Funktion aber durchaus notwendig, Wenn man unter MM entsprechend höhere Funktionen ansteuern will. Ich werde mal schauen, dass ich diese Funktion konfigurierbar mache, damit man dies bei Bedarf ausschalten kann und sich Nachbaradressen nicht stören.

---

Richtig, die Frage ist aber, ob mit dem MaeCAN-Server jemand eine Zentrale ansteuern will, die nur MM und kein mfx kann, denn nur dann macht diese Funktionalität m.E. einen Sinn.


- Produktpflege
Bei dir gibt es eine "MaeCAN-Server Version 2021-01-25.1" mit "Kanalabfrage stabilisiert". Sollte die Änderungen auch Gerd in sein Repository übenehmen?


Gruß
Rainer

Hallo zusammen,

nach einigen Monaten der Stille hole ich das Thema mal wieder hoch und erzähle ein wenig, was ich im "dunklen Kämmerchen" so gebastelt habe

Ich fange mal mit dem vermutlich spannendsten an:

Es war lange in Planung, und jetzt habe ich mich an die Umsetzung gesetzt: Die Ansteuerung von Lichtsignalen. Derzeit setze ich bei der Hardware auf den MP5x16. Dieser ist so umprogrammiert, dass er weiterhin 8 Weichenantriebe steuern kann, zusätzlich aber auch 16 PWM-Ausgänge bereit stellt. Damit wird die Platine auch für kleinere Anlagen oder einzelne Module attraktiver. 16 Weichen an einer Stelle hat man dann ja doch eher sehr selten:



Ein Anspruch von mir war dabei, dass die Lichtpunkte nicht einfach nur und ausgehen, sondern dass sich der Wechsel der Signalbilder daran orientieren, wie es in der Realität aussieht. Dazu gehört die Simulation von "Relaisstellwerkverhalten" für H/V-Lichtsignale sowie das weiche Überblenden zwischen An und Aus. Ich lassen an dieser Stelle einfach mal ein Video für sich sprechen:

Hallo zusammen,

es sind mal wieder ein paar Monate vergangen ohne, dass ich hier von etwas neuem berichtet habe. Das hat auch einen guten Grund, denn seit dem 01.11.21 bin ich nach meinem Studium endlich in das Berufsleben eingetreten. In Verbindung damit hat sich auch meine Situation von "Viel Zeit, wenig Geld" zu "Viel Geld, wenig Zeit" entwickelt und das Hobby hat etwas geschlummert. So langsam hat sich aber alles ein wenig eingependelt und ich habe jetzt sogar Platz, um meine Basteleien in Zukunft auch in der Praxis einsetzen zu können.

An der Firmware für meine Komponenten habe ich nur sehr begrenzt weiter gearbeitet. Hier und da ein paar Anpassungen, aber aktuell bin ich relativ "fertig" mit dem, was ich mir vorgenommen habe, bis neue Bedürfnisse aufkommen oder jemand anderes meine Komponenten einsetzen möchte.

Allerdings habe ich die letzten Wochen mal wieder etwas in die Tasten gehauen und habe mich an ein Neues Projekt gewagt: Das MäCAN Control Panel (GitHub):




Da es ja durchaus Hobbykollegen gibt, die andere Interfaces als den SRSEII von Gerd benutzen, wollte ich eine alternative und bequeme Möglichkeit schaffen, um mit dem CAN-Bus zu interagieren. Und vor allem wollte ich eine komfortablere Möglichkeit, meine Komponenten zu konfigurieren und mit neuer Software zu versehen. Bisher implementiert ist folgendes:

• TCP-Schnittstelle: Die Kommunikation findet über das von Märklin dokumentierte TCP-Protokoll statt. Theoretisch sollte das Programm mit jedem Interface funktionieren, das dieses Protokoll nutzt. In der Praxis habe ich nur einen SRSEII, auf den ich für meine Tests zurückgreifen kann (Hier wäre ich für Erfahrungswerte mit anderen Schnittstellen dankbar).
• CAN-Monitor: Die funktionsweise ist identisch zu Gerds can-monitor auf dem SRSEII, mit der Einschränkung, dass nur das sichtbar ist, was per TCP an das Programm gesendet wird. Die Befehle einer anderen Software, die die selbe Schnittstelle benutzt, sind nicht sichtbar, sofern die Schnittstelle diese befehle nicht zurück spiegelt. Bisher habe ich noch nicht die vollständige Aufschlüsselung der CAN-Frames implementiert, das ist aber nur ein wenig Fleißarbeit, um die Strings entsprechend zu formatieren. Zukünftig will ich noch umfangreiche Filteroptionen implementieren, mit denen man besser nach spezifischen Frames suchen kann.
• Gerätemanager: Hier werden alle Geräte angezeigt, die auf dem physischen Bus auf Pings reagieren. Hierüber können die Geräte genauso konfiguriert werden wie über die CS2/3 oder den MäCAN-Server. Messwerte werden auch abgefragt und angezeigt.
• MäCAN-Updater: Bisher hatte ich zwei alleinstehende Programme für diese Aufgabe, ein mal für Windows per TCP und ein mal für den SRSEII. Den Updater habe ich nun auch in das Control Panel integriert womit keine Befehlszeilenwerkzeuge mehr notwendig sind. Ein Update kann vom Gerätemanager aus angestoßen werden. Damit können Geräte, die meinen Bootloader benutzen, mit neuer Firmware ausgestattet werden.

• Manuelles eingeben von CAN-Befehlen
• Rückmeldermonitor
• Schalten von Magnetartikeln mit umfassenden Einstellungsmöglichkeiten für Protokoll(erweiterungen) und Befehlsstruktur (vor allem, um meine eigenen Komponenten komfortabel testen zu können).
• CV-Editor

Hallo zusammen,

Ich verfolge das Projekt im Stillen auch schon eine Weile.
Den Ansatz finde ich sehr interessant.
Ich habe allerdings eine andere Anwendung als Ziel.
Ziel wäre es eine Mehrsystem fähige "Anlage" zubauen in H0, bei dieser soll man in 2- & 3-Leiter fahren können inklusive Rückmeldung.
Nachdem ich eine kleine Schaltung gebaut hatte und diese mit einem Arduino getestet habe (bzgl. Umschalten und Rückmeldung), bin ich nun dabei diese auf dieses Projekt abzuwandeln.
Die Schaltung verwendet Mono-Stabile Relais für das Umschalten (unbestromt sind die in der Stellung für 3-Leiter), die Rückmeldung geht immer an den gleichen uC-Pin egal ob 2- oder 3-Leiter aktiv ist.
Als Basis habe ich die Dx32 Schaltung verwendet. Die uC-Ports A und J sind unverändert in der Nutzung, der uC-Port K möchte ich für die Umschaltung nutzen. uC-Port C, F, H, L (E & B) welche bisher auch als Rückmeldung + LED Feedback verwendet wurden, habe ich mit ULN2803 Treibern versehen um daraus mal einen Weichendecoder für's C-Gleis zu machen oder sonstiges anzusteuern.

Die Hardware ist momentan per DHL unterwegs zu mir und ich arbeite mich so gut es geht in den Code ein, hoffe ich pack das.
Ich orientiere da mich v.a. an der SW für's Dx32 und den MP5x8+S. Ich meinte immerhin bisher die Pindeffinition richtig gesetzt zu haben...
Theoretisch sollte logischerweise auch die Rückmeldung schon funktionieren, Challenge für mich ist nun jedem Pin von Port K eine Adresse zuzuweisen und diesen Port nur ON/OFF zu verwenden ohne, dass er automatisch abschaltet, sowie für die Übrigenports pro zwei Pins eine Adresse festzulegen in abwechselnder Ansprechung, diesmal mit automatischer Abschaltung.

Mit freundlichen Grüssen
Simon

Hi Maxi,

Zitat von Ixam97 im Beitrag #25

---

---

Zitat von FarFarAway im Beitrag #33

---

Kannst du mir da evtl. eine Bezugsquelle nennen?
Oder ein Aequivalentes Bauteil?

Cheers,
Klaus

---