THEMA: Kommunikation IB RS232

Du mußt an der IB die Anzahl der Rückmelder festlegen! Dann sollte es gehen.
In Deinem Fall: in den Grundeinstellungen in "s88 Einstellungen" 2 eingeben.

Gruß Stefan

Wenn ich dort 2 eingebe, decke ich 2 Modulketten ab. Also 2 x 16 Eingänge.

Das hat zur Folge, dass die Signale vom LocoNet Modul 2 Adresse 17 - 25
vom s88 Bus übertackert werden. Also immer unbelegt oder höchstens mal Super-Fast belegt sind. Im Moment ist dort 1 Modul angegeben. also 16 Adressen von denen 8 Adressen vom Viessmann versorgt und 8 Adressen ungenutzt sind.

In der Sonderoption "automatisches Lesen s88" (Befehl SE xx) ist der Wert 2 eingetragen. Es wird also die erste Modulkette des s88 Bus automatisch von der IB ausgelesen, bzw. verwaltet oder was auch immer. Gebe ich dort 1 ein, wird über den Viessmann nichts ausgegeben. Auch nicht am s88 Monitor der IB.

Ich habe es mal mit der WinDigiPet Software probiert. Die zeigt das "Flackern" auch. Die verwenden wohl den gleichen Befehl. Macht ja auch Sinn.

Gruß

Mike

Hast Du die SW-Version 1.3? Dort ist die Programmierung von LocoNet-Modulen verbessert worden, die Beschreibung dazu gibt's bei Uhlenbrock auf der Homepage.
Dann mußt Du bei den s88-Modulen nur eine 1 eingeben und die Programmierung der LocoNet-Module nach Uhlenbrock-"Vorschrift" machen (also auch nur ein Modul.

Was meinst Du mit Kommunikation über RS-232?

Gruß Stefan

Serielle Kommunikation zwischen der IB und dem PC. Die Schnittstelle hat diese Bezeichnung. Industriekonform.

Die Version ist die 1.5 mit Fahrstrassen.

Hallo Mike,
wenn die "serielle Schnittstelle" auch allgemein "Interface" genannt wird, dann gibts ab ner gewissen Datengröße Verarbeitungsprobleme.

>Wegen der geringen Übertragungsraten der Digital-Interfaces können nur wenige Befehle pro Sekunde vom Computer an die Zentraleinheit übertragen werden. Je nach System liegt die Zahl zwischen 16 und 80 <

Mit einer MpC Demo könnten zwar alle Tfz Dekoder, Weichen einzeln und Fahrstraßen geschaltet werden. Macht aber wohl nicht viel Sinn, weil die MpC viel viel schneller ist und immer auf die Zentraleinheit "warten" müßte.

> Um die geringe Datenübertragungsrate nicht noch zusätzlich zu belasten, ist eine Abfrage von Rückmelde- Dekodern zunächst nicht vorgesehen.< (bei MpC)

Aus diesem Grund sind bei einem Rückmelder- Einsatz in Digitalsystemem für die computergestützte Steuerung spezielle Rückmelder- Einlesekarten von G+R erforderlich. Ich persönlich habe damit aber keine Erfahrungen und es würde auch vermutlich die Anschaffung einer MpCD - Grundeinheit erforderlich sein. Nähere Angaben wären dem Handbuch zu entnehmen.

Gruß, AL,-me

Habe mir eben das Handbuch von G+R zu Gemüte geführt.
Also 80 Befehle pro Sekunde an die IB ist selbst bei 19200 Baud eine heftige Angelegenheit. Wozumal die IB nur einen 16 Byte grossen FIFO hat. Dann ist Schluss.

Bin gerade im Netz auf der Suche nach diesen LocoNet oder s88 Buskarten für den PC. Das G+R Zeug ist zwar hochprofessionell aber auch Schweineteuer ;)

Das größte Problem ist die Abfrage der Rückmelder. Wenn ich da die IB umgehen könnte wäre mir schon wirklich geholfen. Die reinen Fahr- und Schaltbefehle setzt ja auch G+R über die serielle ab, insofern die Weichen nicht auch über MpC Komponenten gesteuert werden.

Aber mal rein rechnerisch:
Wenn sich ein PC mit der Abfrage eines Rückmeldemoduls mit 8 Eingängen 50 ms beschäftigt, kann er in der Sekunde max. 20 Rückmeldemodule abfragen. Das sind 320 Eingänge. Das schliesst aber aus, dass noch Fahr- und Schaltbefehle ausgegeben werden.

