Svenskt Modulforum

Hej!

Efter Grimslövträffen tidigare i år på smålandsbannan så känner jag att trafikmängden inte var i högsta lagret och när det då dessutom gick åt två TK för att bemanna denna linje så har tänkarna gått igång på om det skulle vara möjligt att fjärrstyra en station av denna storlek (tre spår). Svaret är självklart att det går men hur ser andra på de, är det något som hade varit intressant. Vet att Kristineberg går att fjärklarera men då denna station/trafikplats är relativt omfattande så blir det naturliga att det behövs en person.

I höstas så byggde vi i Växjörallarna stationen Snöflemåla som kan ligga till grund. Stationen består av tre tågspår och ett sidospår där växelomläggningen sker med vippor i sargen och sköldpaddor. Min tanke är så fall att komplettera detta med några relä och styrning med Arduino och loconet för att med enkelhet bygga en panel med möllehems kort. Samt tydliga signaler.

Den slutliga frågan blir då hur mycket övervakning kan tänkas vara en rimlig nivå. Räcker det med spåravkänning eller behövs en eller flera kameror för att kunna säkerställa driften? Kan det tänkas att lokföraren ringer till stationen som fjärrstyr stationen när denne har kommit fram?

Tanken med att kunna fjärrstyra är framförallt att spara folk men inte på stationer och godskunder. Tror dessutom att vara tågklarerare för två mindre stationer kan vara rätt lagom för att inte bli uttråkad då det är lite att göra vilket gör att det blir enklare att någon vill vara TK på de mindre stationerna.

Finns det några tankar kring detta, skulle gissa på att jag inte är den första som tänker i dessa banor.

/Hugo L

FREMO har skissat på en standard för fjärrstyrda stationer. Poängen med det är väl främst att köra flera stationer med en fjärrtågklarerare vid en dator.

https://www.fremo-net.eu/praxis/stellwerke/elekdra/

Det var jag som planerade trafikspelet i Grimslöv, och jag hade faktiskt räknat med att en TKL skulle sköta både Fäboda och Snöflemåla genom att vara ambulerande TKL och vara på den station som krävde mest uppmärksamhet för tillfället. Eftersom båda stationerna hade telefoner kunde TKL avtala med lokförarna om att ringa från den obemannade stationen av de två till den bemannade. Nu blev det inte så, men det hade fungerat.

Ett enklare sätt är att man bemannar den ena stationen och låter lokförarna ringa den andra stationen (eller nästa station på linjen). Man behöver i regel ingen fjärrstyrning utan får ge instruktioner till lokförarna.

Jag har varit med på träffar där Kristineberg har fjärrstyrts. Då har stationen inte varit en förgreningsstation utan endast med ett genomgående enkelspår med mötesspår (och alla industrispår). Men det var smidigt att kunna skicka iväg tåg till Kristineberg innan man behövde ringa nästa TKL, och det var ibland taktiskt att ta tågmöten på Kristineberg för att minska förseningar.

Det är tankar jag har haft ett bra tag nu.
Tidigt föddes tanken på att låta en mindre station kunna skötas av "fjärren" och ett par gånger på ett dygn vara lokalbemannad då gods ska tas emot och gods ska levereras. Den bemanningen skulle då kunna vara ett "kör" uppdrag.
Första tanken var en "ren" loconet lösning med raspberry PI och JMRI, senare med hjälp av arduino nano och loconet. Nu är jag mer inne på nodeMCU och MQTT.
Jag har labbat rätt mycket med nodeMCU med MQTT och wifi. Jag har redan så pass mycket gjort att den styr två signaler med hjälp av MQTT och utökning med två växlar så blir det en mötesplats och då har man en mindre station.
Tanken med den stationen är att den ska automatiskt kunna hanterar möten.

/Benny

Såklart har fremo tagit fram ett sådant dokument. Dock på tyska så vi får vad Google tycker det står där.

Stefan det fungerade bra att vara TKL för både snöflemåla och fäboda, jag vill endast göra det ändå enklare. Så där av frågan och jag tog endast upp det som ett exempel är att det skulle fungera bra i tillämpningen på en träff som i Grimslöv.

Att ett lokalgodståg kör dit någon gång om dagen och då att stationen är lokalbemanad förmodligen av lokföraren själv en en trevlig idé.

Dom gångerna Kristineberg har varit med som fjärstyrd har då endast spåravkänning används eller har man känt behovet av kamera övervakning? Eller har den varit så pass nära så man faktiskt har sätt den från den stationen som varit en TKL på?

/Hugo

Om ställverket är byggt med MGP's lösning så är det väl "bara" en längre Loconet-kabel som behövs för att kunna fjärrstyras? Förstod det som att Anders var inne på att hitta någon lösning för "trådlös Loconet".

