BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: SpoorFun op 04 October 2008, 11:47:37
-
Hallo,
Ik ben van plan een spoorbaan te bouwen, die compleet digitaal is en adhv een computer programma bestuurd zal worden.
Mijn vraag is welk digitaal systeem het beste past bij de volgende eisen:
requirements:
- Elke decoder moet uniek zijn (i.e. trein, wissel, etc. decoder)
- Op de baan zullen meerdere "herkennings melders" komen die bv de passerende locomotief met de unieke decoder herkennen, en deze "trigger" terugkoppeld aan de computer/software .
- De computer/software is adhv het ingeladen baantrace, de plaats van de "herkenningsmelders", de ontvangen "trigger" (i.e. decoder_id & herkenningsmelder) in staat de unieke locomotief op de baan te besturen.
- De computer/software moet ook zelf triggers genereren ( bv sein op groen, rood, etc.)
- de software moet zo zijn dat gemakkelijk de besturingslogica (I.e. afstemming tussen baantrace, "herkenningsmelders", "triggers") te programeren is.
-
Kwa systeem?
In elk geval 1 die op je pc is aan te sluiten, en dat zijn er inmiddels genoeg.
Ligt er ook een beetje aan of je al materieel/rails en dergelijke in huis hebt.
Iets meer info is dan wel van belang.
Elke decoder is sowieso al uniek dus dat is geen probleem.
Herkenningsmelders zijn beter bekend als bezetmelders ism terugmelders.
Of beide op 1 print samengevoegd.
Kwa software komt in elk geval Koploper in aanmerking even als RailRoad & Co.
Met behulp van decoders kan bovenstaande software de seinen natuurgetrouw aansturen.
Kwa gemakkelijkheid ligt dit deels aan je eigen kunde. Wat de een moeilijk vindt vindt de ander makkelijk, alles is door stap-voor-stap te doen uiteindelijk te leren en daarna ook makkelijk.
mvg,
Sander
-
Ik denk dat als ik je eisen pakket lees, er niet zoveel systemen aan je voorwaarden voldoen.
Ook aangaande je software eisen, heb je denk ik hetzelfde probleem.
Je moet de dingen ook gescheiden houden, aan de ene kant heb je een digital systeem en aan de andere kant heb je een software pakket.
Mvg
Wim.
-
Dank voor de antwoorden.
Tav "Bezettmelders icm terugmelders":
Welke zijn dit (/ welke merken leveren dit?) & welke communicatie protocollen ondersteuen deze?
Is er ook een "adapter", die de communicatie van/naar de baan direct interfaced met een PC, zonder dat deze "adapter" ook besturingslogica heeft? (Voor meer uitleg/begrip zie "architectuur" beneden)
Weet iemand fora(/een forum) waar meer de de digitale architectuur van modelbanen besproken word?
T.a.v. "architectuur" zijn er imho verschillende lagen:
-a. de fysieke rail infrastructuur laag (i.e. rails, locs, seinen)
-b. de fysieke signaleringslaag (i.e. triggers/melders & wissel/trein/sein decoders)
-c. de communicatie laag (i.e. het bus/protocol/etc.)
-d. de integratie/logica laag (i.e. Het besturingssysteem van de baan)
-e. de presentatie laag. (i.e. waar ik als gebruiker mijn opdrachten ingeef)
Ik zoek oplossingen voor elke laag vanaf laag b t/m d.
Mijn indruk is dat de heren fabrikanten deze scheidingen erg ondoorzichtig maken.
Ad a.
2-rail gelijkstroom, mogelijk wisselstroom voor wisselaansturing/seinen.
Ad b.
Ik zoek trigger/melders die uniek een loc(/stroomgebruiker) identificeren adhv zijn decoder.
De decoder wordt vervolgens benaderd om een opdracht uit te voeren (bv snelheid verandering, wissel/sein omzetting, etc.)
(PS. deze opdracht is geinitieerd door de integratei/logica laag)
Ad c.
Moet aansluiten bij signaleringslaag/integartielaag & liefst een open standaard zijn.
Geen idee wat in de modelterinwereld gebruikelijk is; Ik zie MM & DCC, maar dit zijn imho geen communicatie standarden, maar systemen.
Ad d.
Ik zie de PC/software als invulling voor de integratie/logica laag en zoek daar een s/w programma bij.
Deze s/w zet de inputs van de gebruikerslaag & triggers van de baan om in -veschillende- doel aansturingen (bv wissels(straten), locs, seinen), rapporteerd de huidige status aan de gebruikerslaag.
De s/w moet makkelijk te progarmeren zijn ( bv koploper/ georienteered WinDigital PAPS)
Geprefereerd is dus ook een "adapter" tussen de communicatie/laag & integratielaag die GEEN integratie(/besturingslogica) heeft.
(Als ik de huidige systemen zie, dan wordt dit juist samengenomen; I.e. bv. IB doet beide & heeft een "ook nog een uitgang voor de PC"....)
Ad e.
Moet de (baan/loc/sein)status kunnen presenteren & gebruikers opdrachten kunnen verwerken. PC-scherm/toetsenboord is voorlopig genoeg; Nice to have dedicated mobiel device.
-
Spoorfun, heb je je al eens verdiept in bestaande oplossingen? Het is schitterend om zelf allerlei zaken te bedenken en te defineren. Maar je bent een beetje een al langer bestaand karrewiel opnieuw aan het uitvinden. En op sommige punten wijkt je wat af, waardoor uiteindelijk geen enkele bestaande oplossing voldoet aan jouw voorwaarden.
Sander
-
Suc6 bij je zoektocht, maar wat jij wil, tenminste wat ik denk te begrijpen uit je opsommingen, zul je het zelfs moeten ontwikkelen. Wat een systeem kan, lees je in de specificaties daarvan.
Verder staat het mij erg tegen om tegen een volkomen anoniem persoon zulke uitgebreide en technische vragen te moeten behandelen.
Je profiel is leeg en Spoorfun is ook nietszeggend.
Mvg
Wim.
-
Hoi Sander & Wim,
Dank voor jullie antwoorden;
Natuurlijk kan ik naar de winkel gaan en een IB, Ecos, Zimo, Digitrax, of etc. te kopen envervolgens me te gaan afvragen hoe ik e.e.a. kan realiseren. Daarbij zal ik tegen allerlei beperkingen aan te lopen, omdat al deze fabrikanten een geintegreerd systeem aanbieden. KASSA voor de heren fabrikanten.
Dat probeer ik om te draaien, en dus in eerste instantie systeem onafhankelijk de "eisen" te specificeren;
Vervolgens hoop ik door gebruik te maken van de bij de forumleden aanwezige kennis, de beste componenten daarbij te zoeken. ( waarbij ik mijzelf ook verdiep in wat de heren fabrikanten opleveren)
Nadruk ligt voor mij op de "bezet/terugmelders"; Dit is blijkbaar een ondergeschoven kindje.
Helaas gebruiken de meeste systemen "een status memory" van waaruit de lokatie van de loc afgeleid is adhv een begin situatie. (maar NIET de werkelijke situatie).
Ik lees ontwikkelingen van Lenz/Kuhn/Tams & Zimo tav RailCom, maar implementaties daarvan zie ik nog niet;
Dus ik ben inderdaad zoekende, hoop op forum kennis, maar misschien op het verkeerde forum.
Laten dat laatste aub toch niet de waarheid worden.
-
Natuurlijk kun je de bestaande melders als ondergeschoven kindjes beschouwen. Technisch gezien is het echt wel te doen om die dingen een heel stuk duurder te maken en dan kunnen ze meer informatie (treinidentificatie) genereren.
Bestaande oplossingen (bijvoorbeeld Koploper) blijken die extra informatie niet nodig te hebben. Door slim om te gaan met beschikbare informatie kunnen die oplossingen op een hele goedkope manier de situatie weer te geven.
Over het algemeen kun je beter wat investeren in 1 enkel centraal deel dan 100+ peperdure melders te gaan bedenken. Daarmee maak je het immers onbetaalbaar duur.
Wellicht schuilt daarin de filosofie van de door de meesten gekozen route.
Als je overigens zo graag in een aantal lagen software wilt ontwikkellen, begrijp ik niet goed dat je uberhaupt over een IB of een ECoS praat. Dan geef je immers geld uit aan een geintegreerd apparaat dat veel overlap heeft met wat je zelf wilt gaan maken.
Sander
-
Hoi Sander,
Dit is opbouwend, daar heb ik wat aan.
Die overlap zie ik ook; Vandaar ook mijn oorspronkelijk vraag, waarbij ik probeer te achterhalen of er nog iets anders bestaat.
Tegen de bezetmelders zit ik er idd alleen logisch tegen aan te kijken;
I.e. de locdecoder heeft alle CV waarden die uitgelezen/veranderd kunnen worden (het beroemde "programmer rails"). Kortom dit moet(/kan) bij elke melder ook.
Kosten heb ik nog niet naar gekeken, eerst probeer ik de alternatieve oplossingen te vinden.
Thnx,
Marcel.
-
Marcel,
Kortom dit moet(/kan) bij elke melder ook
Waarom zou dat bij jou bij leke melder moeten/kunnen?
Welk voordeel denk je hier mee te kunnen halen?
mvg,
Sander
-
Marcel, het klopt dat een decoder volledig uitgelezen kan worden. Daar heeft de decoder ook alle tijd voor als de loc stilstaat. En als jij bij iedere melder effe wilt blijven stilstaan, zou de decoder het kunnen doen.
Neem maar aan, dat als de loc op snelheid aan het rijden is, de datastroom veel te groot is om het op tijd aan de melder te vertellen. Los van het feit dat de decoder het al druk genoeg heeft om z'n eigen werk te doen.
Mag ik je heel voorzichtig de hint geven dat je een beetje te ver van de werkelijk aan het bedenken bent ..... Leuke bezigheid voor een zondagmiddag, maar verwacht er niet te veel van.
Sander
-
Wat moet er dan bij elke melder ook kunnen? Zo te lezen, zit jij van achter je tekentafel allerlei zaken te bedenken, die absoluut onnodig zijn.
Verder merk ik dat je niet weet wat er te koop is en hoe bepaalde systemen werken.
Zo maak ik op dat je nog nooit gelezen hebt over POM. Lissy, Trainnavigator, Tags en MFX.
De meeste zijn niet doorontwikkeld net zoals RailCom dat nog steeds niet is. Het grootste probleem met indentificatie systemen is het is niet universeel en algemeen toepasbaar, terwijl een simpele bezet/terugmelder op basis van aan/uit dat wel is.
En om een antwoord te geven op je vraag, 'Welk digital Systeem' dan is mijn antwoord daarop een systeem met een LOCONET aansluiting.
Mvg
Wim.
-
Marcel, het klopt dat een decoder volledig uitgelezen kan worden. Daar heeft de decoder ook alle tijd voor als de loc stilstaat. En als jij bij iedere melder effe wilt blijven stilstaan, zou de decoder het kunnen doen.
Neem maar aan, dat als de loc op snelheid aan het rijden is, de datastroom veel te groot is om het op tijd aan de melder te vertellen. Los van het feit dat de decoder het al druk genoeg heeft om z'n eigen werk te doen.
Nee, het bestaat wel, zoals Wim al aangaf.
1. Infraroodzendertje in de loc en ontvangers tussen de rails. In het zelfbouwsysteem EditsPro was dat al geïmplementeerd en commercieel is het verkrijgbaar bij Uhlenbrock (Lissy) en Fleischmann (Trainnavigator = identiek aan Lissy).
2. Via de rails in de pauzes tussen de digitale signalen van de centrale. Zimo had dat al, MFX kan dat en voor DCC is al een tijdje Railcomm in ontwikkeling. Zimo is de enige die alle mogelijkheden wilde benutten. Märklin/MFX gebruikt to nu toe alleen de mogelijkheid dat een loc zich na plaatsing op de rails automatisch aanmeldt. Van Railcomm bestaan nog nauwelijks praktische toepassingen.
3. Systemen met tags. Ken ik alleen van zelfbouwprojecten.
Als je het per se wil, dan zou ik me eens in Railcomm verdiepen en dan wachten op de eerste centrale die daar wat mee doet.
Maar het is dus niet voor niets dat er weinig mee wordt gedaan. De fabrikanten vragen zich in gerede af wie er op zit te wachten. Voor computergestuurd rijden is het overbodig. Het is niet voor niets dat Lissy/Trainnavigator juist zijn bedoeld om zonder computer te kunnen automatiseren.
-
Märklin/MFX gebruikt to nu toe alleen de mogelijkheid dat een loc zich na plaatsing op de rails automatisch aanmeldt.
Maar wel met de beperking dat je dan nog niks weet over de plaats waar de loc staat. De centrale weet alleen dat hij "ergens" op de baan staat.
-
Ik heb het idee dat Marcel dit per blok wil, dus dat de decoder zich bij elk blok aanmeld (en hoe doe je dat dan met afmelden?-gewoon even een praktisch iets). Volgens mij de enige mogelijkheid op dit moment is zelf ontwikkelen vanuit RailCom.
-
Maar wel met de beperking dat je dan nog niks weet over de plaats waar de loc staat. De centrale weet alleen dat hij "ergens" op de baan staat.
Dat is toch precies wat ik zeg Klaas. :P
Voor nadere plaatsbepaling is koppeling van de informatie aan bezetmeldpunten nodig. Zimo heeft dat voor zijn eigen systeem. Sommige fabrikanten beweren dat ze met Railcom bezig zijn, Tams bijvoorbeeld. Maar voor wie zelf kan ontwikkelen is Railcom een goed startpunt.
Blijft het feit dat het voor computerbesturing niet echt nodig is en dat geen 'ingebakken' systeem zich tot nu toe kan meten met de mogelijkheden en flexibiliteit van computerbesturing.
-
Henk, ik maakte die opmerking omdat je mfx in één zin noemde met Railcom. En Railcom geeft voor zover ik weet wel een plaatsbepaling. Mocht ik dat mis hebben, dan volgt er vanzelf weer een correctie. ;)
-
Voor wat betreft plaatsbepaling ? Ik heb net de Faq gelezen van Railcom bij Lenz maar daar staat alleen in dat het kan meer niet. Ik neem aan dat plaatsbepaling beperkt is tot een sectie ?
Gr. Remco
-
Henk, ik maakte die opmerking omdat je mfx in één zin noemde met Railcom. En Railcom geeft voor zover ik weet wel een plaatsbepaling. Mocht ik dat mis hebben, dan volgt er vanzelf weer een correctie. ;)
Railcom en MFX bevatten beide een protocol voor bidirectionele communicatie, zeg maar de taal die een decoder moet kletsen om te worden begrepen. Daar hoort randapparatuur bij die er iets mee kan, bijvoorbeeld een bezetmelder die ook de informatie van de langsrijdende loc doorgeeft. Dergelijke bezetmelders zijn voor Railcom of MFX nog niet in de handel. Ik heb Tams wel eens een soort prototype zien demonstreren. Dat wil zeggen, er was een kastje op een geïsoleerd stuk rail aangesloten. Kwam er een trein langs dan toonde een display op het kastje het juiste locadres. Wauw. ;D
Voorlopig zijn er ook nog geen centrales die er wat mee zouden willen doen. Een MFX-centrale hoort graag van een MFX decoder wie hij is, maar interesseert het geen bal waar de decoder op de baan staat. Een Railcom decoder kan voorlopig kleppen wat hij wil, niemand luistert, hoewel fabrikanten als Tams en Lenz al tijden van alles en nogwat beloven. Maar het kan zijn dat ik een recent product heb gemist.
Alleen Zimo heeft/had een compleet en poepduur systeem met alles erop en eraan. Maarten heeft daar op het vorige forum wel eens een draadje over gehad en vond de mogelijkheden uiteindelijk tegenvallen.
-
Dit is wat jij gezien hebt of iets wat er op lijkt.
(https://images.beneluxspoor.net/bnls/railcom.jpg) (https://images.beneluxspoor.net/bnls/railcom.jpg)
Dit heeft dus geen verdere verbinding naar de centrale of naar de computer, dus je kunt er verder niets mee.
Mvg
Wim.
-
Voor de link: http://www.tinet.org/~fmco/home_en.htm (http://www.tinet.org/~fmco/home_en.htm)
Zie ook de TAMS site voor RailCom:
http://www.tams-online.de/htmls/produkte/RCD-1/produkte_RCD-1.html (http://www.tams-online.de/htmls/produkte/RCD-1/produkte_RCD-1.html)
Je hebt blijkbaar ook een aangepast centrale of booster nodig, met een "RailCom-Cutout". We moeten het denk ik wel hebben van dit soort particuliere ontwikkelingen, bij de grote fabrikanten lijkt erg weinig te gebeuren.
-
Klopt zonder een speciale centrale lukt het niet, dus met een lenz digital plus systeem onder versie 3.0 lukt het niet.
Mvg
Wim.
-
Maar technisch gezien is het toch niet zo heel lastig te realiseren om in een blok een feedback te krijgen van een loc ?
Ik denk even hardop:
Je scheid je blokken over beide railassen. Een BM krijgt wat extra know how. Noem het een RequestID functie. De bezetmelder detecteerd een BM.
Gelijk doet hij een RequestID en krijgt antwoord. Daarop volgt de bezetmelding naar de centrale met ID en klaar, iedereen gelukkig ;D
Het enige wat ik mijzelf afvraag is, gaat dit werken met maar 1 draadje aan de BM en de andere op een ringleiding ? Misschien moet je in dit geval dan wel beide draadjes op een BM aansluiten? Dat werkt sowieso.
Ik weet niet hoe complex S88 is maar een combinatie zou toch te maken moeten zijn ?
Je moet dan wel alle baanvakken detecteren om het echt functioneel te laten zijn.
Alleen ik denk dat het vooralsnog alleen een gadget is, ik kan me zo snel geen relevant voordeel bedenken wat de investering rendabel zou maken.
Schiet er vooral op het is maar hardop denken ;D
Gr. Remco.
-
Remco, helaas maar zo simpel is het niet. Daarbij komt het wordt onbetaalbaar. Ieder meldpunt op je baan moet dan deze voorziening hebben. En wat win je er mee, helemaal niets.
Mvg
Wim.
-
Dat je er niets mee wint dat gaf ik zag ik zelf ook al.
Maar ik werd net via via er op gewezen dat S88 request driven is en dat vind ik wel vreemd. Waarom moet een centrale de status van een BM opvragen ?
Efficienter zou zijn: Start de baan, vraag de status 1 keer compleet op en laat als er iets wijzigt, de bezetmelder zelf melden dat er iets is gewijzigd. Dat kan veel verkeer schelen denk ik.
Nou ja het maakt niet uit, ik denk dat we het er voorlopig wel over eens zijn dat je er niets mee wint. Het blijft alleen wel leuk om er over te discusieren :)
Gr. Remco.
-
Remco, Lissy/TrainController is een systeem wat via de feedback uit een lokdecoder of Lissy zender via infrarot een ontvanger verteld welke lok hij is hoe snel hij gaat en welke richting. En waarschijnlijk nog meer onzin.
Alleen die lissy ontvanger staan wel in directe verbinding met de centrale en die lissy ontvanger kun je programmeren zodat er een bepaalde actie wordt ondernomen als een bepaalde lok passeert. Dat gebeurd allemaal via het LocoNet.
Peperduur en ongelooflijk moeilijk in te regelen. En absoluut niet flexibel, in vergelijking met een PC en een besturingsprogramma.
Maar is dus ook weer niet universeel toepasbaar.
En datzelfde probleem is er dus ook met RailCom, is ook niet universeel toepasbaar.
Mvg
Wim.
-
Dat je er niets mee wint dat gaf ik zag ik zelf ook al.
Maar ik werd net via via er op gewezen dat S88 request driven is en dat vind ik wel vreemd. Waarom moet een centrale de status van een BM opvragen ?
Efficienter zou zijn: Start de baan, vraag de status 1 keer compleet op en laat als er iets wijzigt, de bezetmelder zelf melden dat er iets is gewijzigd. Dat kan veel verkeer schelen denk ik.
Gr. Remco.
Remco,
Jouw S88 systeem werkt ook zo, niet verder vertellen hoor.
Zo werkt de intellibox, die geeft alleen maar een verandering door.
Mvg
Wim.
-
Remco,
Jouw S88 systeem werkt ook zo, niet verder vertellen hoor.
Mvg
Wim.
:-X
Remco, Lissy/TrainController is een systeem wat via de feedback uit een lokdecoder of Lissy zender via infrarot een ontvanger verteld welke lok hij is hoe snel hij gaat en welke richting. En waarschijnlijk nog meer onzin.
Alleen die lissy ontvanger staan wel in directe verbinding met de centrale en die lissy ontvanger kun je programmeren zodat er een bepaalde actie wordt ondernomen als een bepaalde lok passeert. Dat gebeurd allemaal via het LocoNet.
Peperduur en ongelooflijk moeilijk in te regelen. En absoluut niet flexibel, in vergelijking met een PC en een besturingsprogramma.
Maar is dus ook weer niet universeel toepasbaar.
En datzelfde probleem is er dus ook met RailCom, is ook niet universeel toepasbaar.
Mvg
Wim.
Ok die namen zie ik wel eens vaker voorbij schieten ja, maar ja ir ? wie wil er nu via ir communiceren ? Dat is inderdaad totaal niet flexibel. Als je dan niet via de railstaven wilt communiceren gebruik dan bijv. bluetooth. Draadloos en uitstekend standaard te koppelen aan PC's met hele kleine printjes, maximaal decoder formaat.
Dan zou je een sectie wederom volledig moeten isoleren en de BM moet broadcasten welke aansluiting hij is. Dan kan je via Bluetooth aan de centrale melden, ik ben die en die loc en sta in die en die sectie.
Sterker dan hoef je geen 'normale' BM te doen. Je bezetmelders worden dan geen BM's maar locatiemelders.
Zou dat wat zijn ?
Ik raak nu op dreef met het verzinnen van oplossingen hoor ;D
Gr. Remco.
-
Wim, je bedoeld waarschijnlijk dat het S88...LI systeem zo werkt. En dat die werking meer aan de LI-kant zit dan aan de S88-kant.
Sander
-
Dat bluetooth idee spreekt me wel aan. Lekker op een beurs rondlopen en inbreken op de diverse banen ..... Ooit wordt hacken nog leuk, dan kun je Goude naspelen op de baan van iemand anders ;D
-
De rubriek is weer geschoond, en ook deze bijdrage, want hier stond wat anders.....
Allemachtig heren. ::)
Wat is er nou in hemelsnaam zo moeilijk om gewoon antwoord te geven op bepaalde vragen, of als je het verder niet meer interesseert, of je hebt geen opties meer te geven, je verder te onthouden van welk dom commentaar ook.
Wil je elkaar dan toch nog virtueel het bloed onder de nagels vandaan halen, gebruik dan de mail.
NIET de PM.
-
Dat bluetooth idee spreekt me wel aan. Lekker op een beurs rondlopen en inbreken op de diverse banen ..... Ooit wordt hacken nog leuk, dan kun je Goude naspelen op de baan van iemand anders ;D
Haha ja maar op zich lijkt het me wel wat. Het zou ideaal zijn.
Gewoon je locatiemelders programeren en daar plaatsen waar je ze nodig hebt en dan de loc draadloos laten melden op welke locatiemelder hij rijdt :) incl. alle andere gegevens die je wilt weten.
Als ze voor de melder an sich en de poort een 8 bits getal sturen heb je dus per melder al 256 aansluitingen mogelijk en nog eens 256 melders :) nou wat wil je nog meer 65000 melders totaal ;D Ik weet niet hoeveel Railz precies heeft maar ik denk dat 65.000 wel voldoende moet zijn :)
Gr. Remco.
-
Ah, Tams heeft toch wel wat op de markt gebracht.
Binnenkort verschijnt weer de digitaal special van MiBa. Daarin lezen we de stand van zaken wel. Vorig jaar werd aangekondigd dat Railcom nu toch echt op doorbreken stond. ;D