Fastclock - önskemål

[daniel]

Om RUT ska vara server så måste RUT-programmet skrivas om så fort man vill ha nya funktioner i FastClock-systemet. T ex info-texter som kom i version 2 av protokollet. Det är bättre att ha olika små program för olika uppgifter än ett stort som kan "allt".

Mvh Daniel

[FreddePettersson]

@Daniel
Kan man inte låta RUT vara en modul i server programmet, dvs ska man modifiera server mjukvaran, läggs RUT som en modul i själva programmet?

Med vänlig hälsning,
Fredrik

[daniel]

Både ja och nej. Att Anders B och jag är negativa till att ha RUT i servern förklaras nog bäst med ett exempel:

I begynnelsen fanns LLJ:s Fastclock. Den fungerade bra men var svår att se på långt avstånd.
Sen kom Anders B med önskemålet om en digital klocka vilket ledde till att jag tog fram en klient till Lars FastClock som visade klockan digitalt.
Med Lars server och min klient började Anders B använda klockan och då ville Anders son även ha klockan i sin mobil, vilket ledde till en Android-app.

Tack vare att Lars klocka hade klient/server med ett enkelt protokoll så har systemet kunnat utvecklats av olika personer på olika plattformar utifrån olika behov.

Även på serversidan har en utveckling skett. Lars klocka stödjer version 1 av protokollet, den skickar enbart ut snabbklockans tid. Men efterhand kom önskemål som krävde en utökning av protokollet och det ledde till version 2 av protokollet som är fullt ut bakåtkompatibelt. Men med ny version av protokollet krävdes en ny server som klarade av detta nya protokoll och en sådan server har Anders B gjort.

------

Antag nu att jag gör en FastClock-server med RUT.

Och sedan att det går ett tag och så en dag kommer Anders och hans son på att de vill ha en server som styrs av mobiltelefonen. Så de tar fram en ny FastClock-server som stödjer protokollet fullt ut och där Anders son gör en Android-app som styr själva servern, t ex anger klockans tid, m.m. Då hamnar vi i ett dilemma, antingen använder vi min FastClock-server med RUT och kan både köra snabbklockan och RUT-klockorna, eller så använder vi Anders FastClock-server och vinner då att trafikchefen kontrollerar klockorna från sin mobil men det går inte att använda RUT-klockorna.

Genom att låta RUT-programmet vara en separat klient så slipper vi hela det här problemet. Då kan vilken FastClock-server som helst användas. Notera att protokollet är kompatibelt åt båda håll. En ny server kan prata med en gammal klient. En ny klient kan prata med en gammal server.

Mvh Daniel

[LLJ]

Programmet skickar ut RUT-signalen på serieporten på RTS-signalen. RTS och GND ansluts sedan lämpligen till två reläer som polvänder 12/24V till RUT-klockorna. Men själva hårdvaran överlåter jag till någon annan.

Mvh Daniel

Det där fungerar inte, då det krävs två styrsignaler, en för vardera relä. Normalt ligger ingen spänning på ledningarna till RUT-uren.
Pulsen är omväxlande polariserad genom att dra det ena eller det andra reläet.

/Lars

[daniel]

Är det så här tidsdiagrammet ser ut för RUT?

Om två signaler behövs så kan jag använda både RTS (RequestToSend) och DTR (DataTerminalReady).

Serieport: http://sv.wikipedia.org/wiki/Serieport

Mvh Daniel

[AndersB]

Tack för det Daniel - jag började skriva ett svar till Lars innan jag såg att tråden fortsatte på ny sida. Man ska inte skriva när man är upprörd...

Jag nöjer mig med: "Vi har nu en öppen och fin arkitektur som har bevisat en hel del. Snälla - förstör den inte!"

mvh/anders

Både ja och nej. Att Anders B och jag är negativa till att ha RUT i servern förklaras nog bäst med ett exempel:

I begynnelsen fanns LLJ:s Fastclock. Den fungerade bra men var svår att se på långt avstånd.
Sen kom Anders B med önskemålet om en digital klocka vilket ledde till att jag tog fram en klient till Lars FastClock som visade klockan digitalt.
Med Lars server och min klient började Anders B använda klockan och då ville Anders son även ha klockan i sin mobil, vilket ledde till en Android-app.

Tack vare att Lars klocka hade klient/server med ett enkelt protokoll så har systemet kunnat utvecklats av olika personer på olika plattformar utifrån olika behov.

Även på serversidan har en utveckling skett. Lars klocka stödjer version 1 av protokollet, den skickar enbart ut snabbklockans tid. Men efterhand kom önskemål som krävde en utökning av protokollet och det ledde till version 2 av protokollet som är fullt ut bakåtkompatibelt. Men med ny version av protokollet krävdes en ny server som klarade av detta nya protokoll och en sådan server har Anders B gjort.

