THEMA: Digital per Ethernet ?

Eine Modelleisenbahn ist vom Prinzip her ein Feldbussystem. Mit den Industrie-Feldbussen gemeinsam hat es die Eigenschaft, dass da nicht "sinnfreie Daten" herumkuven, sondern eine sich bewegende Hardware in Echtzeit gesteuert wird.

Die Feldbussysteme sind darauf hin optimiert (und das ist wichtig).

Ethernet basiert auf CSMA/CD (carrier sends multiple access / collision detection), auf deutsch: Alle schnorren wild drauf los. Wenn einer nicht verstanden hat, ruft er "nicht verstanden, wiederholen" und das passiert je häufiger, je mehr Endgeräte (aka Decoder) am Netz sind. (Das erklärt auch , warum Switches für den Ersatz von Hubs erfunden wurden.) Aus meiner Sicht ist Ethernet so etwa das ungeeignetste Protokoll überhaupt für eine Feldbusnawendung.

> Bitte haltet mich nicht für verrückt

Ich halte dich nicht für verrückt - ich *weiss*, dass du verrückt bist

Felix

Um den Ball mal aufzugreifen...

@1: Welches Feldbussystem hälst du für geeignet?

Fragt
Lavamat

dann "spinn" ich mal weiter

@1:
>dass da nicht "sinnfreie Daten" herumkuven
Dieses sollte/kann man unterbinden. Ich meinte ja nich, das man die Anlage
direkt ans LAN oder noch schlimmer ans Internet hängen sollte.
(Mach ich ja noch nicht mal mit meinen PCs)
Die Anlage sollte in einem seperatem Netz laufen und die MCs an einem Switch
hängen. Im Ethernet sind alle Teilnehmer gleichberechtigt und die "Gesprächigkeit"
der Teilnehmer kann man auf das notwendigste reduzieren.

>Wenn einer nicht verstanden hat, ruft er "nicht verstanden, wiederholen"
Ist doch OK. Das dieses öfter vorkommt je mehr Teilnehmer bzw. mehr Daten
übers Netz gehen ist klar. Wie häufig denkst du kommt das denn vor ?
Man sollte das nicht mit einem normalen LAN vergleichen wo etliche PCs,Router,
Switche, etc.. dranhängen.Wenn man die MCs entsprechend programmiert.
Zusätzliche Sicherheit könnte noch mit QoS sowie getrennten Netzen fürs
Schalten und Rückmelden erreicht werden.
Wie funktioniert z. Zt. im Modellbahnbereich das Schalten und Rückmelden ?
Wenn ich das richtig verstanden habe werden in regelmässigen Abständen die
Teilnehmer abgefragt bzw. mit neuen Informationen versorgt. Ich kann also immer
erst im darauffolgenden Zyklus auf Ereignisse reagieren bzw. feststellen ob die
Übertragung erfolgreich war. (Hat dann die bekannten Grenzen)

Folgende Vorteile sehe ich beim Einsatz von Ethernet :
1. Reduzierung der übertragenen Daten, ich spreche nur den Teilnehmer an
    den ich erreichen möchte bzw. nur die Teilnehmer die was zu melden haben
    senden Ihre Informationen.
2. Reduzierung der Hardware , eine Komponente die je nach Programmierung
    unterschiedliche Aufgaben übernimmt , leichter Tausch von defekten
    Komponenten
3. Sicherheit , da jedes Gerät am Bus gleichberetigt ist kann dieses alle
    angeschlossen Geräte ohne zutun einer Zentrale in einen definierten Zustand
    versetzen(Broadcast).
    Die MCs besitzen auch Interrupts , welche als Nothalt dienen können, z.B.
    per Schalter rund um der Anlage
4. autonom , Bsp. Schrankensteuerung, ein MC überwacht die Strecken vor und
    hinter einem Bahnübergang, fährt ein Zug in einer diese Strecke veranlasst der
    MC das Senken der Schranke, hierzu fallen mir noch etliche Bsps. ein

Wie gesagt sind nur so Gedanken.