Tror Bennys lösning är smidigare, bättre, mer framtidssäkert och billigare än någon slags loconet-lösning.
Är själv inne på liknande lösningar för framtida projekt med en fjärrstyrd infartssignal, tänk vad smidigt att slippa dra extra kablar över halva lokalen för att kunna styra olika signallösningar...

etxbct skrev: ↑2020-06-02, 22:35 Det är tankar jag har haft ett bra tag nu.
Tidigt föddes tanken på att låta en mindre station kunna skötas av "fjärren" och ett par gånger på ett dygn vara lokalbemannad då gods ska tas emot och gods ska levereras. Den bemanningen skulle då kunna vara ett "kör" uppdrag.
Första tanken var en "ren" loconet lösning med raspberry PI och JMRI, senare med hjälp av arduino nano och loconet. Nu är jag mer inne på nodeMCU och MQTT.
Jag har labbat rätt mycket med nodeMCU med MQTT och wifi. Jag har redan så pass mycket gjort att den styr två signaler med hjälp av MQTT och utökning med två växlar så blir det en mötesplats och då har man en mindre station.
Tanken med den stationen är att den ska automatiskt kunna hanterar möten.

/Benny

Intressant Benny!

Kör du någon egen standard på MQTT-topics, elller har du hittat någon som du följer?
Vi är nog 4-5 personer (som jag känner till, kanske finns många fler)) som håller på lite med MQTT och MJ, risken är att vi får ungefär lika många olika standarder.

Jo jag har byggt MQTT strukturen på det jag funnit.

Jag har byggt mitt på Peter Kindströms MQTT projekt (https://github.com/mekanoid) samt det jag fick till mig på körningen i Grimslöv i våras. Där fick jag ett papper av någon från N skalan (vet ej hans namn) som också byggt MQTT för att fjärrstyra en station/lastplats. Hans topic är /mqtt_n/rower/sigmod_a/... Han undrade också om det tagits fram någon standard för MQTT till MJ.

Den topic jag har börjat använda är: körning/node/rapporttyp/track/name/state
Nu är state det ända jag använder så här långt då jag realiserat autonoma blocksignaler som lyssnar på signalen/stationen före och efter och då blev state det som den lyssnar på.

Ex.
mqtt_n/bs-1/signal/up/cda1/state
mqtt_n/bs-1/block/up/s123/state
mqtt_n/cda/turnout/up/vx23/state
mqtt_n/bs-1/traffic/up/direction/state

Om vi ska göra MQTT noder som ska kunna fungera ihop så måste vi ha en gemensam topic att följa samt payloads.
För att styra eget internt spelar detta ingen roll.

De payload jag använder nu är vanlig text istället för json.
mqtt_n/bs-1/signal/up/cda1/state {stop,d80,d40,d40short,d80wstop,d80wd80,d80wd40}
mqtt_n/bs-1/block/up/s123/state {free,occupied}
mqtt_n/cda/turnout/up/vx23/state {closed,thrown}
mqtt_n/bs-1/traffic/up/direction/state {up,down}

Mina blocksignaler är tänkt att kunna fungera ihop med andra blocksignaler och ut/in fart för stationer för att kunna visa rätt signalbild. Jag har lagt upp första versionen på github https://github.com/etxbct/mqttBlockSig.
Den mötesstation jag jag har logiken till är som blocksignalerna, autonom, dvs den lyssnar på signal/station före och efter för att avgöra om ett möte kommer ske eller ej och då leda in första tåget på sidospår och låta andra passera och därefter släppa ut det första på linjen igen. Som spåravkänning använder jag IR-sensorer så man vet att "allt" har passerat en signal.

För att göra blocksignalen enkel att använda så laddar den ner sin konfiguration via http GET och då kan man göra konfig för alla blocksignaler för en körning och de hämtar då automatiskt sin konf, i json format, vad de har för signal/station före och efter som den ska lyssna på. samt adressen till MQTT brokern som ska användas. Det enda man behöver konfa på blocksignalen är accesspunkten den ska användas om vi inte alltid kör samma accesspunkt namn/pin på alla körningar.
Hittas ingen konfig via http GET så används den konfiguration som finns lokalt i blocksignalen, som även går att ändra via en browser till blocksignalens ip adress.

/mvh
Benny

etxbct skrev: ↑2020-06-06, 13:28 Den topic jag har börjat använda är: körning/node/rapporttyp/track/name/state
Nu är state det ända jag använder så här långt då jag realiserat autonoma blocksignaler som lyssnar på signalen/stationen före och efter och då blev state det som den lyssnar på.

En reflektion är att det nog är bra att välja engelska ord. Då slipper man alla problem med Å, Ä och Ö. Det som kan funka utmärkt på en dator kan ge problem på en annan. Exempelvis kan terminaler (kommunikationen över serieport) visa Å, Ä och Ö fel om terminalen och datorn inte är överens om teckenkodningen.

Mvh Daniel