Im Moment schalte ich noch mit anschließender Statusabfrage der Decoderadresse. Hat zur Folge, dass ein Schaltvorgang etwa 60 ms in Anspruch nimmt. Das kann man halbieren.

Das bedeutet, die reale Anzahl von max. sinnvoll zu überwachenden RMs beläuft sich auf etwa 10 bis 15. Hat ja nicht jeder auch wirklich was zu melden.

Was mich an dieser Art der Überwachung aber am meisten stört ist folgendes:
10 RMs. 5 davon haben was zu melden. Bedeutet: Das letzte Modul in der Meldekette kann sich erst nach etwa 150 ms kund tun. Weiter gefällt mir nicht, dass es zu keinem Zeitpunkt einen Absolutzustand gibt. Also ein Zustand, wo die Logik anfangen kann, die vollständig gesammelten Informationen zu verarbeiten und entsprechende Massnahmen einzuleiten. Hmmm.

Und warum gibt es diesen Zustand nicht?
Weil es über die serielle zu lange dauert, alle Module abzufragen und so ein absolutes Bild zu bekommen. Schwierig, schwierig.

Hat jemand ein solches Szenario mit WinDigiPet und RMs über die serielle?
Wenn ja würde mich interessieren wieviele RMs dran sind und wie das ganze so läuft.

Gruß
Mike

Korrektur.
5 x 50 ist immer noch 250 ;)
Also eine viertel Sekunde!

Hallo Mike,

Ich habe keinen Schimmer, wie die Digitalen Steuerungen mit Interface schnell und sicher funktionieren könnten. Selbst mein schnelles System kann die Schwachstellen der Datenübertragung der Zentralen nur teilweise umgehen, indem es die eigenen Rückmelde- Einlesekarten verwendet.

Außerdem gibts auch schon bei der Lok-Dekoder - Kommunikation Zeitprobleme und wird durch Vergabe von Prioritäten halbwegs aufgefangen. Mich würde so etwas für eine Bahnsteuerung abschrecken.

Laß Dir mal von der Dem die Datei MPC_LIES.TXT anzeigen. Hier gibts auch Info z.B. zur IB + MpCD wie z.B.:

>Es können 20 Belegtmelder-Einlese-Steckkarten 9473 für insgesamt 480
Belegtmeldungen angeschlossen werden. Bei einer geschätzten Anzahl von 3
Belegtmeldeabschnitten pro Block ergibt das ca. 160 installierbare Blöcke.<

Über eigene Erfahrungen mit diversen Digital- Zentralen und Interface verfüge ich nicht; nachdem, was ich hier im Forum alles lesen durfte, wollte ich mir die Einzelheiten ersparen. Mein Interesse daran liegt bei Null und ich denke mir meinen Teil dazu.

Gruß, AL,-me

Warum loggt mich das Forum immer wieder aus <grummel> ;)

Aber es ist in jedem Fall hochinteressant und eine Herausforderung für jeden Herzschrittmacher :D

Die Infos über die Systemgrenzen des G+R habe ich auch schon gelesen.

Ich bin am Grübeln und am Grübeln.
Ich muss das alles nochmal zusammen schreiben.
Also max. Zeit pro Modul und somit max. Anzahl der Module.

Ich habe auch gerade festgestellt, dass man die IB als reines LocoNet Interface verwenden kann. Hmmm. Und was mache ich mit etwaigen s88 Komponenten?

Ich muss das Problem mit der Kommunikation zur IB in den Griff bekommen.
Irgendwie ;) Die IB kann ja schließlich 2048 RM Eingänge verarbeiten.
Jetzt muss ich nur noch herausfinden, wie man die am gescheitesten Abfragt ;D

Hallo,

Ihr seht das zu kompliziert!
Bei 19200 Baud fahrt, bremst und beschleunigt Ihr locker 200 Loks gleichzeitig, abgesehen von den gleichzeitig konstant fahrenden Loks, die keine Befehle benötigen. Theoretisch reichen schon 2400 Baud.
Ich muß wieder mal auf das Forum von Hr. Freiwald verweisen, da sind diese Szenarien bezüglich Baudrate, Schnittstelle und Geschwindigkeit weit und breit getreten worden - http://de.groups.yahoo.com/group/railroadandco_deutsch/messages -.
Geht in die Archivsuche unter Baudrate und die Seiten werden voll. Interessant dabei sind hauptsächlich die Kommentare von Herrn Freiwald dazu.