Wenn jemand gute Argumente für vorhandene Systeme hat , immer her damit.
Vielleicht hab ja was übersehen.
Mein Hauptanliegen ist eigentlich , das wenn ich schon einen PC zum fahren und
schalten nutzen möchte nicht unbedingt noch eine Zentrale dafür benötige.
Wenn es sowas wie DDW/DDL für SX geben würde, würde mir das evtl. schon
reichen, da dann fahren und schalten über einen BUS luafen würde.

Gruss
Hannes

Selectrix oder DCC, da bereits erfunden und für die Bedürfnisse der Moba massgeschneidert...

Felix

@3
> >Wenn einer nicht verstanden hat, ruft er "nicht verstanden, wiederholen"
> Ist doch OK... Wie häufig denkst du kommt das denn vor ?

Man redet bei einem 10BaseT von 4MBit Nutzdaten, also 60% Verlust... (!)

Bei einem Feldbus gibt es keine Kollisionen, weil das Protokoll so gebaut ist, dass der "Gesprächsleiter" (also die Zentrale) nacheinander die Teilnehmer "aufruft" und nur der redet, der dazu die Erlaubnis hat. Dieses Konzept ist schon per Design leistungsfähiger.

> Mein Hauptanliegen ist eigentlich , das wenn ich schon einen PC... nutze...
> nicht unbedingt noch eine Zentrale dafür benötige

Kein Problem! Es gibt diverse Berichte von Freaks im Internet, die ihre Digitalanlage ab PC steuern, d.h. das Digitalsignal im PC generieren. (Zumindest wenn ich das richtig in Erinnerung habe.)

Da fragst du aber besser die Digital-Spezis, zu denen ich mich eigentlich nicht zähle. Das bisher gesagte drehte sich ja mehr um Netzwerk-Allerlei.

Felix

Hallo Hannes,
Hallo Felix,

die Idee mit PC via Browser eine MoBa zu steuern ist nicht völlig neu, zur Zeit aber noch technischer Overkill. Browser "sprechen" gewöhnlich HTTP und ein bisschen FTP. HTTP ist sehr voluminös, aber bei 10 oder mehr Mbit/s Netzen geht das - für menschliche Bedürfnisse, also Reaktionszeiten >0,1s.

Felix hat Recht, wenn er (Industrie-)Feldbusse als die geeigneteren Systeme für Echtzeit-Steuerungen anführt. (Auf der letzten embedded-Messe hat ein WindowsCE-Sprecher von "hartem Echtzeitbetrieb" gesprochen. Ich hab Ihn gefragt, was er damit meint, z.B. wie lange es dauert, bis auf einen Interrupt ein Task losläuft (LOSLÄUFT != adäquat geantwortet hat). Bei 3GHz Systemen wären wohl 50..100µs möglich... Ich habe gedankt und bin gegangen. Bei Feld- Wald und Wiesen µC´s liegen die Reaktionszeiten auf Interrupts unter 5µs, oft unter 1µs.)

Dafür sind die Datenmengen, die bei Echtzeitsystemen transportiert werden, deutlich kompakter. Der µC verbraucht entsprechend weniger Ressourcen. Ein Miniwebserver mit nur 1..2KB RAM ist ein echter Krampf, aber es werden nunmal Datenpuffer gebraucht. Ein Lokdecoder hat vielleicht 64 oder 128 Byte (nicht KB!) insgesamt (auch für den Stack). Und wieviel Strom soll die Lok mit ´nem TCP/IP Interface ziehen? 10 oder 100 MBit über die Gleise? EMV? Reboot-Reconnect-Delay nach Powerfail?.....

Also wenn überhaupt (zur Zeit), dann via Interface PC <-> Digital-MoBa-Steuerung. In wieweit das mit/ohne Zusatz-HW gemacht wird ist Geschmackssache. Für gewöhnlich bieten die diversen Zentralen ja eine Schnittstelle, über die alle (?) relevanten Infos hin- und hergebeamt werden können. Daran kann man "bequem" einen Webserver klemmen und den Rest dann via Browser steuern.

Nichts für ungut, ist halt meine Meinung dazu...

cosinus

Hallo zusammen,

erst mal danke , für eure Meinungen.
Vielleicht habe ich mich etwas unglücklich ausgedrückt.

