Samengevat: De 'MiNiDiGi' Centrale

[Wim Ros]

Jeroen, volgens mij blijft stroom of massa detectie altijd nodig. Denk aan de wagons/rijtuigen, of wil je die ook van een zender voorzien (kassa).

Vooralsnog zie ik het als een leuk speeltje. Of het echt nuttig is bij computersturing heb er ernstige twijfels bij.

Crash van een PC wanneer komt dat voor? Bovendien onthoud koploper altijd de laatste situatie. Je kunt in de meeste gevallen gewoon weer verder.

Mvg
Wim.

[henk]

Helder stuk Karst. Verder heb ik er wel eens in MiBa over gelezen. Daar proberen ze de lezers er op alle mogelijke manieren van te overtuigen dat het heel nuttig gaat zijn. Maar de praktische voorbeelden die ze dan noemen klinken zo onbenullig, dat ze mij er vooral van overtuigen dat de voordelen zeer beperkt zijn en in geen verhouding tot de (ombouw)kosten staan.

Ik begrijp dat het op een hele grote baan met verschillende besturingsterminals gemakkelijk kan zijn als een loc bij de overgang even vertelt wie hij is. Klinkt logisch, maar dat is een beperkte markt. Daar gaat het commercieel niet op draaien.

En voor de doorsnee zolderpiloot die het leeuwendeel van de markt vertegenwoordigt?

Basale informatie weet de centrale al. Hij heeft namelijk zelf de bijbehorende opdrachten verstrekt. Controleren of die opdrachten wel zijn uitgevoerd, is het paard achter de wagen spannen. De boel moet gewoon werken en in de praktijk blijkt dat ook mogelijk te zijn. De doodenkele keer dat een opdracht niet wordt uitgevoerd levert op de hobbyzolder ook niet gelijk grote rampen op hè.

Daar komt nog bij dat de retourcommunicatie ook kan falen en zelf een bron van storingen kan zijn. Het doet me een beetje denken aan alle electronica die tegenwoordig in auto's zit, waarbij door defecte electronica soms meer problemen worden veroorzaakt dan opgelost. Welke kans is groter: dat een opdracht niet wordt uitgevoerd of dat bijvoorbeeld een verkeerde wisselstand via Railcomm wordt gecommuniceerd?

Toerentallen, temperatuur, ja ja, nee nee, goh.  
Ik zie eigenlijk niet onmiddelijk hoe het terugmelden daarvan mijn modelspoorlol gaat vergroten, maar misschien zie ik grote mogelijkheden over het hoofd.

[Han Zijlstra]

@ henk
T heeft idd veel te maken met de beleving van het modelsporen. In Europa rijden we bv veel liever in de rondte met vastgestelde treinen en trajecten. volg je daarentegen de Amerikaanse markt dan zie je veel point to point banen waarbij tijdens een operating sessie al veel meer het rijgedrag van een lok van invloed is( wordt gemaakt) op de uiteindelijhke doelstelling nl het vervoeren van vracht van a naar b. Denk maar eens aan het Way bill system. Als je dan kunt simuleren dat het toerental, kolenvoorraad en "what ever"snelheid- en reikwijdte bepalende elementen zijn (conform realiteit) dan wordt een systeem als Railcomm echt leuk.

Bovendien: Evolutie hou je niet tegen tenzij je woonplaats urk is ooit begon dcc ook als speeltje ....

[fissy]

Ik ben volledig met Karst en andere eens Railcom heeft geen grote meerwarde voor een normale baan, ook niet voor een grote baan. Een PC met contact naar de centrale kan op elke punt het rem gedrag  berekenen. Informatie uit de slot en van een detector icm de lengte van een sectie...

@han Ja, het Amerikaanse systeem point-to-point is heel leuke, maar heb je dit nu in europe? Veel club-banen zijn niet geschikt voor dit gebruik, heb je een geschikt baan, moeten nu alle clubleden railcom decoders aanschaffen, echt duur...  Grappig is ook dat digitrax niet mee maakt aan Railcom,...

Het enigste voordeel van Railcom is denk ik het transponding van de Adres, de snelheid kan je niet echt uitlezen (heeft iets met de "Reibung, Massenträgheit" te doen) Dit is het zelfde met de terug melding van een wissel, de DS 54 geeft een melding "wissel heeft geschakeld" maar geen idee als de tongen nu in de juiste positie zitten...