Mike: Abfragen am besten immer über Software, da die IB zu umständlich zu bedienen ist, oder weißt Du nach 10 Minuten noch, welches "Ei" gerade an welchem Melder dunkel war und wo der Melder hängt. Das ist doch eigentlich der Sinn der Software, die Übertragung auf die realen Gegebenheiten!

Stefan

>Abfragen am besten immer über Software, da die IB zu umständlich zu bedienen ist<
Also hierüber hätte ich gerne etwas mehr erfahren. Wieso denn dann IB, wenn sie umständlich zu bedienen ist ?
IB = Indiskutable Bedienung ?
Gruß, AL,-me

AL,-me,

ich dachte das Thema interessiere Dich nicht? Es ging eben um Rückmeldung.

Eine Rückmeldung von Weichenstellungen und Gleisbelegtzuständen ist, egal ob bei analogen oder digitalen Arrangements, nur im Zusammenhang mit einem Gleisbildstellpult sinnvoll. Im Zusammenspiel mit IB + PC hat man die komfortable Möglichkeit, das GBS per Software ohne Hardwareaufwand (Lampen, Taster etc.)am Bildschirm nachzubilden. Dafür hat man mit der IB eine gute Lösung, da Zentrale, Interface, Programmer und Fahrregler bereits in der Box sind - man muss also nur den PC anschliessen und los geht's.

Grüße, Peter W.

Der Stinkstiefel logged mich immer aus <MAHAAAAANNNNNN>.

@Stefan
hehehe, also ich hab wirklich nicht vor, den s88 Monitor der IB als
optische Hilfe zur Überwachung von Blockstellen und Fahrstrassen zu benutzen.
Da muss man ja ein fotografisches Gedächtnis haben und permanent zwischen den einzelnen Modulen rumswitchen ;)
Genau darum geht es ja. Ich möchte den PC benutzen. Und zwar mit meiner Software. Nicht irgendeiner ;)

Das Forum schau ich mir mal an. Oder News group...

Den Begriff "gleichzeitig" musst Du bei serieller Kommunikation gleich aus Deinem Wortschatz streichen. Denn das ist ja der Sinn der seriellen Schnittstelle. Immer schön eins nach dem andern und zwar hintereinander ;)

Wenn ich 200 Loks einen Fahrbefehl geben möchte, dann rechne mal 200 x ca. 20 ms pro Lok. Das sind satte 4 Sekunden. Rein theoretisch. Denn jeder Befehl erzeugt eine Antwort, die erst mal gelesen werden will. Sonst geht der IB die Galle (sprich der FIFO) über. Und dann verschluckt sie sich :D

Um die Loks mache ich mir auch weniger Gedanken. Außer, wenn mal eine wirklich stehen bleiben muss, aber der Dekoder den Befehl nicht "gefressen" hat.
Aber das ist noch Zukunftsmusik. Erstmal die Rückmelder und ne stabile Kommunikation.

Hab mir gerade noch mal die P50X - Doku reingezogen und ggf. was "entdeckt".

Die Bedienung der IB find ich gar nicht mal so unschlecht. Also ich komme gut damit klar. Solange ich keine Fahrstrassen überwachen will. Die Strassen selbst damit zu programmieren finde ich auch eher etwas ... langweilig.

Gruß Mike

Hallo Peter,

klar, bei meiner MpC läuft auch alles mit GBS wesentlich einfacher.

Nein, ich kannte bisher hier http://www.1zu160.net/digital/zentralen.php nur die Lobeshymne :

>Die wohl beste Multiprotokollzentrale am Markt. <

Dann gibts wohl keine Zentralen mit leichter Bedienbarkeit ?

Gruß , Alfred

Naja, es geht ja nicht NUR um die Nachbildung eines HW-GBS.
Als Schlagworte wären da noch zu nennen:
- automatischer Fahrbetrieb (Fahrplanabarbeitung)
- Überwachung des manuellen Fahrbetriebes
- selbständige Wegfindung, Streckenführung, Ausweichstrecke, etc.

Also alles, was so einer Anlage eine Art von Leben einhaucht ohne selbst Hand anzulegen.

Gruß Mike