@5
Das ein Feldbus die bessere Lösung wäre, ist gut möglich.
Im Prinzip soll/kann ja der PC die Zentrale spielen und die angeschlossenen Teilnehmer der Reihe nach abfragen. Die Teilnehmer sollen nur in "Notsituationen"
selbständig aktiv werden.
Das bei TCP/IP ein Overhead an Daten vorhanden ist auch klar. Alleine der Header
ist schon 24Byte gross, besonders wenn evtl. nur 4-6 Byte an Nutzdaten anfallen.

@6
Die Mikrocontroller sollen nicht unter Windows laufen , Gott bewahre.
Die Dinger werden in C oder Assembler programmiert. Im Prinzip läuft dort nur ne
Endlosschleife die die Eingänge überwacht , bei Bedarf Ausgänge setzt oder auf
Interrupts reagiert und das sehr flott.  

Im Prinzip würden die Aufgaben der Zentrale auf mehrere "SubZentralen" verteilt.
Die Kommunikation würde über Ethernet laufen.

Wie gesagt , sind bisher nur Gedankenspiele.

Gruss und schönes WE
Hannes

Hallo Hannes,

jetzt denk mal weiter. Wieviel Feldbus, wieviel Ether, wieviel lokale Intelligenz?
Es wäre HW-Overkill nur ein paar digitale I/Os mit einer Ethernet-Schnittstelle auszurüsten, oder? Also etwas mehr als nur ON/off - kaum hast du den µC programmiert, fällt dir was ein, was anders laufen soll. Also umprogrammieren oder SW mit Parametern konfigurieren (vgl. DCC-Lokdecoder und deren Einstellmöglichkeiten). Dann wächst aber zwangsläufig das Datenvolumen und der Protokollaufwand. Wenn jetzt noch Leben in die Bude kommt, sprich 10 Züge simultan unterwegs, sollte man die Latenzzeiten von Ethernet/TCP/IP mal kalkulieren. Das worst-case-scenario tritt u.U. schneller ein als es einem lieb ist.

Ich würde (Gedankenspiel) mir die IST-Daten aus der Steuerzentrale absaugen und via MiniWebserver ins lokale Netz stellen. Das dürfte zum Abschätzen der Echtzeiteigenschaften schon interessant sein. Wie sehr hängt das Web-Abbild der Realität nach? Würde eine falsch geschaltete Weiche schnell genug erkannt werden ? Nur mal zum Gedankenspielen....

Gruß
cosinus

P.S. und schönes WE

Hallo.

In der Automatisierungstechnik geht der Trend derweil geradezu rasant Richtung Feldbus auf der Basis des Ethernet. Das oben schon erwähnte Übertragungsverfahren mit den Kollisionen etc. erschwert es schon, eine Steuerung mit garantierten Reaktionszeiten (Echtzeitverhalten) zu realisieren. Diesbezüglich hilft man sich, in dem man den Teil des Ethernet-Netzwerkes, welcher auch als Feldbus fungieren soll quasi nur über einen speziellen in der Steuerung integrierten Switch an das restliche Netzwerk anbindet. Die Steuerung und der Switch arbeiten dann mit einen speziellen Protokoll, welcher die Feldbusdaten bevorzugt transferiert, so dass ein Echtzeitverhalten zu stande kommt. In der Zeit, in der keine feldbusspezifische Kommunikation läuft, wird dann der ganz normale Datentransfer abgewickelt.

Einer der Vorreiter sind dort beispielsweise die Fa. Beckhoff (nein, ich bin da nicht angestellt, verwandt oder verschwägert). Bei denen im Internetauftritt links unter "Feldbuskomponenten/EtherCAT" schauen. Dort ist auch das Funktionsprinzip ganz gut erklärt

http://www.beckhoff.de/

Die Siemens-Leute haben mit ihrem Produkt "PROFINET" auch ein Beitrag zum Thema Feldbus über Ethernet geliefert.

http://www2.automation.siemens.com/profinet/index_00.htm

