Itrain en decoder. Trein vertrek, sein te laat op groen.

[banne]

Op het iTrain forum dezelfde vraag gesteld maar wil hem hier ook even kwijt, misschien dat ook hier iemand een zinnige suggestie heeft.

Op mijn baan staan inmiddels een stuk of 60 seinen. Deze seinen staan niet alleen op het schakelbord in iTrain maar ook in het "echt" en hebben allemaal een eigen DR4018 DCC seindecoder. Tot zover geen problemen. Echter toen ik vandeweek aan het rijden was met iets van 14 treinen tegelijk (in auto modus) viel mij op dat vrijwel alle treinen al vertrekken terwijl de seinen nog op rood stonden! Eerst dacht ik dat de decoders te traag waren maar al snel viel op dat zelfs de virtuele seinen op het schakelbord op rood stonden toen de treinen al wegreden. Ze veranderden een seconde of 5-8 daarna wel van kleur op zowel het schakelbord als op de baan (om pas ook weer heel erg laat op rood te gaan)

Dit draait op een Macbook Pro mid 2008 (16GB RAM, SSD, 2.5 ghz Dual Core) met OSx El Capitan, ook na even opnieuw opstarten geen verschil. Hoe is dit mogelijk? De CPU belasting was op dat moment geen 100% (75-80%). Wel best een tegenvaller trouwens, 60 seinen neerzetten en programmeren en dan tot de conclusie moeten komen dat ze bij een beetje belasting gewoon niet of slecht bediend worden. Als het probleem in de CPU belasting zou zitten, wat kan ik doen om deze te verlagen in het huidige baanplan? Zit er een max aan het aantal treinen wat iTrain kan aansturen icm veel wissels en seinen? Of zit er een max aan de DCC? Had ik beter de seindecoders kunnen programmeren als Motorola?

Wat wel raar is, is dat de S88 detectie en nahandelingen wel gewoon vrijwel realtime gedaan werden. Treinen stopten gewoon netjes op de juiste plek. Het waren echt enkel de seinen die vertraging hadden.

[santerdam]

Bart,

Je hebt nu een testresultaat met 14 treinen. Kun je ook eens testen met 4 treinen en kijken hoe dan het gedrag is ? En vervolgens lijken hoe het systeem zich gedraagt met 6-8-10-12 treinen.

Mij lijkt een CPU belasting van 75-80% best pittig - in het algemeen geldt dat 80% CPU wel het maximum is. Je kunt echt niet tot 100% gaan.

Sander

[Wim Ros]

Lijkt mij iets te maken te hebben met de schakeltijden per wissel/sein. Er kan er altijd maar eentje tegelijk schakelen.  Zou eens kijken wat de tijden zijn, voor seinen, kan dit heel erg kort zijn, voor wissels een tijd van 100..200ms aanhouden.


Tel die schakeltijden maar eens bij elkaar op en zie hoe zich dat verhoud tot de vertraging. In koploper kun je een vertrek vertraging opgeven na het zetten van de seinen en wissels, of dat ook in iTrain kan weet ik even niet.

Mvg
Wim.

[banne]

Op welke schakeltijd adviseer je de seinen te zetten? Als ik het verhaal van Bert dan goed begrepen heb ben ik wel het "tussengeel" kwijt als ik onder de 250ms ga.

[Bert_Apd]

Hallo Bart,

Ik neem aan dat je in iTrain de optie "Zet magneetartikelen altijd" heb aangevinkt:

     

Zet deze optie eens even uit en kijk of de seinen nu met minder vertraging geschakeld worden met 14 treinen...

Let wel: de P-seinen tonen met de uitstaande optie geen "tussengeel" meer.

Groeten,
Bert

[banne]

Grappig dat je dat zegt Bert, deze optie heb ik inderdaad recent ingeschakeld na advies van jou dus mogelijk dat dit de oorzaak is. Wat is nu de exacte functie van deze optie? Geldt dit continue of is dit alleen bij verbinding maken om alles in beginstand te krijgen?

