Hur många funktioner kan behövas på ett lok?

[daniel]

Dem ursprungliga frågan verkar vara baserad på att JMRI är begränsat av DCC. Är antalet funktioner verkligen begränsat till F0-F29 i DCC?
Någonstans i tråden stod det att DCC stöder 32000 funktioner, stämmer detta och vad är i så fall problemet att få JMRI att stödja fler funktioner, annat än att det inte finns några dekodrar som stödjer detta ännu och därmed inte heller någon standard hur de skall adresseras?

Alla körkontroller i JMRI, oavsett om det är en körkontroll i PanelPro, en körkontroll i form av WiThrottle, eller någon annan sorts körkontroll, så ärver de från interfacet Throttle. Källkoden till jmri.Throttle finns här:
https://github.com/JMRI/JMRI/blob/maste ... ottle.java

Titta på rad 36 - 352. Visst går det att utöka med fler funktioner, men låt säga att det kommer en dekoder som klarar 128 funktioner. Då kommer de nuvarande 317 raderna bli i storleksordningen 1400 rader, enbart för att hantera funktionerna.

När projektet JMRI startades 2001 fanns det bara någon eller några få funktioner, så koden var funktionell då. Och sedan har ingen brytt sig om att fixa problemet när antalet funktioner har utökats.

------------------

Jag tittade på DCC-standarden och det finns beskrivet i S-9.2.1 DCC Extended Packet Formats. Se sida 7, stycket märkt med nummer 305. Där beskrivs att en dekoder kan ha 32767 olika "states". Ett "state" är ungefär som en funktion men har en egen adressrymd.

Eftersom LocoNet har stöd för att skicka DCC-kommandon över LocoNet så har LocoNet även stöd för dessa states, oavsett om LocoNet-centralen har stöd för det.

Med vänlig hälsning
Daniel

[daniel]

För dom flesta lok räcker programeringsraderna till, men det hittas ju ständigt på nya logiska funktioner och säkert ökar behovet för fysiska funktioner i framtiden också, skala 1 är nog redan där med alla möjligheter som finns när det blir mer utrymme under lokkåpan!

Plats under kåpan på större lok i skala H0 är inget problem om dekodertillverkarna börjar utnyttja möjligheterna som dagens elektronik ger. Idag börjar ju vissa lok i N-skala få ljuddekodrar.

Gör som i bilarna: Gå över till en intern buss i loket. Tre eller fyra ledare i en liten kabel räcker gott. Ha ett kretskort i fronten på loket med alla lysdioderna för helljus, halvljus, topplyckta, röd lykta, hyttbelysning och maskinrumsbelysning. Ett likadant kretskort i bakänden på loket. Komplettera sedan vid behov med ett eller flera "funktionskort" för t ex blixtar i maskinrummet på äldre elektrolok.

En sak jag saknar är lokförare i båda ändar som går att fälla så att han inte syns. Ett mikroservo skulle fixa det.

Jag tror inte problemet är tekniskt, utan snarare om tillverkarna kan få ekonomi i det. Det allra bästa är om man hade lyckats få till en standardiserad intern-buss i loken som alla tillverkarna följer. Alla hade tjänat på det genom att utbudet av tillbehör till den bussen hade blivit större.

Med vänlig hälsning
Daniel

[LLJ]

Så JMRI problemet är snarare hur man skall hantera F-tangenterna, inte att skicka ut DCC funktionerna i sig?
Genom att lägga till ett antal shift-tangenter , t.ex. +20, +40 och sedan lägga upp varje funktion som record i en lång array så borde det vara enkelt att hantera fler och bygga ut allt eftersom behovet ökar.

/Lars

[daniel]

Shift-tangenter, m.m., är en fråga för användargränssnittet. Det jag pratar om är hur JMRI hanterar funktionsknappar internt.

Idag har JMRI 29 Java-funktioner enligt:

Kod: Markera allt

public void setF0(boolean f0);
public void setF1(boolean f0);
public void setF2(boolean f0);
...
public void setF28(boolean f0);

Istället borde JMRI ha EN Java-funktion:

Kod: Markera allt

public void setF(int function, boolean value);

Då kan JMRI hantera godtyckligt antal funktionsknappar. (Övre gränsen för datatypen "int" är 2 miljarder och det lär dröja tills vi har dekodrar med 2 miljarder funktioner).

Viktigt att komma ihåg här är att JMRI har Java-funktionerna getF0, setF0, getF0Momentary och setF0Momentary, alltså fyra Java-funktioner för varje funktionsknapp. Så med 29 funktionsknappar blir det 116 Java-funktioner. Dessa funktioner ska sedan implementeras för de olika digitalsystemen, så i praktiken blir det kanske fem gånger så många Java-funktioner, alltså runt 580 Java-funktioner. När det hade räckt bra med fyra Java-funktioner. (Med Java-funktion avses en funktion skrivet i programmeringsspråket Java). Det här bidrar också till att koden blir svår att underhålla.

Observera också att körkontrollerna i JMRI inte har en aning om vilket system JMRI är anslutet till. Det kan vara LocoNet, XpressNet, DCC, Motorola, eller något helt annat.

Och utvecklarna av JMRI inser att den nuvarande koden har problem. Men för att korrigera den och få det rätt behöver man ha koll på vad som kan bli aktuellt framöver.

Med vänlig hälsning
Daniel

[Bengt Samuelsson]

@Daniel: Har man inte jobb så fixar man det

[LLJ]

Det var just av anledningen att varje funktion har mer än en status (t.ex. on/off , monentan on/off) som jag föreslog en record för varje funktion för att reducera antal javafunktioner.

/Lars

[RobertWahlström]

Ja det vore dumt att göra så många nya funktioner. En med argument för nummer är MYCKET mer användbar och framtidssäker