Grundsätzlich lassen sich alle diese industriellen Produkte zum Steuern einer Modellbahn benutzen. Sogar richtig gut. Aber wenn man mal einen Blick in die Preislisten geworfen hat, dann hält man plötzlich die teuerste Lok von beispielsweise M*trx für ein günstiges Schnäppchen. Ausserdem sind die Produkte aus der Automatisierungstechnik nicht einfach so an den häuslichen PC anzuschliessen. Bei den Beckhoff-Leuten beispielsweise gehören zu den Klemmen, mit denen man Steuern und Abfragen könnte noch jeweils eine eigene Steuerung. Wahlweise als separates Gerät oder als Softwarelösung im PC. Und die Preisspirale dreht sich weiter...

Grüße
WGK

Beitrag editiert am 01. 10. 2005 01:53.

@7
> Das bei TCP/IP ein Overhead an Daten vorhanden ist auch klar

Ich hab nicht von TCP/IP geredet, sondern von 10BaseT Ethernet. Der Durchsatzverlust tritt bereits sehr früh ein - aufgrund der Kollisionen, nicht (nur) wegen des Overheads. (TCP/IP hat mit Ehternet nur insofern etwas zu tun, als dass man das eine auf dem anderen laufen lassen kann.)

Guckst du hier
http://www.elektronik-kompendium.de/sites/kom/0301201.htm
http://de.wikipedia.org/wiki/OSI-Modell

Dann wäre da noch eine andere Frage:
Die Übertragung zu den Loks. Diese erfolgt über das Rad/Schiene-System, welches in Bewegung ist und womöglich Haftreifen das ganze noch zusätzlich verschlimmern. Das ist von der Datentechnik her gesehen ungefähr die dreckigste Verbindung, die man sich vorstellen kann (noch paar mal schlechter als Schleifringe), mit entsprechend verheerendem Einfluss auf die Datenrate. Warum wohl arbeitet DCC mit etwa 4kHz? ...

Und mit der Übertragungssicherheit der physischen Ebene steht und fällt die ganze Kommunikation...

Felix

Beitrag editiert am 01. 10. 2005 08:49.

Ist DCC nicht irgendwas mit 8KHz ?

Günter

Hallo Günter,

laut MIBA extra, MoBa digital: 1er bits 116us, 0er bits 232us. Such´ dir die Frequenz selber aus...

Hallo Hannes,
WGK hat Recht, der Trend geht im Sinne der Factory Automatisation und ERP und was sonst nicht noch für schöne Anglizismen herumschwirren in die total vernetzte Bude. Ich glaube aber nicht, das die Steuerdaten für einen Schweißrobotor tatsächlich auf jedem angeschlossenen PC abrufbar wären - es macht ja auch eigentlich wenig Sinn. Wenn ein Management wissen will, was welcher Apparat gerade tut, sind Vorschubdaten für irgendeine Achse ja wohl kaum die gewünschte Info . Ohne nachgeschlagen zu haben, ich denke 1Gbit/s oder mehr wird wohl schon erforderlich werden, wenn Echtzeit ins Spiel kommt.

Außerdem - wie WGK ja schon sagt - es sind -mal wieder- spezielle Protokolle. IP ist ja nur die Verpackung, TCP eine Zusatzverpackung für den sicheren Transport. Darüber erst fängt HTTP oder FTP an - das in einen Lokdecoder zu impfen LOL.

Auch Felix hat vollkommen Recht mit seinem Hinweis, das die DÜ über das Gleis im Wesentlichen aus Fehlern besteht, die von gelegentlichen heilen Datenpaketen überrascht werden (*g*). Abgesehen davon werden die Störemissionen bei wachsenden Frequenzen immer schwerer kontrollierbar (Flankensteilheit). Auch 10Mbit Netze arbeiten mit verdrillten und gewöhnlich auch geschirmten Kabeln. Schienen zu verdrillen? Könnte sich negativ auf das Rollverhalten auswirken...

Euch allen ein schönes WE

cosinus

OT..PS: Hallo Günter, wenn ich heute Abend auf der A7 gen S/H rolle, werde ich an die Heideprellböcke denken. Hätte euch gerne mal kennengelernt, aber ich konnte es nicht einrichten - hoffentlich ein ander Mal.

Jo, Arne....
in punkto digitales Fahren habe ich erhebliche Wissenslücken, welche m.E. dringenst gefüllt werden müssen.

Aber mal zum Thema hier:
was würde ein Blick in Richtung Kfz Industrie bringen bez. der dortigen Verfahrensweise ( CAN-Bus System) ?