[banne]

Let wel: de P-seinen tonen met de uitstaande optie geen "tussengeel" meer.

Dit kan ik toch ontkrachten, deze optie heb ik namelijk nooit aangehad totdat jij het erover had en tóch had ik al een tijdje tussengeel na groen-knipper

[Bert_Apd]

Hallo Banne,

Ik ging ervan uit dat jij inmiddels de door mij voorgestelde P-sein definities had gebruikt voor jouw seinen, maar uit je opmerking dat je ongeacht de uitstaande optie altijd al tussengeel had na groen knipper begrijp ik dat je nog steeds deze definitie hanteert:

Het tonen van het tussengeel na groen-knipper vindt in jouw geval zijn oorzaak in de door jou opgegeven schakelvolgordes, blijkbaar ongeacht het aan of uit staan van de optie "zet magneetartikelen altijd".

Volgens de handleiding van iTrain zou de optie de volgende werking moeten hebben:

Opties

Hier kunnen twee algemene opties worden opgegeven:

• Zet magneetartikelen altijd - een magneetartikel wordt normaal gesproken niet
geschakeld als iTrain denkt dat dit al in de goede stand staat. Als er ook handmatig
geschakeld wordt dan kan deze optie gebruikt worden om te garanderen dat het
magneetartikel altijd geactiveerd wordt, zodat de stand op de baan altijd hetzelfde is als
in het programma.

Ik heb zelf ook nog even getest met deze optie en ben tot de ontdekking gekomen dat iTrain ook bij de uitgezette optie toch altijd (ongeacht de stand van het adres) alle drie adressen schakelt, dit in tegenstelling tot Koploper, die alleen die adressen schakelt die niet in de juiste stand staan. Bij iTrain wordt blijkbaar niet gekeken naar de stand van de te schakelen adressen maar naar de stand van het sein...

Blijkbaar hoeft bij iTrain voor de juiste werking van de P-seinen met de definities zoals ik die heb opgegeven de optie dus niet aan te staan.

Dit zou dan ook moeten inhouden dat het aanzetten van deze optie niet leidt tot extra overhead bij het schakelen, zodat dit niet de oorzaak kan zijn van "overbelasting" van iTrain en/of cpu gebruik...

Als jij trouwens je schakeltijd van 250 msec terugbrengt naar een lagere waarde zul je zien dat ook de tijd van het "tussengeel" na groen-knipper korter wordt. Let er wel op dat de totale omschakeltijd van het sein drie keer de opgegeven schakeltijd is: bij 250 msec dus totaal 750 msec per sein...

Groeten,
Bert

[banne]

Op welke schakeltijd adviseer jij de seinen te zetten? 0,75 seconde per sein is idd wel erg veel op een grote baan. Even los van het feit dat er dan geen tussengeel meer is. Wat is de minimale benodigde schakeltijd?

[Bert_Apd]

Ik houd zelf voor de "normale" seinen een schakeltijd van 50 msec aan, dat is voor de DR4018 naar mijn idee voldoende om te schakelen. Zoals Wim al eerder meldde kan de schakeltijd voor seinen "heel erg kort zijn"...

Bij uitgangen in "pulsmode" (dus o.a. preset 0) voor het schakelen van (wissel)spoelen voegt de DR4018 daar zelf nog een extra schakeltijd aan toe afhankelijk van de waarde in CV 238 - 253: de defaultwaarde 128 levert een aanvullende schakeltijd van ca. 0,8 seconde... Deze aanvullende schakeltijd gaat buiten de treinbesturingssoftware om en belast dus niet de aansturende pc.

Let er overigens op dat de schakeltijd van bijv. 50 msec door de centrale ook weer vergroot kan worden afhankelijk van de opties binnen de centrale zelf: veel centrales (zo ook de DR5000) hebben de mogelijkheid een "minimale schakeltijd" in te stellen. De uiteindelijke effectieve schakeltijd is dus afhankelijk van meerdere factoren.

