Ich gucke da drüben nur noch sporadisch rein und bereue nicht, mich daraus zurückgezogen zu haben. Nur, warum schreibt hier keiner was?
Statistik: Verfasst von ateshci — Mo 7. Apr 2014, 11:48
]]>
Super, dass es mit dem NetIO jetzt klappt! Tröste dich, mir geht es ähnlich. Töchterchen belegt das Tablet, nachdem sie ihres geschrottet hat. Und das Wiznet-Modul hat mich mehrere schlaflose Nächte gekostet, bis es sich wieder ordentlich ansprechen ließ. Ich hoffe, dass ich jetzt am Wochenende endlich die Steuerung testen kann.
Dann kann ich endlich auch meine Steuerungssoftware damit ausprobieren. Demnächst wird es hier mit Infos dazu weitergehen.
Wir sollten aber nicht geizig sein und für die NetIO-Angelegenheiten einen eigenen Thread eröffnen. Platz genug haben wir ja..
Schöne Grüße,
Michael
Statistik: Verfasst von michaelb — Fr 6. Dez 2013, 19:42
]]>
nun wechsel ich mal hier rüber, weil ich denke, dass die Steuerung mittels Net IO eher zum Software, denn zum Hardware-Unterforum gehört.
Also: auf meinem Tablet hab ich die App (oder heißt es den App?) ans laufen gebracht. Ging ja ganz einfach...
dank den Hinweisen von Michael und Zoltan hab ich`s dann hinbekommen. Danke Euch (Y)
Das kommt davon, wenn die Frau das Tablet für Ihre Bedürfnisse vereinnahmt, ich selbst hab mich damit noch nie beschäftigt. Da sie damit auch ins Internet geht, um Plätzchenrezepte zu suchen, hab ich nu grad in der Vorweihnachtszeit seeeeehr schlechte Karten
Nun könnte man meinen, es geht weiter... Weit gefehlt: ich warte immer noch auf meine Trägerplatinen
Die erste Lok könnt schon laufen, wenn Murphy nicht wär...
lg Thomas
Statistik: Verfasst von papabaer465 — Fr 6. Dez 2013, 14:27
]]>
Ich habe einiges an Aufwand getrieben, damit sich die Oberfläche automatisch möglichst ideal an die jeweilige Bildschirmgröße und -Auflösung anpasst. 1024x600 sind zwar vielleicht nicht ideal, wenn man vor hat, auf dem Tablet viel Text zu lesen, aber für die WLAN-Steuerung reicht es durchaus. Mein erstes Tablet hat diese Auflösung, daher spreche ich hier aus Erfahrung.
Ich habe mir diesen Test des Acer Iconia B1 durchgelesen, da ich das Gerät selbst nicht kenne.
Bildschirmauflösung und Prozessor-Leistung, Speicher mögen nicht großartig sein, für die WLAN-Steuerung ist es aber ausreichend.
Bedenken für unsere Anwendung habe ich allerdings bei folgenden Punkten:
- Das Display scheint sehr lichtschwach und stark spiegelnd zu sein. Diese Kombination macht bei Tageslicht im Garten sicher wenig Freude. Solltest du Innen-Bahner sein, fällt das natürlich weniger ins Gewicht.
- Dem Gerät wird in diesem Test eine geringe Akkuleistung bescheinigt, was bei längerer Aktivität im Freien (besonders in Gesellschaft) auch schnell zum Spaß-Killer werden kann. Intensiver WLAN-Betrieb saugt immer ordentlich am Akku. Da ist damit zu rechnen, dass der Akku sogar noch früher leer ist als in den angeführten Tests.
Je nachdem, wie intensiv du das Tablet einsetzen willst, würde dir eher zu einem deutlich besseren Gerät wie zB. dem Google Nexus 7 raten. Vielleicht lässt sich auch am Gebrauchtmarkt etwas Passendes finden.
Schöne Grüße,
Michael
Statistik: Verfasst von michaelb — So 24. Mär 2013, 00:31
]]>
Gruß
Andreas
Statistik: Verfasst von HaMuKiBahner — Sa 23. Mär 2013, 23:02
]]>
Tony Cannaerts hat geschrieben:Ich würde sehr froh sein wenn da einer art 'Gäste' möglichkeit sein wird.
Hallo Tony!Das wird es ganz sicher geben! Ich halte das für eine ganz besonders wichtige Funktion, denn was ist wichtiger als den Spaß und die Freude mit der Gartenbahn auch unseren Familien und Gästen zu vermitteln? Und dazu ist auf jeden Fall eine einfache, schnell begreifbare und "sichere" Steuerungsmöglichkeit notwendig.
Schöne Grüße,
Michael
Statistik: Verfasst von michaelb — Di 22. Jan 2013, 19:26
]]>
gatzi hat geschrieben:ich bin immer platt, wenn ich Menschen treffe, die so etwas zusammen bauen können.
Hallo Holger!Man soll den Tag nicht vor dem Abend loben
. Davon abgesehen sind deine Überlegungen doch noch viel weitreichender als meine.Das Programm zu erstellen, ist nicht soo schwer, wenn man die Grundlagen erst mal verstanden hat. Viel schwieriger ist es, den Überblick nicht zu verlieren, da das Ganze doch eher organisch wächst und ich in gewissen Bereichen immer noch mitlerne.
Schöne Grüße,
Michael
Statistik: Verfasst von michaelb — Di 22. Jan 2013, 19:20
]]>
ich bin immer platt, wenn ich Menschen treffe, die so etwas zusammen bauen können.
Viele Grüße
gatzi
Statistik: Verfasst von gatzi — So 20. Jan 2013, 19:33
]]>
Das Prinzip meiner Anlagensteuerung geht in die selbe Richtung wie das, was Gatzi hier vorgestellt hat, ist aber noch etwas einfacher gehalten. Folgendermaßen habe ich mir das vorgestellt:
Ich möchte sozusagen über die technische Netzwerkebene eine "Gartenbahner"-Ebene legen. Die logische Struktur dieser Ebene ist dann eben so aufgebaut, wie man es auch im Garten vorfindet. Die oberste Einheit dieser Struktur ist dann eben die Anlage. Die Anlage wird durch ein Stück Software ("Anlagenserver") repräsentiert, das irgendwo im Netz der Anlage läuft. Das kann ein PC, ein Notebook, ein Raspberry Pi oder das Steuerungsgerät des Anlagenbesitzers sein. Man kann aber je nach persönlicher Präferenz auch ganz auf diesen Anlagenserver verzichten. Die grundlegenden Funktionen kann sowieso das Steuerungsgerät des Anlagenbesitzers übernehmen.
Die weiteren Einheiten (Geräte), die es auf so einer Anlage gibt, sind "Controller" (die Steuerungsgeräte), "Loks" (eben alles, was mobil ist) und "Bodenstationen" (alle ortsgebundenen Geräte) - alles, was sich einzeln über das Netzwerk ansprechen lässt.
All diese Geräte melden sich nach dem Einschalten im Netzwerk. Sie rufen, damit es alle hören können zB: "Hallo, ich bin da. Ich bin eine Lok mit dem Namen "Taurus WLB". Mein Besitzer ist "michaelb". Diese Meldung wird solange wiederholt (alle 10s), bis eine Verbindung mit einem Controller hergestellt wurde. Bodenstationen senden die Meldung immer, Loks nur, wenn sie nicht mit einem Controller verbunden sind. Somit wird kein Anlagenserver benötigt.
Lokname+Besitzername sollen zusammen schon ziemlich eindeutig sein. Der Anlagenserver oder das Steuerungsgerät des Anlagenbesitzers überwachen die Namensmeldungen (die verwendete IP-Adresse ist auch noch bekannt) und geben dem Chef einen Hinweis, wenn etwas unkoscher erscheint. Das sollte vorerst reichen.
Die Geräte sollen melden können, welche Funktionen und Einstellungsmöglichkeiten sie anbieten, sodass diese automatisch in der Steuerungsoberfläche angeboten werden können. Die Bodenstationen zB. können verschiedenste Aufgaben übernehmen (Weichen schalten, Beleuchtung, Bahnhofsdurchsagen, Umweltsensoren [Tag/Nacht, Regen], diverse Motorsteuerungen...). An eine netzwerkfähige Bodenstation können ja mehrere "dumme" klein-Steuerungsmodule angeschlossen sein - je nachdem was in der Nähe gebraucht wird. Es besteht keine Notwendigkeit, jedes Mini-Teil selbst netzwerkfähig zu machen.
Sowohl die Anlage als auch die Geräte (nur wichtig für Loks und Controller) haben einen Besitzernamen gespeichert. Somit können fremde Loks aussortiert werden und nur eigene Loks werden im Steuerungsgerät angezeigt. Fremde Loks müssen dann vom jeweiligen Besitzer übergeben werden, wenn sie jemand anderer steuern will (gilt auch für eigene Controller im "Gästemodus"). Der Anlagenbesitzer legt fest, ob das so restriktiv gehandhabt wird, oder ob jeder jede freie Lok übernehmen darf.
Die Loks tauchen somit nach dem Einschalten selbständig in einer Liste im Controller auf und können zur Steuerung ausgewählt werden. Wurde eine Lok übernommen, kann dies ebenfalls gemeldet werden, sodass sie sofort aus den Auswahllisten verschwindet.
Eine Lokverbindung per IP-Adresse (wenn man fixe Adressen verwendet) ist aber immer noch möglich und kann im Steuerungsprogramm auch vordefiniert werden.
Es können mit einem Controller auch mehrere Loks gleichzeitig gesteuert werden. Falls das jemand will, kann ein 2. Steuerungsbereich angezeigt werden, über den gleichzeitig eine 2. Lok gesteuert wird. Gedacht ist aber eher, dass zB. noch Makros und Ereignisse für einen automatischen Verkehr definiert werden können. Wenn zB. eine Lok ein RFID-Tag überfährt und ausliest, kann sie ein Ereignis an den Controller melden "RFID-Tag mit der Nummer XY wurde soeben überfahren". Der Controller meldet das (+ den Namen der Lok, die das Ereignis ausgelöst hat) weiter an alle. Jedes Gerät, das sich durch dieses Ereignis angesprochen fühlt, kann darauf reagieren:
in jedem Gerät können Macros als Reaktion auf dieses Ereignis hinterlegt sein. Und zwar nicht nur für sich selbst, sondern jeweils getrennt für jedes beliebige andere Gerät. Somit bleibt es jedem selbst überlassen, wie er seine Steuerungsstrukturen aufbaut, ob alles im Controller oder im Anlagen-Server oder ganz anders.
Dieses System mit den Macros und Ereignissen bietet ein vernünftiges Maß an Flexibilität. Denn diese Komponenten lassen sich leicht verwalten, von einem Gerät zum anderen kopieren und die Befehle im Macro selbst können jederzeit geändert werden. Wenn jemand ein neues Gerät "erfindet", braucht man nur die unterstützen Befehle ins Macro tippen und schon kann man es in die Anlage integrieren.
Wichtig ist aber, das System trotzdem möglichst einfach und flexibel zu halten, um einen reibungslosen und frustfreien Betrieb sowohl in der ich-will-nur-mal-fahren-Umgebung, als auch bei der Garten-Wunderland-mit Gastbetrieb-Bahn zu ermöglichen. Das wird auf jeden Fall spannend!
Schöne Grüße,
Michael
Statistik: Verfasst von michaelb — So 20. Jan 2013, 19:00
]]>
Statistik: Verfasst von Tony Cannaerts — So 20. Jan 2013, 17:13
]]>
Hi Gatzi,
das ist auch eine Alternative, zumal der DCC-Decoder auch mit analogem Strom gesteuert werden kann, dazu habe ich einen 2 poligen Umschalter in der Lok. R/C ist für mich als auch Echtdampfer kein Thema, allerdings fahre ich nur 40 MHz-Steuerungen, das neumodische Zeug mit 2,4 GHz tue ich mir nicht an.
Eine meiner Überlegungen ist, wenn Karl zunächst nur mit einer analogen WLAN-Steuerung rauskommt (m.E. hatte er mal so etwas geschrieben), dann kommt das Ganze in die B-Unit (WLAN-Modul, MC, H-Brücke), die dann meine analoge Spannungsversorung der A-Unit darstellt. Im Prinzip ersetze ich dann die vorhandenen R/C-Fernsteuerung, Empfänger, Fahrregler und Polwendeschalter durch das analoge WLAN-Projekt und kann damit Michaels Steuerung verwenden. Immer in der Hoffnung, dass auch irgendwann einmal ein digitales WLAN-Projekt kommt.
Schöne Grüße
Johannes
Statistik: Verfasst von Pirat-Kapitan — So 20. Jan 2013, 13:44
]]>
Pirat-Kapitan hat geschrieben:Hi gatzi,
Du bist mit Deiner Idee sicherlich zukunftsträchtiger als meine MAC-Adresse, allerdings hast Du das gleiche Problem beim Austausch der identifizierungstragenden Komponente wie ich mit der MAC Adresse. Bei mir ist sie an das WLAN- / LAN-Modul gekoppelt, bei Dir z.B. an einen Controller (MC oder PC). Auch dieses Teil kann einen Austausch benötigen.
Ja, Johannes, Du bist mit Deiner Idee sicherlich zukunftsträchtiger als meine MAC-Adresse, allerdings hast Du das gleiche Problem beim Austausch der identifizierungstragenden Komponente wie ich mit der MAC Adresse. Bei mir ist sie an das WLAN- / LAN-Modul gekoppelt, bei Dir z.B. an einen Controller (MC oder PC). Auch dieses Teil kann einen Austausch benötigen.
vor Austausch ist nichts sicher, das trifft immer und auf alles zu. Das ist im Grunde ein Totschlagargument.
Nur habe ich in der Vergangenheit eher defekte Tastaturen, Mäuse, Monitore, Festplatten, Schaltnetzteile und natürlich Netzwerkkarten austauschen müssen als ganze Hauptplatinen.Die Frage ist nur, wie unkompliziert ich die am MC angehängten Komponenten auswechseln kann und wie wenig Auswirkungen es dann auf das übrige System hat.
Viele Grüße
gatzi
Für den Schneeeinsatz habe ich eine Lok umgerüstet auf RC, auch funktionierend, marktgäng wie nie zuvor und außerdem vom Schienenstrom unabhängig, obwohl schon dreimal so alt wie DCC ...
Statistik: Verfasst von gatzi — So 20. Jan 2013, 13:28
]]>
Aber das alles ist für mich derzeit Zukunftsmusik, ich rüste gerade meine für das WLAN-Projekt vorgesehene Lok wieder auf Digitalbetrieb (DCC) um, weil ich diese Lok zum Schneeräumen brauche. Und, bei allen systembedingten Einschränkungen, DCC funktioniert und ist bereits heute marktgängig !
Schöne Grüße
Johannes
Statistik: Verfasst von Pirat-Kapitan — So 20. Jan 2013, 12:00
]]>
im Bitte um Verständnis, wenn folgend meine Gedanken etwas weitschweifend sind, aber ich versuche, 'mal über den Tellerrand hinaus zu sehen, zumal man hier dabei ist, Grundlegendes festzulegen, was auf die nächsten Jahrzehnte Gültigkeit haben soll (die Zeit vergeht schneller als gedacht, man denke nur an die DCC-Historie).
Ja sicher, die MAC-Adresse schwirrte mir auch im Hinterkopf herum. Ich dachte jedoch daran, die Organisation der Berechtigungen von der MAC-Adresse abzukoppeln, um bei der Einbindung der Geräte flexibler zu sein, denn die MAC ist nicht im Microcomputer in der Lok hinterlegt, sondern im Wifi-Baustein, der - so unsere WLAN-Philosophie - jederzeit austauschbar sein soll.
Anders ist die Organisation im Computernetz eigentlich auch nicht, denn die IP und MAC werden für den Zugang und die Anbindung ans Netz benötigt und sind in der Netzwerkkarte hinterlegt, nicht im PC selbst. Dieser erhält eine eigene Kennung. Weiterhin werden die Berechtigungen eines Benutzers noch in Rollen zugeteilt. Die Verwendung von Benutzern macht die Arbeit an mehreren Geräten ja so einfach, weil man z.B. seinen Bildschirm/seine Anwendungen von PC zu PC mitnimmt, ohne den PC neu konfigurieren zu müssen, weil der Server registriert, wenn der Benutzer den Platz/PC wechselt.
Mein Hintergedanke ist, die Verwaltung der Loks (Berechtigungen, Funktionen, Einstellungen etc.) unabhängig vom Nachrichtennetz zu gestalten. WLAN, LAN etc. sind nur einzelne Möglichkeiten von vielen, die Kommunikation mit der Lok aufzubauen und im Grunde der eigentlichen Verwaltung untergeordnet.
Wer die Lok steuert, welche Funktionen sie ausführen darf, sollte unabhängig vom Kommunikationsweg sein, damit auch andere Technologien leichter integriert werden können. Ein (Negativ-)Beispiel sind doch DCC, Selectrix und Co.: Sie verbinden die Kommunikation mit der Stromversorgung. Auch wenn die Bediengeräte inzwischen schnurrlos sind, die letze Strecke geht doch von der Zentrale/dem Booster über Kabel und Schienen zum Dekoder. Die bisherigen Digitalbahnhersteller hätten es einfacher, wenn eben dieser Kommunikantionsweg herausgetrennt und beliebig ausgetauscht werden könnte, je nach Stand der Technik. Die Digitalsteuerung ist da auf dem Niveau von vor 30 Jahren stehen geblieben, auch wenn die Bediengeräte noch so vielseitig und schnurlos sind.
Zieht man nun die MAC heran, macht man den gleichen Fehler wie damals DCC: die Steuerung wird an einen Datenweg festgemacht, nämlich an der MAC im Wifi-Baustein. Vielleicht hat die Welt ja mit der IPv6 und dem Internet das entgültige Kommunikantionsnetz für alle Bereiche des Lebens gefungen. Vor 40 Jahren konnte man sich aber wohl auch keinen anderen Weg vorstellen als über Kabel und Schiene zur Lok ... Wer weis was Stand der Dinge ist, wenn wir 30 Jahre weiter sind?
Wenn aber die Verwaltungssoftware (Steuerungssoftware) unabhängig vom Informationweg funktioniert, bildet sie eine Einheit mit der Lok bei höchstflexiblen Weg dorthin.
Aber zurück zu Beispielen von Heute:
Wie wäre es, wenn jemand zu einem Fahrtag kommt, der nur sein Smartphone, Tablet etc. dabei hat und mitfahren darf? Die Anmeldung ist bei einem offenen Netzwerk zu vernachlässigen. ebenso die insallation der Steuerungssoftware. Anders sieht es aber bei den Berechtigungen und damit mit dem Funktionsumfang und die Anbindung an einzelne Loks aus.
Da wäre es womöglich von Vorteil, dieses auf Benutzerkennungen zu verlagern, damit ihm z.B. die Kennung Gast3 zugewiesen wird und er die entsprechenden Einstellungen automatisch erhält. Von daher wäre es auch interessant, diese Benutzerkennung in den Loks zu speichern, damit auch hier eine eindeutige Zuordnung möglich ist. Das erlaubt, schon beliebig viele Gastzugänge vorzuhalten und diese je nach Schwierigkeitsgrad mit verschienenen Berechtigungen (Rollen) freizuschalten. Sogar Zuordnungen zu (heimischen) Loks wäre möglich.
Sollen Gastloks fahren, sind sie ähnlich einfach zu integrieren: Die Kombination aus Besitzerkennung (z.B. Piratenbahn) und Benutzerkennung (Gast1 ... x) und Loknummer (beliebig, auch mehrfach) würde es ermöglichen, Loks sofort vom gastgebenen Bediengerät aus zu steuern, selbst wenn Loks des Gastgebers und der Gäste gleich Namen haben.
Anderer Fall: Der Wifi-Baustein wird ausgetauscht, dann stellt dieser natürlich automatisch eine Verbindung her. Welche Lok es ist und vor allem welche Funktionen mit ihr verbunden sind, wird aber im Microcomputer der Lok abgespeichert. Der Anlagenserver muss nur prüfen, unter welcher IP diese Kennung zu erreichen ist und aktuallisiert die Tabelle, die dann allen Bediengeräten zur Verfügung gestellt wird. Schon flitzt sie wieder los.
Das funktioniert auch an Stammtischen. Probehalber den Wifi des einen Teilnehmers in die Lok des anderen Anwesenden eingesetzt, schon hat sie wieder Verbindung und funktioniert so wie voher, obwohl sich die MAC und die IP geändert haben, ohne dass extra vom Benutzer etwas geändert werden muss ...
Letztlich kann man so auch die Loks besser updaten. Sollen z.B. bei einem größeren Fuhrpark bestimmte Funktionen geändert werden, kann dies automatisch geschehen, wobei es dann völlig egal wäre, auf welchen Weg die Updates in den MC gelangen, ggf. auch über USB-Kabel, MicroSD oder Prgrammierboard. Diese Updates könnten für alle Loks oder selektiv nur für bestimmte Loks vorgenommen werden.
Letzlich muss ich für den Anwender ohnehin eine einfache Bezeichnung zur Verfügung stellen, damit er sich in der Einrichtung und Wartung des Systems leichter zurechtfindet. Wieso dann nicht auch gleich diese in der Lok hinterlegen, unabhängig von IPs, MACs etc.? Denn dann spielt der Weg, mit dem ich vom Bedienteil die Lok erreiche, keinerlei Rolle mehr.
Diese Frage mag in der jetzigen technischen Umsetzung eine Nuance darstellen, tatsächlich muss man sich jetzt darüber unterhalten, wie universell das System wirklich werden soll: Soll nur der MC universelle Funktionsfähigkeiten haben oder wollen wir auch die Steuerungssoftware so weit wie möglich ohne Grenzen gestalten?
Viele Grüße
gatzi
Statistik: Verfasst von gatzi — So 20. Jan 2013, 10:56
]]>
Eine weitere Individualisierung ist m.E. nicht erforderlich.
Mit dieser MAC-Adresse läßt sich z.B. die Zuordnung einer festen IP-Adresse vom Router "automatisieren", ebenso Berechtigungen zur Teilnahme am (Funk-)Netzverkehr. (Wenn ich nur bestimmte Geräte zulasse und Dein Handy / Pad ist nicht dabei, kannst Du auf meinem Fahrtag nur zusehen.
Das bringt natürlich immer, wie jede 2Tabelle" einen gewissen Verwaltungsaufwand mit sich, weil diese "Tabelle" immer aktuell gepflegt sein will. Ein Grund mehr, warum ich meist bei Fahrtagen und Demonstrationsveranstaltungen, wo andere mitfahren können sollen, ein offenes Netzwerk ohne Kontrolle dieser MAC-Adressen und ohne Verschlüsselung verwende.)Schöne Grüße
Johannes
Statistik: Verfasst von Pirat-Kapitan — So 20. Jan 2013, 05:45
]]>