fragt
Günter

Hallo zusammen,

ok, viele Argumente die dagegen sprechen. Dass das nicht so adhoc gemacht
werden kann ist schon klar. Für unmöglich halte ich es dennoch nicht.

Ich werde mir mal auf alle Fälle die Projekte zum Thema RealTimeEhternet
etwas genauer anschauen.
Ob das dann technisch und köstengünstig umzusetzen ist , wird man sehen.

Gruss
Hannes

@13
Hallo Günter,
auch ich bin kein DCC/Selectrix/was_sonst_noch Spezi, auch mit ProfiBus und CAN habe ich nicht direkt gearbeitet, lediglich InterBus-S habe ich/wir beruflich genutzt, außerdem habe ich vieles in Sachen LON gelesen.

CAN bietet Echtzeitfähigkeit, die integrierte Priorisierung (Adressen mit führenden Nullen gewinnen vor Einsen) und die unmittelbare DÜ-Kontrolle (lesen während des Sendens) erhöhen die Sicherheit und den Durchsatz. Wahrscheinlich (es gibt ja viele µC´s mit integr.CAN-Schnittstellen) lassen sich damit recht bequem die MoBA Anforderungen abdecken - wobei ich dabei jetzt nicht an Lokdecoder denke, sondern Weichen schalten, Belegtmeldungen erfassen/weiterleiten, etc.

Leider bin ich z.Zt. nicht zu Hause und kann mir die CAN-Spec anschauen (es gibt sie aber frei im Netz, Bosch CAN Specification 2.0A müsste als Suchbegriff ausreichen). Ich glaube aber es waren 6 oder 8 Byte Nutzdaten im kurzen Standardprotokoll und Bitraten von 9600 bit/s als quasi untere Grenze (1 Mbit/s geht auch). Leider hat mein Eiweißspeicher viele Details nicht mehr abrufbereit - liegt halt daran, dass ich beruflich diese Sachen auf Nutzbarkeit für (berufliche) Anforderungen lese, wenn´s dann nicht so gut passt, sinkt die Aufmerksamkeit...

Die Idee von Hannes vertsehe ich so im Sinne von: System ala G+R aber dezentral mit vernetzten MCs (bei Hannes Vernetzung via Ethernet & TCP/IP) oder - aus bereits geschilderten Gründen - vielleicht über eine andere digitale Kommunikationsstrecke. Hier ist CAN vielleicht unter Preis/Aufwand/Leistungs Gesichtspunkten optimal. Sonst würde man ja auch mindestens an RS485 denken und CAN ist da ähnlich.

Hmmm, mir fallen jetzt plötzlich tausende von Sachen dazu ein - Multimaster, lokale Gruppen, Leitzentrale, alles mit CAN durchaus machbar - aber sinnvoll oder erforderlich??? Das könnte ein langes, interessantes aber evtl. auch kontroverses Diskussionsthema werden.

Soweit von einem fürchterlich verschnupften
cosinus

Naja, I²C wär ja auch nicht so ein ungeschickter Bus für die Modellbahnsteuerung...

Enrico

PS: der CAN-Bus 2.0A hat bei 64 Bit Daten eine Bitrate von 125 kHz und eine Latenzzeit von ca. 1 ms. Der Vorteil ist seine hohe Datensicherheit.  

Beitrag editiert am 02. 10. 2005 17:21.

I²C ist bei längeren Übertragungswegen schwierig zu handhaben, ob die Störsicherheit im MoBa - Betrieb ausreicht, wage ich zu bezweifeln. Und mit der Geschwindigkeit ist das auch nicht so dolle.....

Hier denke ich, das ein CAN-System in Verbindung mit RS-422 (oder 485) eine feine Sache wäre.....

meint ersnthaft am frühen morgen,
Günter

Günter, was verstehst Du unter "längeren Übertragungswegen? 1m, 10m, 100m, 1000m?

I²C: Durch die Geschwindigkeiten 100kbps/400kbps/3.4Mbps in den drei Modis  Standard/Fast/Hi-Speed und die maximale Buskapazität von 400pF ohne Bus-repeaters sind mit den richtigen Kabeln 20 - 40m je Abschnitt ohne Probleme machbar. Die Störabstände sind wie bei TTL - allerdings halt geschirmte Leitungen, immerhin wird der I²C auch für Gebäudeautomatisation verwendet und dort gehts auch nicht gerade störungsfrei zu, wenn eine Leuchtstoffröhre so vor sich hinblinkt.

