BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: Jeroen van Tol op 06 December 2009, 23:43:25
-
Hallo allemaal,
Ik zit al een tijdje te piekeren over RailCom. Hoewel niet iedereen het eens is over het nut er van en ze bij de NMRA ook al jaren proberen te verzinnen hoe RailCom nou precies zou moeten werken is het voor mij toch een onderwerp wat me blijft interesseren.
Mijn voornaamste doel met RailCom was om te kunnen zien waar een trein daadwerkelijk is (bezetmelding met daarbij door welke trein), in tegenstelling tot waar een trein zou moeten zijn (bezetmelding in cominatie met treinbesturingssoftware). Inmiddels kun je wel een RailCom detector kopen/bouwen die dat kan, maar alle bezetmelders vervangen door RailCom detectoren is nogal een kostenpost. (Bezetmelding op basis van stroomdetectie kost een paar euro per sectie, een RailCom detector een paar tientjes!)
Na wat piekeren zit ik nu aan de volgende oplossing te denken. Ik heb begrepen dat wanneer je een opdracht stuurt naar een RailCom decoder, dat deze (en alleen deze) antwoord geeft in de cutout periode direct na de opdracht.
Tijdens de cutout periode staat er heel even geen spanning op de baan dus de bezetmelders op basis van stroomdetectie meten op dat moment geen van allen stroom. Behalve dan (volgens mij) die ene sectie waar een RailCom decoder antwoord aan het geven is.
Stel nu dat je voor de logica 'achter' de stroomdetectie (normaal gesproken shiftregisters volgens de s88 norm) gebruik maakt van een microcontroller (dergelijke oplossingen zijn er al). Dat is iets duurder dan normaal maar op 16 secties scheelt het niet heel veel. Je bent dan in staat om het DCC signaal te monitoren en steeds te bewaren aan welk decoderadres de laatste opdracht werd verstuurd. Tevens ben je dan in staat om de cutout periode te 'zien'. Wanneer je vervolgens tijdens de cutout periode een bezetmelding krijgt weet je dat het laatst bewaarde adres in de betreffende sectie zit. Kortom, je hebt dan 1 RailCom detector nodig per 16 stroomdetectie secties. En dan vallen de kosten wel mee.
Er is weliswaar (nog?) geen software die iets met deze informatie doet maar aangezien ik zelf software aan het bouwen ben wil ik wel eens weten of deze theorie haalbaar is. Mijn vraag is dan ook: Wat denken de goeroes op het gebied van bezetmelding en microcontrollers hier van? Kan het wat ik wil of zie ik zaken over het hoofd?
Alvast bedankt voor het meedenken!
Groet,
Jeroen.
-
Hoi Jeroen,
Best wel een haalbaar idee ;)
Zeker als je de railcomdetector ook b.v. de s88 bus laat scannen...
Dus zoiets als een s88LocoNet adapter, die ook RailCom detecteerd en beide messages ( bezetmelding en lokadres per bezetmelding ) op de bus zet.
Er zullen overigens nog wel wat haakjes en oogjes aanzitten, omdat de cut-out maar enkele microseconden groot is. Je zult dus het wegvallen van de bezetmelding moeten detecteren, vervolgens RailCom moeten detecteren en die twee gegevens aan elkaar koppelen. Maar.... de meeste, huidige, RailCom geenabelde decoders zenden 'unsollicited' hun adres al, waardoor er dus al een speciale RailCom message aan te pas moet komen om e.e.a. uit elkaar te kunnen houden....
Denk ze lekker verder, ik hou het in de gaten ;)
Grtzz,
Karst
-
Jeroen,
Volgens mij is deze discussie al eens eerder gevoerd. Ik zie het nut niet van te weten waar een lok is en in welke sectie op grond van RailCom.
Er is maar een plaats waar het enig nut heeft, en dat is aan het eind of het begin van een rangeerterrein wat buiten om de computer handmatig wordt aangestuurd.
Wat je vervolgens denk ik over het hoofd ziet is hoe krijg je de Railcom informatie vanaf zeg het S88 schuifregister in de seriele poort van de computer.
Alle besturings programma's weten perfect waar een lok is en kunnen die ook perfect volgen.
Mvg
Wim.
-
Ik zie het nut niet van te weten waar een lok is en in welke sectie op grond van RailCom.
Dan zet binnen welk huidig systeem maar eens een lok of meerdere op de baan. Of haal er een of meer van de baan af.
Dan weet je meteen waarom Railcom zoveel handiger is, want de lok meldt zichzelf aan (of af door niet meer te melden). Die hoef je dus niet meer in te geven via je computerprogramma, samen met de positie waar die neergezet is. Of je hoeft hem niet meer te verwijderen uit je systeem.
Kortom: uitermate handig en in dit tijdperk van automatisering een zeer bruikbare logische stap vooruit. Met de tijd meegaan dus, over een paar jaar bestaat er niks anders meer en zijn alle huidige programma's verouderd.
Maarten
-
Dan lees je dus niet wat ik al in mijn vorige bericht geschreven heb.
Wim.
-
over een paar jaar bestaat er niks anders meer en zijn alle huidige programma's verouderd
Zoiets heb ik 20 jaar geleden, of nog langer, ook wel eens gehoord, nog niet over railcom, maar over andere programma's. Dat heet marketing, laat die jongens ook een droom hebben.
-
Hi,
En er is een nog veel groter probleem, je hebt decoders nodig die de RailCom informatie kunnen uitzenden. Dat is misschien een leuke optie als je nieuw begint met de hobby, maar niet als je daar al een tijdje mee bezig bent en een niet nader te noemen aantal decoders in bedrijf hebt. Of je moet een apart zendertje monteren.
Maar goed, bij het aanmelden op de baan daar kan ik me nog wel iets bij voorstellen dat kan automatisch. Maar automatisch afmelden bij het systeem of bij de software daar kan ik nog niets mee.
Ik wil best mee met de tijd, alleen moet het wel zoden aan de dijk zetten en goedkoper zijn dan het systeem wat er nu gebruikt wordt.
Zolang de aanbieders er zelf nog niet uit zijn, zal ik er geen geld aan uitgeven.
Marklin heeft MFX
Fleischmann/Uhlenbrock hebben Traincontroller/Lissy
Digitrax heeft Transponders
En nu Lenz met RailCom.
En allemaal niet compatibel met elkaar. ;)
Maar goed laat Jeroen maar een systeem bedenken dat aan de eisen van het Railcom systeem voldoet, dus geen standalone oplossing is, en waar men dus iets aan heeft, bij alle RailCom systemen.
Mvg
Wim.
-
Ik denk eigenlijk dat Jeroen niet zit te wachten op de volgende discussie over nut en onnut van RailCom. Ik denk ook niet dat dat nieuwe argumenten gaat opleveren. ;D
-
Dan lees je dus niet wat ik al in mijn vorige bericht geschreven heb.
Dat geloof je toch zelf niet. Ik lees in ieder geval iets wat niet juist of niet volledig is, zoals:
"Alle besturings programma's weten perfect waar een lok is en kunnen die ook perfect volgen."
Dat klopt grotendeels, maar dan vergeet je er wel bij te zeggen, dat dat pas gebeurt nadat je de lok en de plaats waar die staat eerst hebt moeten ingeven in je systeem. En dat hoeft bij Railcom dus niet. En een huidig besturingsprogramma weet al helemaal geen raad met "verdwenen" lok's.
Dat je verder het nut ergens niet van ziet lees ik ook en dat nut zie ik dus wel.
Dan een inhoudelijker reactie van jou waar ik wel wat mee kan.
"Maar automatisch afmelden bij het systeem of bij de software daar kan ik nog niets mee."
Heel simpel. Wanneer een lok van de baan genomen wordt, komt er geen Railcom-signaal meer op dat baanvak en ziet het (toekomstige) programma dat er geen lok meer aanwezig is. Dit staat los van eventuele bezetmelding (bijv. door wagons).
"Zolang de aanbieders er zelf nog niet uit zijn, zal ik er geen geld aan uitgeven."
Marklin heeft MFX, klopt, maar dat is geen DCC. Overigens wel ongeveer dezelfde werking als Railcom
Fleischmann/Uhlenbrock hebben Traincontroller/Lissy met hetzelfde probleem. Er wordt pas iets gedetecteerd als op een bepaalde plaats iets gebeurt (een trein passeert een detector)
Digitrax heeft Transponders idem als hierboven, maar met een ander systeem
"En nu Lenz met RailCom."toch al een hele tijd hoor
"En allemaal niet compatibel met elkaar."
en dat is inderdaad een heel cruciaal punt, waardoor het nog niet goed van de grond komt. De modeltreinindustrie werkt nog steeds meer naast/tegen elkaar dan met elkaar. Over enige tijd zijn alle Europese DCC-producenten bij elkaar (misschien al geweest) om Railcom beter vast te leggen dan wat met DCC gebeurd is. Dan zal er dus een soort Railcom-standaard ontstaan, waaraan iedere fabrikant zich dient te houden die Railcom als mogelijkheid in zijn systeem en decoders wil hebben. Aangezien Lenz het ontwikkeld heeft zal die wel de houder van de naam blijven, maar het vrijgeven voor algemeen gebruik, zoals nu ook al een aantal merken Railcom hebben. Dan kunnen ook de diverse merken programma's aangepast worden op de werking met Railcom
Maarten
-
Ik denk eigenlijk dat Jeroen niet zit te wachten op de volgende discussie over nut en onnut van RailCom. Ik denk ook niet dat dat nieuwe argumenten gaat opleveren. ;D
Jeroen vraagt zelf om mee te denken. Daar komt een reactie op, waarin getwijfeld wordt aan het nut. Juist dat nut benadruk ik, temeer daar Jeroen blijkbaar voorop wil lopen door zelf te programmeren. Dan moet je wel het in mijn ogen grootste nut duidelijk hebben. De keuze of hij dat wil gebruiken en hoe is aan hem.
Maarten.
-
Jeroen heeft een innovatieve gedachte aangaande RailCom en stelt daarover een technische vraag. Tot nu toe is Karst de enige die op zijn vraag ingaat.
Over nut en noodzaak heeft Jeroen vast wel nagedacht. Al was het alleen maar omdat alle vragen die hij tot nu toe op het forum over Railcom heeft gesteld onmiddelijk tot dezelfde discussie tussen dezelfde personen (ik ook, waar blijft Han) met precies dezelfde argumenten hebben geleid.
-
De discussie over het al dan niet zinvol zijn is inderdaad al gevoerd en probeer ik hier ook te vermijden. Met een beetje zoeken staan alle voors en tegens al ergens besproken. Liever niet in dit draadje dus. (y) (Niet omdat ik er niet blij ben met alle mogelijke informatie maar meer omdat het in andere topics thuis hoort en we er daar naar hartelust over kunnen praten)
@Karst
Het probleem van 'unsollicited' adresmeldingen hangt als het goed is af van hoe je de decoder programmeert. Je kunt dat volgens mij uitzetten door een juiste CV programmering. (Mits de 'onofficiele standaarden' door decoderfabrikaten aangehouden worden ;))
@Wim
Ik ben van plan om vanaf de detectieprint meteen naar LocoNet te communiceren en de hele s88 achterwege te laten. Zeg maar zoiets als jullie S88LN op elke detectieprint in plaats van de schuifregisters. Ik heb immers al een microcontroller nodig om RailCom uit te lezen dus kan die ook meteen de LocoNet communicatie voor zijn rekening nemen.
Ik denk alleen dat er (nog?) geen LocoNet bericht is gedefinieerd waarin ik deze info kwijt kan, wat zoveel betekent dat ik daar zelf een bericht voor zou moeten verzinnen. Qua compatibiliteit misschien niet zo mooi maar ik begeef me toch al op een vlak waar nog nauwelijks iets voor te krijgen is dus kan dat er ook wel bij. ;D (En het is eventueel nog aan te passen mocht zo'n bericht er ooit wel komen of stiekum toch al bestaan :P) Op de PC aangekomen (Middels de door jouw geleverde LocoNet->(RS232)PC interface) kan mijn treinbesturingssoftware het bericht eenvoudig oppakken.
Het doel is om tegen vergelijkbare kosten als de huidige bezetmelding (en daarmee hebben Karst en Wim de lat behoorlijk hoog gelegd met hun scherp geprijsde artikelen :-\) een RailCom detector er 'gratis' bij te krijgen. Dat zal niet helemaal lukken maar ik wil het verschil zo klein mogelijk proberen te houden. En ja, het zal inderdaad voor toekomstige starters pas interessant worden want vervangen is duur en er is ook nog geen software die de info op pakt. (Mijn software is waarschijnlijk pas leuk voor de eerstvolgende generatie want heel ver ben ik nog niet :-[)
-
Jeroen,
Als je het via loconet laat verlopen, dan is het geen RailCom meer, maar is het Lissy/Com of Transponder/Com. En die zijn wel gedefineerd in het LocoNet-Protocol. Daar hoef je zelf geen wiel voor uit te vinden.
Je hebt dan alleen een vertaalslag nodig van RailCom naar LocoNet. En heb je dus in feite een nieuw systeem, wat nergens meer mee compatibel is. Als dat is wat je wil prima.
Mvg
Wim.
-
@Wim
Daar heb je een verdraaid goed punt waar ik totaal niet over nagedacht had!
Wel een leuk dilemma. De techniek van Transponding vind ik persoonlijk niet zo mooi vanwege o.a. die lompe magneet. Vandaar mijn keuze voor de RailCom techniek. Voor het mooie zou het dan een XpressNet oplossing moeten worden. Maar qua 'bus' vind ik de werking van LocoNet dan weer mooier dan die van XpressNet...
Voor mij persoonlijk speelt het probleem inderdaad niet omdat de 'logica' van mijn centrale in de PC zit en de centrale(hardware) en boosters fysiek gescheiden zijn van de rest. Ik kan zelfs (in theorie) alle mogelijke bussoorten tegelijk met de PC verbinden en het met elkaar laten werken.
Voor anderen zouden er dus eigenlijk twee varianten moeten komen, waarbij je natuurlijk wel altijd gebonden bent aan de voorwaarden voor RailCom (cutout, decoders, enz.):
Eén 'standaard variant' voor XpressNet, waarbij RailCom gewoon als RailCom wordt gecommuniceerd.
En een tweede variant waarbij RailCom berichten 'vertaald' worden naar vergelijkbare Transponder of Lissy berichten (indien mogelijk, anders kan het alleen met 'passende' zelfbouw centrales) en deze over LocoNet communiceert.
De tweede is wat ik eigenlijk aan het doen was maar Wim heeft een terecht punt. Ik ga eens uitzoeken of je eenvoudig RailCom kunt vertalen naar Transponder of Lissy berichten (oftewel, komt de functionaliteit enigszins overeen?). Kan dat niet dan heeft de tweede variant voor weinig mensen nut en ga ik met de eerste verder. Anders hou ik me bij de tweede (en kan wellicht iemand anders het nabouwen voor XpressNet).
*** edit
Wel een vreemd idee eigenlijk: Mijn centrale geeft dan RailCom opdrachten aan decoders, vervolgens ontvangt de treinbesturingssoftware Transponder/Lissy antwoorden, en tot slot geeft deze Transponder opdrachten welke door de centrale weer vertaald moeten worden naar RailCom opdrachten voor op de baan.
Ik verzin weer wat ;D ;D ;D
***
*** edit2
En door deze eerste edit wordt me ineens duidelijk dat de tweede variant niet eens gaat werken zonder een centrale die daar mee om kan gaan.
Ik ga dus verder met variant 1. Bedankt voor de oplettendheid Wim!
***
-
Ik loop meteen tegen het eerste probleem aan: Geen documentatie te vinden over RailCom berichtspecificaties, waarschijnlijk omdat het nog niet 'uitgekristalliseerd' is. Berichtspecificaties over Transponding zijn er als het goed is wel maar ik kan ze niet vinden... Zo wordt het erg lastig om iets te maken wat ergens compatible mee is. >:(
Een variant voor XpressNet maken kan op dit moment alleen door zelf verzonnen berichten te gebruiken (binnen de al wel gereserveerde range, zoals OpenDCC ook doet) en ze dan 'ooit' om te zetten naar officiele berichten.
Voor mijn eigen baan kies ik dan toch liever voor LocoNet. Een XpressNet variant bekijk ik nog wel eens op het moment dat de berichten wel bekend zijn.
Wanneer iemand overigens uitgebreide specs heeft over LocoNet (dus meer dan het 'personal edition' verhaal van Lenz) dan hou ik me aanbevolen!
-
"Railcom" in de search op de NMRA pages geven een goed beeld van de "progressie" van Railcom.
Afgezien van nut en noodzaak ligt er een groot deel van het probleem bij de fabrikanten op hun bordje. Er bestaat zelfs een aparte werkgroep van fabrikanten die overeenstemming zou moeten bereiken over de soorten terugkoppeling tbv Railcom. (en ja dan gooit die crisis ook nog es roet in het eten.
Met een beetje goed zoeken vindt je ook de namen van de kontaktpersonen bij die fabrikanten die zich met Railcom bezig houden.
Lenz, Esu, Kuhn, Tams , Zimo zijn er allemaal mee bezig.
Bij Zzimo kun je denk Peter Ziegler wel even vragen wat de status is.
grtz
-
Future toepassing van RailCom ....
voorzie ergens op de tandwiel overbrenging tussen motor en aandrijfwielen een impulsgever (zogenaamde incremental rotary encoder)
Deze sturen een teller aan die op/neer telt afhankelijk van de verplaatsing van de Loc.
Verstuur de waarde van de teller periodiek via railcom naar het commandstation
Command station weet hierdoor de relatieve positie (verplaatsing) van de loc tot op 0,1 mm (shoot ... ;)).
Memoriseer deze waarde voor een blok/sectie op het ogenblik dat je een bezetmelding ontvangt voor het blok/sectie.
PC software kan hieruit de absolute positie berekenen van de loc binnen een blok (als de lengte van blokken exact opgemeten zijn).
Automatisch rangeren is hierdoor weer een stapje dichterbij ...
grtz,
Patrick
(voor de patent hunters - jammer, maar kan niet meer ingediend worden na deze publieke openbaring )
-
Command station weet hierdoor de relatieve positie (verplaatsing) van de loc tot op 0,1 mm (shoot ... ;)).
Afgezien van de wielslip dan. ;)
-
Afgezien van de wielslip dan. ;)
Door preventief onderhoud in de herst is mijn NMBS baan vrij van vallende bladeren.
Ijsvorming voorkom ik door het raam gesloten te houden.
;D
-
Ook bij goed onderhouden sporen heb je altijd een (onvoorspelbare) wielslip. Dus een positiebepaling op de millimeter is een utopie.
Maar goed, ik zal me er verder niet inhoudelijk mee bemoeien, aangezien het hele Railcomverhaal voor mij een ver-van-mijn-bed-show is.
-
Future toepassing van RailCom ....
Command station weet hierdoor de relatieve positie (verplaatsing) van de loc tot op 0,1 mm (shoot ... ;)).
PC software kan hieruit de absolute positie berekenen van de loc binnen een blok (als de lengte van blokken exact opgemeten zijn).
(voor de patent hunters - jammer, maar kan niet meer ingediend worden na deze publieke openbaring )
Leuke opmerking, heb ik vroeger ook al eens gezegd over toekomstige motoren.
De toekomstige modeltreinmotor wordt iets als een piezo-stappenmotor, waardoor jouw voorstel nu al tot het verleden behoort (maar de industrie zal deze stap heus niet overslaan, denk ik. De treintjeswereld is nogal behoudend). De nauwkeurigheid wordt dan eerder 0,01 mm., maar de relatief slechte rijeigenschappen van modeltreinen zullen dat volledig tenietdoen (slip, scherpe bochten etc.)
Op de tweede plaats kan er geen patent ingediend worden omdat het al toegepast wordt, zie de T4T decoders. Uitlezing door Railcom en verder gebruik is een logische stap maar niets nieuws, dus niet patentwaardig.
Toch leuk om het weer eens te lezen.
Maarten.
-
Leuke opmerking, heb ik vroeger ook al eens gezegd over toekomstige motoren.
De toekomstige modeltreinmotor wordt iets als een piezo-stappenmotor, waardoor jouw voorstel nu al tot het verleden behoort (maar de industrie zal deze stap heus niet overslaan, denk ik. De treintjeswereld is nogal behoudend). De nauwkeurigheid wordt dan eerder 0,01 mm.
Het probleem met de huidige decoders voor nauwkeurige positiebepaling is dat zij snelheid regelen.
Nu wordt via een grote omweg geprobeerd een positieregeling te bereiken door een ijking te doen van de snelheid.
Zouden zij een positie regelen dan was (onafgezien van de slip waar je blijkbaar beducht voor moet zijn) het heel wat eenvoudiger om het beoogde doel te bereiken. Snelheid is dan niets anders meer als positieverandering (=verplaatsing) per tijdseenheid, positie blijft altijd gekend. Omgekeerd (zoals nu) gaat ook maar resultaat is matig (naar positie toch)
Stappenmotor kan ook maar vereist andere motoren, deze oplossing enkel andere software in de decoder (blijft een leuke vervangingsmarkt).
mvg,
Patrick Smout
-
Stappenmotor kan ook maar vereist andere motoren, deze oplossing enkel andere software in de decoder (blijft een leuke vervangingsmarkt).
Eigenlijk is de huidige stand van zaken zeer ouderwets: we gaan een perfect digitaal stuursignaal omzetten in een twijfelachtig analoog signaal, dat we doorgeven aan een willekeur van meestal bijzonder slechte recht-toe-recht-aan elektromotoren.
Juist digitaal leent zich ervoor een variabele frequentie (lees hier: hoeveelheid pulsen per tijdseenheid, lees snelheid) gedurende een bepaalde tijdsduur door te geven. Vermenigvuldiging geeft dan een totaal aantal pulsen, dus het totaal aantal omwentelingen van een (stappen)motor, dus de totaal afgelegde afstand.
Niks geen meten (achteraf), gewoon weten (input).
Die andere motoren bestaan al lang, decoders hebben geen vermogensuitgang meer nodig, software is een fluitje van een cent (veel eenvoudiger), dus waar wachten we nog op ??? ???
De firma M* heeft jaren (geschat: 4 a 5 jaar) geleden al een keer een plaatje laten zien, waarover ik in de voorganger van Beneluxspoor al bericht heb.
Maarten
-
Maarten,
De sinus motor van M* doet toch wat jij beschrijft?
-
De sinus motor van M* doet toch wat jij beschrijft?
Geen notie van, maar voordat we dit draadje gaan vervuilen, kun je daar een nieuw draadje over opstarten of mij een prive bericht sturen hierover (of waar ik de technische informatie hierover kan vinden)?
Maarten.
-
Allemaal heel leuk discussiemateriaal!
Toch vind ik het voorlopig even voldoende om alleen bezetmelding te combineren met een RailCom detector, zodat je a: altijd met zekerheid weet dat de treinen daar zijn waar je denkt dat ze zijn (in plaats van het 'bijna zeker' te weten door softwarematig te 'voorspellen' waar ze zouden moeten zijn, wat bv. fout gaat wanneer een wissel om wat voor reden dan ook niet omging) en b: Alle overige (al dan niet zinnige) RailCom informatie uit een decoder kunt opvragen zonder dat je dat al te veel extra kost ten opzichte van de standaard bezetmelding.
En omdat ik dan toch een nieuwe "bezetmelder-detectorcombi" zit te verzinnen kan ik meteen weer wat leuke, handige, (on)zinnige features aan het geheel toevoegen. (Alleen jammer dat alleen mijn eigen centrale daar dan iets mee kan/gaat doen)
Zoals bijvoorbeeld het LocoNet 'probleem' ondervangen dat je de beginstand van bezetmelders pas doorkrijgt nadat er een wijziging optreedt.
En patenten? Die interesseren me niet. Als iemand al rechten zou hebben op mijn ideeën dan zijn Karst en Wim dat want van hen heb ik zo'n beetje alles geleerd. Oftewel, wanneer mijn ideeën ooit in een stadium komen anderen het ook graag willen hebben dan zijn zij de eerste waar ik mee ga praten. Hun 'vrijwilligers-achtige' aanpak om de modeltreingemeenschap te voorzien van betaalbare oplossingen spreekt me namelijk wel aan.