Mike,

wenn Du die Überwachungs-Software - und darum gehts ja jetzt - selbst programmieren kannst, dann wirst Du wohl auch bei "externen" Komponenten (zusätzlich zur vorhandenen Zentrale) mal spinxen gehen. Im Handbuch gibts hierzu - bei Routen, Aktionen, Fahrbefehlen und weiteren Automatiken - viele sehr gute Informationen.

Gruß, AL,-me

Die IB kann zwar (fast) alles, aber die Darstellung ist nach wie vor auf das Display bschränkt. Und bräuchte man tatsächlich ein fotografisches Gedächtnis, zumal die Umschaltung in die verschiedenen Modi auch nicht gerade die schnellste ist.
Also gleichzeitig Belegtmeldung kontrollieren, Rückmeldung auswerten, Fahrstraßen schalten und noch fahren, das schaffen nicht mal Siegfired & Roy mit der IB.
Daher kann die IB eigentlich nur Mittel zum Zweck sein - Darstellung über Software am PC oder Anschluß eines externen Gleisbildpultes.

Mike: Was macht die Lok real in 20 MILLIsekunden? Also hast Du dafür schon mal genügend Zeit. Die Rückmeldungen werden doch auch nicht dauernd übertragen, sondern es erfolgt doch in gewissen Zeitabständen eine Rückfrage durch die IB/Software.
Geh mal in die genannte Group, da sind durch den Entwickler ganz andere Gründe genannt, warum die serielle Schnittstelle mehr als ausreichend ist.

Stefan

Noch eins drauf vom Entwickler Railroad&Co TrainController:

"Lassen wir die Detaildiskussion:
Bis heute habe ich in der Praxis mit den gängigen Digitalsystemen noch keine
Betriebssituation auf einer Modellbahn erlebt, wo die serielle Schnittstelle
auch nur annähernd der Flaschenhals war.

Jürgen Freiwald"

Stefan

Der Herr Freiwald hat wohl auch schon alle Kommunikationsprobleme gelöst.
Mal abgesehen davon.
Wenn ich ein Produkt hätte, dass seriell (und nur so) über die IB diverse Komponenten steuert und überwacht, würde ich das selbe wahrscheinlich auch sagen ;)

Wenn ich allerdings auch noch Hardware verkaufen wollte (wie G+R) und zwar hauptsächlich Hardware, dann würde ich behaupten, die IB mit ihrer seriellen reicht für das aus, was ich mit meiner Hardware nicht kann. Nämlich Züge steuern.
Also protokolltechnisch die Decoder unterschiedlichster Formate ansprechen.

Dann kommen Aussagen zustande wie: die Serielle ist für alle Aufgaben des Automatisierungsbetriebes einer Anlage zu langsam ;)

Es gibt aber bei jedem System Einschränkungen. Die muss es geben, weil jedes System, egal wie geartet, sich weniger über die Menge an Features sondern mehr über die Menge der Einschränkungen definiert. Nur so werden sie nun mal nicht verkauft.
Und o.a. Rechenbeispiel ist eine klare Einschränkung. Natürlich ist das System dann immer noch schneller, als der Mensch mit egal welcher Zentrale jemals sein könnte und schickt die 400 Loks auf die Reise. Aber aus technischer Sicht ist es noch nicht optimal.

Es ist immer auch eine Frage von Motiven, wie so etwas bewertet wird. Besonders dann, wenn die eigene Ernährung davon betroffen ist. Was ich hier versuche ist, die Sache neutraler zu bewerten. Ich möchte den besten Weg finden.
Und das von mehreren Seiten betrachtet:
1. Wie gehts am Besten (Technik)
2. Wie gehts am Günstigsten (Kosten)
3. Welche Kompromisse muss ich dabei akzeptieren
4. Wie Anpassungs- und/oder Erweiterungsfähig wäre die Lösung aus 1.-3.

und last but not least...
5. würde das Ergebnis von anderen Anwendern, ausser mir, auch akzeptiert!
Also wäre die Entwicklung marktfähig.