Der I²C ist halt ein ziemlich einfacher und billiger Bus, natürlich ist ein RS-485 in Umgebungen mit hohen Störeinflüssen besser, allerdings kann man bei einem RS-422 System unidirektional halt nur 10 Empfänger/Sender verwenden, in einem RS-485 wenigstens 32 bidirektionale Teilnehmer. Allerdings muss für große Buslängen wieder eine (galvanische) Massetrennung vorgesehen werden - je besser der Bus, desto mehr halt der Aufwand.

Zu den Geschwindigkeiten: der CAN-Bus hat entweder Lowspeed (100 kbps) oder Hi-Speed (1 Mbps) und erlaubt Leitungslängen bis etwa 500m bei Lowspeed und etwa 40m bei Hi-Speed. Durch den hohen Aufwand der Datensicherung (CRC und Bitstuffing) ist der Durchsatz aber geringer als bei anderen CSMA/CD-Systemen.

Jetzt wäre halt zu definieren, was man auf üblichen Modellbahnanlagen oder bei Modultreffen für Geschwindigkeiten, Buslängen und Störfeldstärken hat, wobei ich meine, dass übliche Anlagen mit I²C gut bedient wären, so wirklich nette große Modultreffen mit 300m+ Fahrstrecken wahrscheinlich mit einem Feldbus besser bedient wären.

Bedenkt man, dass zB LocoNet auch nur 15mA Konstantstrom (max +/- 24V) hat und bei großen Modultreffen voll ausreichend ist, würde wohl I²C auch ganz schön lange reichen...

LG
Enrico

Ich kriegs nicht mehr ganz zusammen, aber ich glaube in der LINUX-Welt hat mal einer versucht, einen PC als Zentrale aufzubauen und damit die Anlage zu steuern. Der Bursche hatte dazu auch eine Schnitstelle entwickelt IIRC.

Wie das ganze genau gefunzt hat, weiss ich leider nicht mehr ... ist schon ein paar Jährchen her  ....

Stand mal irgendwo in einem LINUX Magazin .... war aber wahrscheinlich mehr Marketing (was LINUX alles kann) als alles Andere

andere Grüsse,
Claus

Naja, man kann ja auch DDL verwenden = DCC für Linux. Da braucht man nur die (freie) Software und einen Booster und schon läufts - obendrein kann man die alten PC dazu aufarbeiten

LG
Enrico

Enrico, ich glaube das war es.

Ist aber wahrscheinlich nicht, was sich der Hannes gedacht hat.

Hmm, ein paar Schrottkisten kann ich hier wieder aufmöbeln ...... DCC? Hmmm.....

dankende Grüsse,
Claus

Claus, es gibt auch DDW = DCC unter Windows - für die unter uns, die keine Linux-Spezialisten sind.

Link: http://home.snafu.de/mgrafe/

Der Link für Linux: http://www.vogt-it.com/OpenSource/DDL/

liebe Grüße

Enrico

BTW: wieviele Stunden sind denn eigentlich Zeitunterschied zu MEZS?

Beitrag editiert am 03. 10. 2005 16:23.

Hallo zusammen,

ich hab mir mal vershcieden Bus-Systeme angeschaut.

1. RealTimeEhternet wird schon in der Praxis (PC- und Embedded) mit Standardkomponenten eingesetzt.
   Für Mikrocontroller laufen schon Tests , sind aber noch nicht optimal.
   Stichwörter : RTNet, RTAI
2. I²C : wäre eine alternative, wie unter #18 gesagt. Nachteil sehe ich darin, max
   110-120 Teilnehmer pro Bus und das es ein Master/Slave-System ist.
   Der Master fragt regelmässig die Slaves ab - ähnlich SX.
