CS3 langsom død

[Søren]

Et SD kort i en CS3 øger kapaciteten for det interne lager. HVIS man selv vælger at gemme ting på det.

CS3 kan ikke på magisk vis benytte det som erstatning for manglende hukommelse.

Når det er sagt, så er manglende hukommelse næppe Prebens problem. Det er nærmere programmeringen af anlægget der får skabt "et eller andet" som trætter CS3'eren.

[marklinbygger]

til søren

nej det kan det ikke , men det kan frigøre plads i den hukommelse cs3 har , så bliver der mere plads til at køre andre ting
og du burde vide at mangel på ram gør at alt bliver meget langsomt afviklet

mvh marklinbygger

[marklinbygger]

til PerR

det du siger er at der er ikke ram på et sd kort ???
set i lyset af det så virker mit sd kort i min cs3 rigtigt godt

mvh marklinbygger

[PerR]

Ja, jeg siger at der ikke er RAM på et SD kort.
Derfor får CS3 ikke mere RAM ved at montere et SD kort.
Hvis du prøver at sætte et SD kort i din CS3, så vil der komme en rød prik der indikerer at der er en opdatering. Opdatering består i at der bliver gemt nogle mapper og filer på SD kortet.
Hvis du slukker for din CS3 og flytter SD kortet over i din PC, så kan du se mapper og filer.
Hvis SD kortet var RAM, så ville indholdet forsvinde når der slukkes for strømmen til CS3 og der ville heller ikke være en filstruktur på SD kortet.
Hvis du vil have mere information om om RAM og den hukommelse hvor Linux, CS3 programmerne, databaserne og opsætning er gemt, så kan du prøve at se i nogle af de system log filer som gemmes i forbindelse med at man slår logning til og gemmer resultatet på en USB stick.
Mvh Per

[Søren]

nej det kan det ikke , men det kan frigøre plads i den hukommelse cs3 har , så bliver der mere plads til at køre andre ting
og du burde vide at mangel på ram gør at alt bliver meget langsomt afviklet

Du blander tingene sammen. Et SD kort frigører ikke hukommelse i din CS3. Det er ikke sådan CS3'eren fungerer.

[Søren]

Problemet med den "langsomme død" er nu løst.

Sammen med udviklerne, har vi gennemgået logfilerne og kunne se, at timeouts skyldtes, at en uforholdsmæssig stor mængde af kommandoer blev sendt på samme tid. Problemet opstår når der er mange stationære MM dekodere i spil, og når automatiseringen af anlægget gør at hændelser er meget aktive.

MM er en ældre protokol og kræver derfor at der sendes både en start- og en slutkommando. Forstået på den måde, at en sporskiftedekoder modtager en "tænd udgang" og en "sluk udgang" kommando. Det giver dobbelt så mange kommandoer pr. operation, og mange af dem på en gang er uhensigtsmæssig.

Ved at ændre dekoderne i Prebens anlæg til at tale DCC i stedet for MM, går problemet væk og der kommer ikke længere timeouts.

Løsning: Skift til DCC, så opstår problemet ikke.

Det taler ind i det emne vi tidligere har vendt her på Baneforum, at man skal undlade at benytte MM hvor det er muligt. Det er ikke en tidsvarig protokol, hvorfor alle Märklin-dekodere i dag også forstår DCC. Märklin understøtter fortsat MM pga. bagudkompatibilitet. MM er ikke blevet udviklet aktiv i mange år(tier).

Bemærk i den forbindelse, at MM og MFX ikke er det samme, det er to forskellige teknologier. MFX giver ikke ovenstående problemer.

Bemærk! Der er dog det "aber dabei", at stationære MFX dekodere modtager deres instrukser i enten MM eller DCC. Hvis du har disse, skal du sørge for at DIP-switch nr. 10 står til ON. Så vil dekoderen forvente instrukser i DCC formatet. Ved stationære dekodere benyttes MFX kun til autoregistrering og programmering, ikke til instrukser. Dette gælder ikke for loks, hvor MFX er en komplet protokol.

Benytter du 3. parts dekodere, der kun forstår MM, så er der kun én ting at gøre: Lad være med det. Benyt en DCC dekoder.