Zu den Rückmeldungen und somit wieder zur Technik:
Die Rückmeldungen müssen leider zyklisch bei der IB "angefragt" werden. Von selbst kommt sie nicht damit rüber. Das könnte man dann schon als "fast" optimal bezeichnen. Den besten Wert, den ich bislang gelesen habe bietet das Selectrix/Rautenhaus System mit 76,92 ms für alle(!) angeschlossenen Rückmelder. Egal wie viele!!!
Das ist mit der IB über die serialle Schnittstelle nicht zu erreichen. Nie! Auch in zukunft nicht. Das ist eine Einschränkung des Systems ;)
Die Abfrage für ein(!) Rückmeldemodul nimmt ca. 30 bis 50 ms in Anspruch. Gemessen habe ich diese Zeit allerdings nicht sondern berufe mich auf die IB-P50X-Doku.

Bei z.B. 10 Rückmeldern (80 Eingänge = ca. 25 Blockstrecken) kann ich also "nur" alle 300 bis 500 ms (eher 500) über alle Zustände definitiv bescheid wissen. In dieser Zeit sind ununterbrochen Telegramme zur Abfrage der RMs gelaufen. Also nicht ein einziges Telegramm zur Zug oder Weichen-/Signalsteuerung. Das bedeutet, ich kann in den verbleibenden 500 ms noch ca. 10 bis 15 Züge steuern oder Weichen schalten.

Aus diesem Grund gibt es bei der IB ein sogenanntes Eventsystem!
Mann "pollt" nicht wie o. beschrieben über alle Module und fragt die Zustände ab, sondern fragt die IB: Hat sich was verändert, wenn Ja sag mir bitte was.

Dann schickt die IB ein Telegramm zurück mit der Moduladresse und dem Wert aller ihrer Eingänge. Also den Status des gesamten Moduls.

Das macht die Sache schon ein wenig besser. Aber leider funktioniert das nicht so, wie es soll, oder wie ich mir vorstelle wie es laufen sollte. Es kommen viele Informationen zurück, die ich nicht erwarte und die ich mir auch nicht erklären kann. Ich würde sogar behaupten, dass falsche Informationen zurückkommen.
Und genau hier fangen dann die Probleme an. Falsche Informationen schnell geliefert sind schlimmer wie korrekte Informationen, dafür aber langsam ;)

Über die Vor- und Nachteile dieser Vorgehensweise will ich mich jetzt nicht auslassen, sonst kündigt mir der Forumsbetreiber die Freundschaft ;)

Nu setze ich mich wieder an die Anlage und probiere die neuesten Erkenntnisse aus.
Bis Morgen ;)

Grüße Mike

>Das bedeutet, ich kann in den verbleibenden 500 ms noch ca. 10 bis 15 Züge steuern oder Weichen schalten.<

Hast Du da eventuell falsche Zahlen benutzt ? Das hieße nämlich für den Zeitraum für 1 Sekunde NUR 20 bis 30 steuerbare Züge - und für so lahm halte ich die intelligente Kiste auch wiederum nicht.

Mal vom kritischen Sekundentakt für den Datenaustausch abgesehen will ich das nicht so richtig glauben; oder kann ich hier noch was hinzulernen ?

Gruß, AL,-me

Bei geht's zweigeteilt:
Steuern über die serielle Schnittstelle mit 19200 baud zum Lenz-Interface,
Rückmeldung s88-Bus über Druckerport.
Dabei habe ich einen Adapter im Einsatz, der vier Busstränge ermöglicht. Im Moment sind 14 s88-Module eingebaut.
Ich muß sagen, das diese Lösung recht zuverlässig funktioniert.
Da ich noch nicht fertig bin mit bauen, kann ich noch nicht sagen, ob das Ganze noch ausreicht, wenn mal alle Gleise liegen.
Der "Flaschenhals" ist bei mir die Lenz-Zentrale. Falls erforderlich, werde ich sie umgehen.
Die Rückmeldung jedenfalls funktioniert bestens.
Übrigens: der verwendete PC hat sagenhafte 120 MHz!

Jens

Guten morgen allerseits.

Habe gestern mit der Kommunikation weitergemacht und diverse Überraschungen erlebt. Das kläre ich mit U*

Das o. beschriebene ist theoretisch richtig. Laut der Dokumentation von Uhlenbrock (P50X, Link auf der U* Seite) benötigt die IB für die Abarbeitung eines Befehls im Schnitt zwischen 20 und 50 ms.

Somit ergibt sich: 1000 / 20 = 50. Also max. 50 einfache, schnelle Befehle (Weiche ohne Statusabfrage) pro Sekunde oder 1000/50 = 20. Also max. 20 umfangreichere, langsame Befehle (Lok-Steuerung mit 5 Parametern).

