Autor Thema: Wielslip voorkomen  (Gelesen 4695 mal)

Offline Rupert van Swol

  • Senior-Mitglied
  • Beiträge: 329
  • Ort: Enkhuizen Ort bei GoogleMaps suchen nl
  • Model trains? it's a life time journey
Re: Wielslip voorkomen
« Antwort #15 am: 05. Januar 2020, 19:40:25 »
Hoi Bas even een toelichting van mij,

Ik ben niet zo bekend met WDP maar heb in het verre verleden voor een andere NL  trein pakket een paar dingen ontwikkeld. Let op DOS tijdperk
Met name voor het stoppen met 1 melder in een blok heb ik onder ander de dynamische remweg ontwikkeld.
Het principe is vrij eenvoudig,  je weet de lengte van een bezetmelder en vervolgens komt er een locomotief en meet je het tijdverschil tussen dat de melder aangaat en weer uitgaat. De locomotief moet 30 km/u rijden dus dan is op voorhand uit te rekenen hoe lang de bezetmelder op aan moet staan, Is hij korter aan dan verwacht dan rijd de trein/lok te snel en bij langer aan dan verwacht dan rijdt de lok te langzaam. het verschil tussen verwacht en gemeten noem ik even de drift van de motor. De drift is niet iets wat een vaste waarde bevat, temperatuur, slijtage alles wat de motor hindert, vieze rails , pluisjes in tandwielen  beïnvloed de drift.
Als ik deze drift wegschrijft in een bestandje welke bezetmelder en locomotief  gebonden is,  beter is gezegd Decoder gebonden is , dan kan je de slechtslopende lok prima laten stoppen, aangezien de rijsnelheid na aanpassing altijd overeenkomt met de gevraagde rijsnelheid. Dan is de remweg tot het stoppunt ook zeer goed te berekenen.
In WDP heb je de mogelijkheid om bij elke terug melder een lengte in te voeren dit  tot op 1 tiende van cm.
WDP kan alleen correct stoppen als de snelheid voor dat het remmen begint constant is. Maar m.i is dit niet een gemeten snelheid vanuit de vorige bezetmelder. het is dus niet gecorrigeerd. Dus regelmatig ijken is een noodzaak in WDP.

Wel de volgende stap is veiligheid
Nu heb je een route die uit meerdere rijwegen bestaan en die rijwegen hebben allemaal een lengte lees een bestandje van de laatst gemeten tijd die de lok nodig had om de bezetmelder af te rijden , dan is het heel eenvoudig een veiligheidscontrole te bouwen  , tel alle gemeten tijden bij elkaar op en dat deel je door de som van de tijden.  dan heb je al de verwachtte reistijd voor dat traject bij de Start . Dat is allemaal op basis van de klok snelheid van de Interne databus.
Wat als de trein te laat aan komt in het doel contact of zelfs helemaal niet , dan is er iets duidelijk fout.
Oorzaak 1 wissel fout ,
oorzaak twee lok zit vast.
Oorzaak 1 lok is de verkeerde richting gaan rijden na een foutje in een ontkoppeling profiel , dus kuiltje graven in de rails, Mijn schade aan de VT98
Bij een wisselfout kunnen twee treinen betrokken raken die eigenlijk moeten stoppen.
Bij de lok die het verkeerde spoor ingaat krijgt een directe stop op basis van een tijdsoverschrijding van de vervolgmelders in de rijweg die hadden al op bezet moet komen maar blijven op uit. kan ook een bezetmelder van de wissel zijn. ( niet handig ) als er parallel een andere trein rijdt die over de wissel gaat. 
De andere trein die een spooktrein krijgt die willen we ook laten stoppen.( is een optie )
Immers de bezetmelders zijn bekend van de rijweg;
de verwachte aankomst tijd is bekend.
Als opeens een bezetmelder op actief  komt die in de rijweg is opgenomen, kan de trein m.i gewoon doorrijden tot het bezette blok.

Mijn fout is,  ik had het veiligheidssysteem in WDP systeem instelling wel actief gezet, vanuit gaande dat er een soort van interne bewaking zou zijn.

Nee dus,  ik had 460 blz door moeten lezen in de Nederlands handleiding die door de importeur verstrekt zou worden.

Blijkt achteraf dat vervolgens per rijweg een z.g.n. veiligheids- contacten moeten worden toegewezen met daarbij ook een tijdsduur. dat zijn er best veel geworden.