3. CAN : hohe Störsicherheit, Übertragungsraten von 10 kbits/s (6km) bis
   1 Mbits/s (40 m) , Echtzeitfähig, kostengünstig (CAN fähige MCs gibts ab 3€),
   Datenpakete zwischen 1 und 8Byte
   Wo ich evtl. ein Problem sehe, ist das die Controller sich bei mehrfach
   auftretenden Fehlern vom Bus abkoppeln, müsste man sich genauer anschauen.
   Ist nun die Frage wie andere Busse das handhaben

Wenn Feldbus , würde ich CAN vorziehen da Multimaster , jeder Teilnehmer kann
Informationen an eine Zentrale oder an einen anderen Teilnehmer senden.
Ich könnte mir vorstellen, das eine Zentrale regelmässig - 10-20/Sek. - den Bus
abfragt. Zusätzlich kann jeder Teilnehmer bei Eintreten eines Ereignisses - z.B.
Gleis belegt - dieses an die Zentrale senden.
Bsp:
Ein MC wird als GBM eingesetzt, dieser überwacht 2 Abschnitte vor und hinter
einem Bahnübergang. Fährt nun ein Zug in einem dieser Abschnitte , senkt der MC
von sich aus die Schranke und gibt diese Info auf den CAN-Bus (Anzeige in der
Zentrale).
Vorteil ist , das nicht erst die Zentrale den GBM abfragen muss ob das Gleis
belegt ist und dann das senken der Schranke veranlasst.

Die MCs liessen sich ja für ganz andere Sachen nutzen, da fallen mir noch
tausend andere Sachen ein.

@#20,#21 : DDL/DDW zum Fahren und MCs zum schalten und melden.
  DDL/DDW nutzt den S88-Bus zum melden.

Gruss
Hannes

#23
Ein Belegtmelder ist ein Master oder ein Weichenantrieb ist sowohl Master als auch Slave in einem Bussystem - ersterer gibt "ungefragt" seine Belegtmeldung ab, zweiterer erhält als Slave einen Stellbefehl und gibt als Master eine Rückmeldung ab - im I²C also ein Multimasterbetrieb, nicht wie SX!

Übrigens hast Du das Master/Slave-Prinzip auch beim CAN-Bus..., dort koppeln sich aber sogar bei (mehrfachen) Störungen die Master selbsttätig ab - naja, wird lustig sein, wenn eine Weiche dann sagt, mir reichts, ich spiel nicht mehr mit

Ich denke, dass Systeme ohne dedizierte Zentrale sogar besser sein müssten als zentral gesteuerte.

LG
Enrico

#24

I²C ist Multimasterfähig und m.W. nicht so einfach zu realisieren. Kommt ja aus
dem TV/Video Bereich und wird dort als Master/Slave eingesetzt.

CAN wird im Automobilbereich eingesetzt. Das der CAN als Master/Slave
eingesetzt habe ich unter #23 ja schon geschrieben. Wäre hilfreich wenn sich
ein Teilnehmer abgekoppelt hat, ist dieser nicht mehr erreichbar könnte daraufhin
die Anlage in eine definierten Zustand - Nothalt - versetzt werden.

Hier - http://bahn-in-haan.de/_nmradec.html - gibts schon Lösungen mit MCs als
Decoder für DCC.

Gruss
Hannes

Enrico,
wie hier schon gesagt, stammt I²C ursprünglich aus der "braune Ware" Branche und wurde erstmals von Philips kreiert.
An Entfernungen dachte damals niemand so das beim Ursystem bei mehr als einem Meter Schluss war
Durch die Verringerung des SCL konnte zwar die Reichweite erhöht werden, aber bei fünf Metern war das System grottenlangsam. Da wäre ein FSK Betrieb schneller.......
Ich weiß, das Matsushita mal in den 90ern des letzten Jahrhunderts damit experimentiert hat um einen höheren Datendurchsatz zu erreichen, ist aber eingestellt worden. Man hat den Bus dann dort für Neuentwicklungen nicht mehr verwendet. Für Standardanwendungen (Listener / Talker) wird er allerdings in modifizierter Form heute noch verwendet.

So denne,
Günter



Beitrag editiert am 03. 10. 2005 19:58.

#25