Das funzt so aber nur, wenn die IB und der PC in der Kommunikation gut zusammenarbeiten. Gibt es Ungereimtheiten, wie bei mir, dauert es länger und es gehen plötzlich nur noch 2 bis 5 Befehle die Sekunde.

Ich habe z.B. das Verhalten, dass die IB ca. 100 bis 200(!) ms benötigt, bis sie mir eine Antwort auf Befehle schickt. Man kann es aber auch so sagen. Ich benötige 100 bis 200 ms bis ich eine Antwort empfangen kann. Da das in keinem Fall das Regelverhalten sein kann, vermute ich einen Fehler bei mir bzw. der Konfiguration. Die gesendeten Befehle werden auch nicht ausgeführt sondern lediglich mit der richtigen Anzahl an zu erwartenden Bytes mit 0 beantwortet. Irgendein Fehler hat sich bei mir eingeschlichen oder die Doku ist falsch.

Gruß Mike

Moin, geplagter Mike,

aua aua hahh, dann schick dem Meister in dem komischen Forum aber wacker ne passende Antwort auf seine "kein Flaschenhals" Auskunft !

Gruß, AL,-me

obwohl, bei genauer Betrachtung hat er ja Recht, is kein Flaschenhals - eher der Korken

Nicht zu fassen, aber tatsächlich wahr.
Habe ich eine Mail an den Entwickler der IB bei Modeltreno geschickt.
Dauerte keine 20 Minuten, da war die Antwort da.
Wow. Zwar keine Lösung aber er hat sich wenigstens bemüht. Anders U*.
Die haben bislang nicht mal nen Autoresponder verschickt.

@AL
Witzig ist halt. Der eine sagt es gibt keinen Flaschenhals, der andere sagt es gibt einen. Die schamlosen Verkäufer ;)

Gruß
Mike

100 bis 200 ms pro Befehl?  Das kann doch nicht stimmen!

Hast Du uebrigens das SX Protokoll abgeschaltet - nicht das das dann irgendwie noch dazwischen"gefunkt" werden muss.  Ich kenn mich mit der IB nicht aus, aber koennte ja sein, das sie abwechselnd eins, dann das andere Protokoll sendet.  Oder ist das Schalten automatisch nur DCC?

Nur eine Idee....

Hi

Ich habe mal einen Versuch mit dem Selectrix -Interface gestartet.

- per Schleife die Adressen 1 - 100 nacheinander abgefragt (ohne Verzögerung)
- 20 ms gewartet
- per Schleife die Antworten 1-100 eingesammelt

Eine Zeitverzögerung ist nicht erkennbar.

Einziges Problem:
Man bekommt immer "" zurück wenn am Funktonsdecoder lauter Nullen anliegen. Genau das gleiche bekommt man aber auch zurück wenn es den Decoder gar nicht gibt.

Harald

Hab das Problem gefunden!
Es lag natürlich bei mir ;)
Ich habe den Empfang der Daten von Pollen auf ereignisbezogenen
Empfang umgestellt und siehe da...es funzt tadellos.

Gruß Mike

Nachtrag:

An dieser Stelle mal ein DICKES und FETTES Lob an den Entwickler bei Modeltreno. Der Herr Chiti-Batelli (seines Zeichens Hauptentwickler der IB) ist ein unglaublich netter und hilfsbereiter Mensch obwohl man glauben mag, dass gerade so ein Mann richtig beschäftigt ist und keine Zeit für Kundenprobleme hat.

Echt SUPER!!!

Gruß Mike

Zu Anfang mit der IB ALLES zu machen -nämlich fahren und schalten - ist bis zu einer gewissen Anlagengrösse aus Kostengründen (erst mal keine zusatzlichen Ausgaben für RR&Co-Software und Littfinsky-S88-HSI-RM) sinnvoll und möglich.  
Wenn die Anlage aber doch mal so groß wird, das man schon GBS zur Übersicht braucht, sollte man die IB von der Aufgabe des Schaltens befreien - vorausgestzt man ist gewillt eine Modellbahnsoftware wie RR&Co und ein S88-HSI-Rückmeldebaustein von LDT einzusetzen, der über eine eigene serielle SS an einen PC angeschlosssen wird. Alle Rückmeldungen usw. laufen dann nicht mehr über die IB.  

ego