Ik denk zo'n Railcom techniek heb je niet echt nodig voor een kleine baan, een voor mij ook niet voor een grote..

Groet

Bernd

[Han Zijlstra]

Eens : nodig is het niet , maar wel leuk als het allemaal kan. Enne ik denk dat fabrikanten( en niet de minste)  niet voor niets Railcom in hun decodertjes stoppen. We zullen zien. 

[Jeroen van Tol]

Ik zit net voor de grap even met een collega te brainstormen over dit verhaal. Deze collega weet niet zo heel veel van modelspoorbanen maar is net als ik wel een automatiseerder...

Vraagt hij op een gegeven moment aan me:
Wat vind je belangrijker? Dat de gewenste kwaliteit en functionaliteit geleverd worden in een technisch perfect maar prijzig pakket of dat precies diezelfde kwaliteit en functionaliteit geleverd worden in een technisch verouderd maar spotgoedkoop pakket?

Ik zeg: Dat laatste natuurlijk! Maar het is in dit geval niet dezelfde functionaliteit...

Hij zegt: Ik kan me niet voorstellen dat er zoveel functionaliteiten zijn die je niet op goedkopere manieren op zou kunnen oplossen.

En daar gingen we... We namen een functie van RailCom en gingen op zoek naar alternatieve oplossingen. En wat bleek? We konden maar 1 belangrijke functie bedenken die we niet zonder RailCom konden reproduceren: Het willekeurig plaatsen van een trein op de baan waarna deze automatisch bij het systeem wordt aangemeld.

Hij zegt: Nou, dat is nog ruim genomen want zolang je een trein niet in een bezet blok zet detecteert de pc al dat er 'iets' is neergezet. Dus je hoeft alleen nog maar te weten of dat 'iets' een trein is die aangemeld moet worden.

Ik zeg: Grappig, dan heb je naast RailCom decoders dus maar 1 Global RailCom detector nodig.

Hij zegt: Is het in de praktijk niet zo dat je altijd op dezelfde plek een trein op de baan zet? Bij een rangeerterrein of zo... Want dan hoef je alleen op dat stukje met de decoder te praten.

Ik zeg: Dan heb je helemaal geen RailCom meer nodig, maar alleen een stukje 'programmeerspoor' van waaruit je de baan op rijdt.

Ik ben geloof ik van mijn geloof gevallen...  :-| :-| :-|


Groet,
Jeroen.

[Remco.]

Maar met een dergelijk 'programeer' spoor doe je dan hetzelfde als het plaatsen van je locomotieven op de sporen in Koploper met het voordeel dat het bij Koploper overal kan.

Gr. Remco.

[henk]

Jawel Remco, maar dan moet je wel een keer met je muis klikken om Koploper te vertellen om welke loc het gaat. Dat valt niet mee. 

Nou ja, als je een loc de allereerste keer op de rails zet is het aardig als die loc gelijk allerlei basale informatie doorgeeft. Hoef je dat niet in te voeren. Precies de basale variant van MFX.

[fissy]

Ja, dit is een oplossing, maar noem je dit fail-safe? Als ik slechts dit spoor gebruiken kan is het dan nog een flexibel systeem noemen?

Ik denk er zitten wat meer problemen in als een bezet melding volgen met enkele data in een buffer van een programma. Bijvoorbeeld een problem: Als je een trippel tractie koploper met drie adressen in een spoor aan de perron hebt, dan enkele stel vertrekt naar een andere richting, war is nu welke nummer? en ben je zeker?

Ik denk zo'n systeem hoeft aan enkele punten melders (Railcom, Transponding, RFID en zo...) nodig.

Groet

Bernd

[Jeroen van Tol]

@Remco
Ik bedoelde eigenlijk dat je op zo'n 'programmeerspoor' een trein volledig automatisch kunt aanmelden. De software detecteert daar een bezetmelding en gebruikt de 'speciale' programmeer-aansluiting van de centrale om de decoder uit te lezen. Met de gevonden gegevens wordt de loc vervolgens aangemeld en kun je rijden.
Handig of niet, ook dat is een beetje overkill (zoals Henk ook aangeeft)...

@Bernd
Nee, dat is niet heel erg flexibel, maar wel erg goedkoop!
Kijk, ik zou ook nog eerder voor 1 Global RailCom detector kiezen zodat je meteen kunt 'genieten' van de exotischere functies van RailCom.
Het lijkt me namelijk wel weer mooi als een decoder kan aangeven dat er iets mis is voordat hij door brandt...
Maar mijn eerste idee, om bij elke sectie ook een local RailCom detector (of soortgelijke functie) te plaatsen blijkt totaal overbodig.

