Stroomdetectie gecombineerd met RailCom detector?

[Han Zijlstra]

"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

[Patrick Smout]

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 )

[Klaas Zondervan]

Command station weet hierdoor de relatieve positie (verplaatsing) van de loc tot op 0,1 mm (shoot ... ).

Afgezien van de wielslip dan.

[Patrick Smout]

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.

 

[Klaas Zondervan]

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.

[maartenvanderburgt]

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.

[Patrick Smout]

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

[maartenvanderburgt]

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

[Klaas Zondervan]

Maarten,

De sinus motor van M* doet toch wat jij beschrijft?

[maartenvanderburgt]

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.

[Jeroen van Tol]

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.