------

Antag nu att jag gör en FastClock-server med RUT.

Och sedan att det går ett tag och så en dag kommer Anders och hans son på att de vill ha en server som styrs av mobiltelefonen. Så de tar fram en ny FastClock-server som stödjer protokollet fullt ut och där Anders son gör en Android-app som styr själva servern, t ex anger klockans tid, m.m. Då hamnar vi i ett dilemma, antingen använder vi min FastClock-server med RUT och kan både köra snabbklockan och RUT-klockorna, eller så använder vi Anders FastClock-server och vinner då att trafikchefen kontrollerar klockorna från sin mobil men det går inte att använda RUT-klockorna.

Genom att låta RUT-programmet vara en separat klient så slipper vi hela det här problemet. Då kan vilken FastClock-server som helst användas. Notera att protokollet är kompatibelt åt båda håll. En ny server kan prata med en gammal klient. En ny klient kan prata med en gammal server.

Mvh Daniel

[AndersB]

Även på serversidan har en utveckling skett. Lars klocka stödjer version 1 av protokollet, den skickar enbart ut snabbklockans tid. Men efterhand kom önskemål som krävde en utökning av protokollet och det ledde till version 2 av protokollet som är fullt ut bakåtkompatibelt. Men med ny version av protokollet krävdes en ny server som klarade av detta nya protokoll och en sådan server har Anders B gjort.

Kanske en sedelärande historia:
Huvudorsaken till ny server var att den gamla fungerade dåligt med många klienter (hängning en gång i halvtimmen).
Lars hade inte tid att rätta buggarna och vi hade en ny körning på gång.
Därmed hade vi behov av en ny server så att nästa körning skulle kunna genomföras utan ständiga omstarter av klockservern.
Hade varit betydligt jobbigare att skriva en ersättare om det varit en massa andra "nödvändiga" funktioner intryckta i den.

Och sedan att det går ett tag och så en dag kommer Anders och hans son på att de vill ha en server som styrs av mobiltelefonen. Så de tar fram en ny FastClock-server som stödjer protokollet fullt ut och där Anders son gör en Android-app som styr själva servern, t ex anger klockans tid, m.m.
...

Kan nämna att Mrclock (mobilappen) redan innehåller en fullfjädrad server (protokoll v2)
Provad i testmiljö med 40 klienter utan anmärkning. Har däremot aldrig (vad jag vet) varit server på en riktig storkörning.

mvh/anders

[AndersB]

Det bör kanske vara ställbart hur långt före RUT-klockorna får vara utan att de ställs om, men samtidigt är det inte bra med allt för mycket inställningar heller.

Mvh Daniel

Man vet ju "klockhastigheten", så om pulslängd + pauslängd anger hur snabbt man får stega framåt, så är det ju rätt lätt att låta klienten själv ta beslutet om vilket som går snabbast, att stega ifatt eller att vänta in.
Behövs då kanske en liten status som anger vad som händer typ "Normal drift", "Snabbstegning", "Väntar in"
mvh/anders

[LLJ]

Om man har en RUT-client, som sänder ut RUT utifrån FastClock tiden, då har väl den bara till att följa tiden?
RUT blir väl aldrig före? (Annat än om man ställer om Fastclock vid omstart)
Eftersom RUT ställs om på annat sätt så får man antingen införa en ny status som anger att klockan är omställd, och då vet en ev RUT klient att den skall snabbstega fram till ny tid eller så får man gå till RUT klienten och manuellt sköta RUT omställningen.

/Lars

[AndersB]

Om man har en RUT-client, som sänder ut RUT utifrån FastClock tiden, då har väl den bara till att följa tiden?
RUT blir väl aldrig före? (Annat än om man ställer om Fastclock vid omstart)
Eftersom RUT ställs om på annat sätt så får man antingen införa en ny status som anger att klockan är omställd, och då vet en ev RUT klient att den skall snabbstega fram till ny tid eller så får man gå till RUT klienten och manuellt sköta RUT omställningen.

/Lars

Uppe i högra hörnet på Daniels förslag på användargränssnitt, har du Servertiden (bör-tid) och RUT-tiden (är-tid).
Skriver du in den tid du vridit in klockorna på i fältet för RUT-tid så kan klienten sen själv ta hand om synkroniseringen.
Klienten hållar alltså reda på vilken tid som faktiskt visas på RUT-klockorna. Så fort den avviker från vad som kommer in från serverklockan så kan den själv synka.

Anledningar till att tiden plötsligt diffar kan ju vara att servern ställts om, klienten har tillfälligt tappat kontakt med nätet eller kanske att man pausat klienten för att byta vägguttag m.m.

mvh/anders