Ook het voorbeeld van de triple-tractie trein met drie decoders is zonder RailCom op te lossen. Op voorwaarde dat de software bij het samenstellen van de drie treinen heeft onthouden wie waar zit (voor - midden - achter).

Ik moet overigens wel zeggen dat sommige oplossingen die we bedachten het gebruik van extra blokken noodzakelijk maakte. Maar aangezien die niet zo duur zijn weegt dat al snel op tegen het veel duurdere RailCom.

Groet,
Jeroen.

[Patrick Smout]

Ik bedoelde eigenlijk dat je op zo'n 'programmeerspoor' een trein volledig automatisch kunt aanmelden. De software detecteert daar een bezetmelding en gebruikt de 'speciale' programmeer-aansluiting van de centrale om de decoder uit te lezen. Met de gevonden gegevens wordt de loc vervolgens aangemeld en kun je rijden.
Handig of niet, ook dat is een beetje overkill (zoals Henk ook aangeeft)...

Het gebruik van een doodlopend *invoeg* spoor dat maar in één richting bereden wordt pas ik toe in mijn besturingssoftware om op een veilige manier automatisch een nieuwe trein op mijn baan te introduceren zonder dat je het risico loopt dat de nieuw geïntroduceerde trein een deadlock situatie veroorzaakt met 1 of meerdere treinen die reeds aanwezig zijn in de baan. De railcom detectie zou hier mooi in passen. Overigens heb ik voor het tegenovergestelde doel ook een uitrijspoor.

mvg,

Patrick Smout

[Wim Ros]

Leuk hoor al die theorie, maar de praktijk is dat het besturingsprogramma de lok al kent als het gaat om het uitrijden naar een rangeerterrein. Hij gaat dan gewoon uit het automatische bedrijf en verder onder handbediening.
Wil je hem weer opnemen dan zet je hem van handbediening weer op automaat en sleep je hem naar het volgende blok in koploper. Koploper bepaald dan wanneer hij vertrekt.
Heb je voor dit spel (speel) element dan railcom nodig?

Railcom verteld iets aan de centrale, maar verteld nog steeds niets aan het besturingsprogramma zelf. Doe dat gewoon zelf zou ik zeggen en denken.

Iedere nieuwe lok zo uit de winkel staat op adres 3, dus die moet je toch via een programmeerrails een ander adres geven, en dan kun je die gelijk bij het besturingsprogramma invoeren, met naam soort trein enz. enz.

Mvg
Wim.

[Patrick Smout]

Leuk hoor al die theorie, maar de praktijk is dat het besturingsprogramma de lok al kent ... koploper. Koploper bepaald dan wanneer hij vertrekt.

Heb je hier railcom voor nodig? Nee dus, maar het kan wel in deze toepassing als was het maar om te voorkomen dat je bvb een loc met een dubbel adres de baan op zou sturen. Kan dit met Koploper - geen flauw idee? Is het zinvol? Voor een thuisbaan waarschijnlijk niet maar misschien wel voor een grote clubbaan waar leden diverse locs van thuis meebrengen.

mvg,

Patrick Smout

[Wim Ros]

Patrick,

Ik zie niet hoe Railcom kan voorkomen dat een lok met een al bestaand adres kan worden tegen gehouden. Lijkt mij eerder dat het sneller wel kan gebeuren, dan dat de treindienstleider van een grote clubbaan bepaald of een lok kan en mag meedoen.
Als je het aan het automatische melden overlaat ben je de controle over dubbele adressen denk ik kwijt. Een lok kan en mag zich namelijk op twee plaatsen tegelijk bevinden. Denk aan overgangen van Railcom detectie secties, die aan elkaar grenzen.

Mvg
Wim.

[Patrick Smout]

Patrick,

Ik zie niet hoe Railcom kan voorkomen dat een lok met een al bestaand adres kan worden tegen gehouden. ... Een lok kan en mag zich namelijk op twee plaatsen tegelijk bevinden. Denk aan overgangen van Railcom detectie secties, die aan elkaar grenzen.

Wim,

mijn uitgangspunt was 1 enkele railcomdetector op het invoegspoor, voortbordurend op de vorige mail(s).
Zoals jij het brengt kan het idd. niet.

grtz,

Patrick