Ja, Du hast schon recht, Neuentwicklungen werden mit dem I²C nicht mehr wirklich gemacht. Das mit dem CAN-Bus abkoppeln dürfte aber so häufig nicht der Fall sein, denn selbst in starken Störumgebungen wie bei einem Auto (Benziner = Zündung, Drehstromlichtmaschine, Batterie mit hohem Innenwiderstand = schlechte Siebung) sind die Fehler nicht so oft anzutreffen.

Der Link ist interessant, allerdings kenn ich die ATMELs kaum, ich beschäftige mich mit BBriefmarken und versuche nun hinter die Geheimnisse der PICs zu kommen - ich brauche das für ein paar interessante Anwendungen wie Beleuchtung von Modellhäusern, Überwachung von Fahrreglern bzw. als Fahrregler selbst mit Peripherie usw.
Die Idee, auf Ethernet-Basis mit einem vernünftigen Protokoll zu steuern und jeder Einheit eine IP-Adresse zu geben finde ich ziemlich gut - nur wie schaut das dann bei Modultreffen aus, wo jeder für seine Abschnitte Adressen aus dem 10er Adressraum nimmt und die Lok auf einem anderen Modul steuert...

Ich halte Dir die Daumen  - da wird noch viel Wasser *) hinunter rinnen (* bei Bedarf einsetzen: Donau, Rhein, Elbe,....) - aber lass es Dir möglichst schnell patentieren

#26
In der Haustechnik wird der I²C auch noch eingesetzt, obwohl auch dort schon absehbar ist, dass was Neues kommt - nur dort ist nur weniger an Informationen zu übertragen und die Speed spielt auch nicht so eine große Rolle.

LG

Enrico

#27

Die neuen ATMELs kenn ich jetzt auch noch nicht , die ersten von denen waren
kompatibel zu Intels 8051er Reihe - aber mit mehr POWER .

Von den PICs gibts auch welche mit CAN (Bsp: AT90CAN128 ) und bei denen in
den Tiefen der HP gibts auch Beispielcode für PICs mit CAN.
(find jetzt leider den Link nich mehr wieder)

Hier m.M nach noch mal nen interessanten Link:
http://www.miniware.nl/
Dort wird ein RS485 Netzwerk eingesetzt. Weiterhin beschäftigen die sich
mit DDW. Ne interessante Art der Weichenantriebe wird dort genutzt - mittels
Shape Memory Alloy, kurtz SMA - Kabel mit Memoryeffekt.

Gruss
Hannes

Danke für den Link, sehr interessant!

LG
Enrico

willst du sicher, einfach und komfortabel steuern und fahren?
http://www.gahler.de

Ich glaube,
das der Vergleich des Gedankens an die Realisierung einer solchen Steuerung mit der von Gahler ein wenig hinkt.....

Allerdings will ich noch mal was fragen,
kann auch sein, das ich wieder mal was fehlerhaft aufgenommen habe:
RS-485 ist doch nichts weiter wie eine Übertragungsart, bei der Daten über eine Zweidrahtleitung symetrisch übertragen werden so das sich Störungen über den Leitungs weg selbst eliminieren.
RS-485 ist doch kein Protokoll !!!
Insofern kann ich den Einwand nicht verstehen, das per RS-485 nur beschränkt "Ansprechpartner" angesprochen werden können, dies ist doch wohl eher System- und Protokollabhängig.

Oder liege ich da restlos falsch ????

Gruß zum Abend,
Günter



Beitrag editiert am 06. 10. 2005 20:00.

Hallo Günter,
die "liegst" restlos richtig, RS-485 sagt nur etwas über die physikalische DÜ aus, sonst nichts. Seit der "Einführung" von low-current-RS-485 (ich glaube es war MAXIM) ist sogar hier noch ein wenig Aussagekraft verlorengegangen. Alles was über die 7.Ebene (=physical layer) des ISO/OSI-Modells hinausgeht, ist nicht Teil von RS-485.

Gruß zum Abend zurück
Arne

Moin zusammen,

die Idee mit CAN haben anscheinend auch andere.
siehe hier : http://www.elektrocrew.de/
Ist zwar noch nicht umgesetzt aber zumindest in Planung.

Gruss
Hannes

CAN kannst auch bei Zimo schon haben, schon ziemlich lange...

#31 Meinem Dafürhalten nach ist RS-485 OSI Layer 1 und 2.

LG
Enrico