Welk Digitaal Systeem?

[SpoorFun]

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.

[Sander]

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

[Wim Ros]

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.

[SpoorFun]

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.

[santerdam]

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

[Wim Ros]

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.

[SpoorFun]

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.

[santerdam]

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

[SpoorFun]

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.

[Sander]

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

[santerdam]

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

[Wim Ros]

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.

[henk]

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.

[Klaas Zondervan]

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.

[Albert.H0]

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.