Dit is echt een gemiste kans in WDP , immers alle ingevoerde data door de gebruiker is aanwezig , tijdmetingen kunnen automatisch worden gedaan om een automatisch beveiliging systeem in te bouwen.

Ik snap ook waarom het niet gedaan is , maar dat is weer een ander verhaal.

met vriendelijke groet,
Rupert van Swol

PS
voor de oude garde toen we nog donker haar of blond waren,  de oude code uit 1998 erbij gehaald,



Implementation

Here is the code that computes if we need to brake.

float Driver::getBrake(tCarElt* car)
{
    tTrackSeg *segptr = car->_trkPos.seg;
    float currentspeedsqr = car->_speed_x*car->_speed_x;
    float mu = segptr->surface->kFriction;
    float maxlookaheaddist = currentspeedsqr/(2.0*mu*G);

maxlookaheddist is the distance we have to check (formula with special case v2 = 0).

    float lookaheaddist = getDistToSegEnd(car);

lookaheaddist holds the distance we have already checked. First we check if we need to brake for a speed limit on the end of the current segment.

    float allowedspeed = getAllowedSpeed(segptr);
    if (allowedspeed < car->_speed_x) return 1.0;

Compute the allowed speed on the current segment. We check our speed, and if we are too fast we brake, else we continue with the algorithm. Here you can improve the return value, it's a bit tough to brake full (e. g. make it dependent on the speed difference).

    segptr = segptr->next;
    while (lookaheaddist < maxlookaheaddist) {

The first line moves segptr to the next segment. The guard of the loop checks if we have already checked far enough.

        allowedspeed = getAllowedSpeed(segptr);
        if (allowedspeed < car->_speed_x) {

Compute the allowed speed on the *segptr segment. If the allowed speed is smaller than the current speed, we need to investigate further.

            float allowedspeedsqr = allowedspeed*allowedspeed;
            float brakedist = (currentspeedsqr - allowedspeedsqr) / (2.0*mu*G);

Here we compute the braking distance according to the formula above.

            if (brakedist > lookaheaddist) {

Here the magic check is done. If the required distance to brake is greater than the current distance we need to brake. This works because the simulation timestep is small, so we fail the point in the worst case with ~2.0 meters. So to fix that you can add always 2 meters to the brakedist, or better a speed dependent value.

                return 1.0;
            }
        }
        lookaheaddist += segptr->length;
        segptr = segptr->next;
    }
    return 0.0;
}

The remaining code is straightforward. If we decided to brake we return 1. If we loop further we update the lookaheaddist and switch to the next segment. A comment to the return value: 1 means apply full brakes, so we have later to adjust the time

        car->ctrl.gear = 4;
        car->ctrl.brakeCmd = getBrake(car);
        if (car->ctrl.brakeCmd == 0.0) {
            car->ctrl.accelCmd = getAccel(car);
        } else {
            car->ctrl.accelCmd = 0.0;
        }

 

Zu diesem Beitrag gehören 3 Anhäng(e). Um diese zu sehen oder zum Download müssen Sie sich einloggen.
  • Win-Digipet-Version:
    Win-Digipet-Version: 2021.1.13
  • Anlagenkonfiguration:
    2-Leiter, Lodi Rektor; 3x Lodi Booster; Lodi LX  S882.+ 8x Lodi GBM8v2, Lodi S88 CM + 2x Lodi RM16+; Lodi Shift +8x DW-DC+4x 16-SD-DFL, Lodi Con
  • Rechnerkonfiguration:
    IntelNUC8i7HVK /32GB Ram /Radeon™ RX Vega M GH /Windows 11 Profi edition

Offline B.Doorduin

  • Senior-Mitglied
  • Beiträge: 207
  • Ort: Bergen op Zoom Ort bei GoogleMaps suchen nl
Re: Wielslip voorkomen
« Antwort #16 am: 05. Januar 2020, 23:23:22 »
Hoi Rupert,

TOP!!! :) :)
Deelnemer Windigipet Gebruikersgroep Nederland
Vriendelijke groet
Bas Doorduin
  • Win-Digipet-Version:
    2009PE
  • Anlagenkonfiguration:
    Fleischmann/Roco DCC, 2-Rail, Twin Center, HSI-88, TT-DEC, Epoche I-III, schaal H0, rollend materiaal: Duits...
  • Rechnerkonfiguration:
    Windows10