Heb je nog iets gedaan met de suggestie van Sander om een test te doen met een oplopend aantal rijdende treinen?

Gelet op jouw seindefinities is het misschien zinvol om nogmaals de door mij al eerder voorgestelde seindefinities te citeren:

Binnen iTrain zijn voor het correct schakelen van de seinen de navolgende Seineigenschappen van toepassing.

De daarin getoonde Schakeltijd en Toestandstoewijzing (en schakelvolgordes) dienen ongewijzigd te worden overgenomen om een correcte schakeling mogelijk te maken. Een afwijkende schakelvolgorde kan leiden tot ongewenste en onlogische "tussenbeelden". Ook de schakeltijd dient zo kort mogelijk te worden gehouden: 50 ms is voldoende.
Uiteraard zullen bij de eigen implementatie de juiste wisseladressen moeten worden ingevuld.

1. Seineigenschappen NS Hoofdsein (bediend):

     

Dit type sein staat normaal op "rood" en toont vanuit "rood" direct de ingestelde seinstand om vervolgens weer direct naar "rood" terug te vallen. Zonodig kan dit sein ook als bloksein worden gebruikt, echter tijdens het schakelen van "groen" naar "rood" zal geen "tussengeel" worden getoond.

Bovenstaande seindefinities leveren in ieder geval geen ongewenste tussenbeelden op, dus ook geen "tussengeel" na groen-knipper... 

Groeten,
Bert

[banne]

Let er overigens op dat de schakeltijd van bijv. 50 msec door de centrale ook weer vergroot kan worden afhankelijk van de opties binnen de centrale zelf: veel centrales (zo ook de DR5000) hebben de mogelijkheid een "minimale schakeltijd" in te stellen. De uiteindelijke effectieve schakeltijd is dus afhankelijk van meerdere factoren.

Heb je nog iets gedaan met de suggestie van Sander om een test te doen met een oplopend aantal rijdende treinen?

Ik heb een CS3+, moet ik daar nog iets in aanpassen zover jij weet mbt de schakeltijd?

De test van Sander wil ik zeker nog gaan uitvoeren maar nog geen tijd voor gehad. Ik wil het wel andersom doen, ik begin met 14 treinen en schakel ze 1-voor-1 uit om te kijken vanaf welk aantal de seinen "normaal" reageren.

[Bert_Apd]

Ik heb een CS3+, moet ik daar nog iets in aanpassen zover jij weet mbt de schakeltijd?

Ik heb geen ervaring met de CS3+, dus moet ik daarvoor zelf ook in de gebruikershandleiding daarvan duiken, en die heb ik dus niet... 

Als ik tijd heb zal ik eens op internet gaan zoeken.

De test van Sander wil ik zeker nog gaan uitvoeren maar nog geen tijd voor gehad. Ik wil het wel andersom doen, ik begin met 14 treinen en schakel ze 1-voor-1 uit om te kijken vanaf welk aantal de seinen "normaal" reageren.

Ik zou het net andersom doen, beginnen met 1 trein en dan opvoeren om te zien of het slechter wordt...
Als het met één trein al niet werkt weet je dat dan meteen...

Groeten,
Bert

[banne]

Dat weet ik al, normaal rijden er 5-7 treinen en daar waren geen onvolkomenheden zichtbaar

[Martin Hornis]

... ik begin met 14 treinen en schakel ze 1-voor-1 uit om te kijken vanaf welk aantal de seinen "normaal" reageren.

Dat weet ik al, normaal rijden er 5-7 treinen en daar waren geen onvolkomenheden zichtbaar

De snelste methode is steeds op de helft van het verschil te gaan zitten. Dus begin bij ca. 10. Als dat goed gaat, dan verder bij 12. Als het niet goed gaat, dan verder bij 8.