Globala celler/variabler strular

[LillWicke]

Precis som du skrev, det är helt naturligt. Fenomen som man kanske inte tänkt på kan ju uppstå när man skriver in "nutid" från Date() på ställen där scriptet körs i "dåtid" medan diagramritningen sker.

Och var står detta att läsa om i script-manualen? Vilka andra funktioner kör i "dåtid" och vilka kör i "nutid"?

Varför har du inte kläckt ur dig det här tidigare om du vetat om det? Det har gått flera månader sedan tråden skapats.

Vad menar du föresten med delar av scriptet? Hur skall man veta vilka delar som körs i "dåtid" och vilka delar som körs i "nutid".

[Rikard Nilsson]

Reserverade variabler listas här:

http://www.autostock.se/NATscriptref...Variabler.html

och Date()-kommandot beskrivs här:

http://www.autostock.se/NATscriptref/Date.html



Texten är från Lasses tid, så det kan säkert behöva uppdateras och förtydligas. Du får ursäkta att jag inte lyckades lista ut att det var en förväxling av Date() och D när du gick ut med varningar om att villkorsdelen i SetGVarIf() inte skulle fungera.

[LillWicke]

De där länkarna du postade har säkert alla som scriptar läst.

Jag frågade inte efter dessa, utan det jag frågade efter var/hur man får reda på vilka funktioner som skall köras i dåtid och vilka funktioner som skall köras i nutid, samt hur man vet vilka delar av scriptet som körs i "dåtid", samt vilka delar som körs i "nutid".

[Rikard Nilsson]

Allt körs enligt databastid förutom Date().

[LillWicke]

Allt körs enligt databastid förutom Date().

Ok, det var ju lätt att komma ihåg.

Det man frågar sig då är ju i vilka fall Date() blir intressant att använda?
Är det bara för rena kontrollsyften i början av ett script, eller finns det andra tillfällen?

[Rikard Nilsson]

Jo, exempelvis om man vill mäta tid ner till sekundnivå för kontrollsyften. Date() returnerar systemtiden och är därför inte beroende av scriptupplösningen. D däremot returnerar tidpunkten då innevarande period börjar. Alltså, det blir beroende av vilken upplösning scriptet körs i.

[LillWicke]

Date() returnerar systemtiden och är därför inte beroende av scriptupplösningen. D däremot returnerar tidpunkten då innevarande period börjar. Alltså, det blir beroende av vilken upplösning scriptet körs i.

Det där var ju väldigt viktig information, det blir att tänka till.


Rikard, vad säger du om att överst i det här forumet ha en klistrad tråd, som ni ansvariga vart efter kan fylla på med viktig script-information och annat smått och gott, som inte går att hitta någon annanstans.

Börja exempelvis med det som framkommit i den här tråden: "att SetGvarIf(), (och även If() har jag upptäckt), inte fungerar tillsammans med Date()-funktionen om man samtidigt har diagramritningen påslagen".

En sådan klistrad tråd borde bespara er mycket arbete, i väntan på att någon tar sig an att uppdatera scriptmanulen.

[LillWicke]

Nu har jag testat lite mer.

Det fungerar inte att ha D i stället för Date() i SetGvarIf().
Om scriptet körs i 30min upplösning och en signal kommer mitt i så skrivs ingenting i cellen förrän i inledningen av nästa period. Det är naturligtvis inte bra, då det förstås skall skrivas i cellen samma stund som triggern signalerar.

Rikard, går det på något sätt att lura SetGvarIf() att köra i "nutid" trots att man har diagramvisning påslagen?

Jag har inte provat, men kommer din lösning att fungera med date() i "minut_nu"?
{ Skrivning }
SetGvarIf(minut_nu,80,and(buy2,eqv(cum(1),1)),T)
SetGvarIf(minut_nu,90,and(short2,eqv(cum(1),1)),T)

Om det inte fungerar tror du att man kan be Lasse att uppdatera funktionen lite, så att den kan fungera med date() även med diagramvisning påslagen?


Alernativet är ju annars att göra som Henrik, och alltid köra med diagramvisningen frånkopplad, med allt omscriptande det medför.

[Rikard Nilsson]

Varianten med Cum() skriver vad som helst så länge det körs "live". Så fort det finns fler än två staplar i diagrammet blir Cum(1) högre än 1 och då är inte villkoret sant längre = skrivning blockerad. Ska alltså fungera med Date(). Enda situationen jag kan komma på där det skulle kunna bli fel är under första stapeln som visas i diagrammet. Då är Cum(1) fortfarande = 1 och skrivning är tillåten. Får du en signal just då skrivs den vid diagramritning. Det i sin tur skulle man kunna isolera bort genom att ha minst två dagar öppet i diagrammet och lägga till följande som villkor:

samma_dag=eqv(int(date(),int(d)))

vilket bara är sant under den dag då databastid och systemtid är samma dag. Dvs, har du mer än 1 dag i diagrammet blir det falskt "dagen innan" och Cum(1) kan användas som villkor för skrivning eftersom första stapeln i diagrammet hamnar på en "ogiltig" dag. Vi använder ju inte L-parametern alls och därmed kan du skriva in vilket data som helst, även Date().

SetGvarIf(minut_nu,80,and(samma_dag,and(buy2,eqv(cum(1),1))),T)
SetGvarIf(minut_nu,90,and(samma_dag,and(short2,eqv(cum(1),1))),T)


Obs! Har inte testat detta, det är bara ett teoretiskt resonemang.

[LillWicke]

För mig känns det här resonemanget minst sagt udda.

Du säger att skrivningen blir blockerad, och så lång är jag med, villkoret är ju falskt, men för min del blir resultatet då att ingenting kommer att skrivas till cellen?

Eller menar du helt enkelt att skrivningen i "dåtid" blir blockerad och skrivning i "nutid" släpps igenom??
Dvs. om "buy" blir sann skrivs "minut_nu" med Date()? Hur kommer det sig i såfall att detta är möjligt när villkoret som helhet är falskt ?

[Rikard Nilsson]

Du vill ju blockera skrivning utom för situationen "just nu", så att du slipper effekter av när scripten körs under uppritning av diagram.

1. Eqv(cum(1),1) är sant utom i diagram.
2. Eqv(int(date()),int(d)) är sant om datastid och systemtid är samma dag.
3. Kombinerar vi dessa båda med ditt skrivvillkor får vi något som skriver till cellen endast idag, endast om det inte är en diagramritning och endast om ditt skrivvillkor är sant.

[LillWicke]

1. Eqv(cum(1),1) är sant utom i diagram.

Det är just det här påståendet som ställer till problem för mig.
Diagram är ju påslaget och då borde cum() bli falsk.

Eller menar du istället att cum() blir falskt endast i det ögonblick då diagrammet uppdateras och är sant när scriptet uppdateras?

Även ett sådant påstående ställer till problem för mig då du tidigare sagt att scripten körs samtidigt med att diagrammet uppdateras, nämligen var 5:e sek. Vilket borde innebära att tidpunkten blir densamma och det hela borde inte fungera.?

Eller råder det alltid en förskjutning i tid mellan diagramuppdatering och scriptuppdatering? Hur stor är denna isåfall, 1 sek? Uppdateras alltid diagrammet först?

Ett lite närmare klargörande här vore önskvärt.

[LillWicke]

Nu har jag testat vidare.
Jag kan meddela att omskrivningen med cum() som Rikard föreslagit fungerar stabilt, trots att jag med diverse knep har försökt att slå ut den.


Hur kommer det sig att detta fungerar då?
Jag försöker svara på min egen fråga i inlägg #72.

Det verkar som att scriptet körs snabbt två gånger efter varandra när diagramritningen är påslagen. En gång när själva diagrammet uppdateras och en gång strax efter då enbart själva scriptet uppdateras.
Jag kallar de båda uppdateringarna ”diagramkörningen” och ”scriptkörningen”

Eftersom digrammet uppdateras i databastid, körs scriptet (under ”diagramkörningen”) också i databastid och därmed inträder det förhållandet att vissa villkor, som i systemtid är sanna, blir falska och andra villkor som i systemtid är falska blir sanna. Däremot när scriptet körs med egen uppdatering (”scriptkörningen”) uppdateras det i systemtid och villkor som, i systemtid, är sanna blir då sanna och villkor som är falska blir falska.

Detta innebär att om man låter båda uppdateringarna köra helt ohämmat efter varandra uppträder fenomenet att falska villkor blir sanna, och därmed uppkommer ”buggen” som jag tidigare varnat för (falsk=sant).

Vad jag har kunnat mäta mig till är tidsdifferensen mellan de två körningarna ca 4sek, och kan man då på något lämpligt sätt blockera att vissa funktioner ”exekveras/skriver” under ”diagramkörningen” och bara låta dem ”exekvera/skriva” under ”scriptkörningen” uppträder inte "buggen", och man är hemma.


Man kan blockera ”diagramkörningen” på två sätt:
1) Helt sonika genom att stänga av diagramritningen som Henrik föreslog. Då körs enbart ”scriptkörningen” och allt är frid och fröjd.
(Det fungerar)

2) Göra det som Rikard föreslog, nämligen att för vissa funktioner blockera ”exekvering/skrivning” vid ”diagramkörningen”.
(Det fungerar utmärkt och fördelen är förstås att man kan ha diagramritningen påslagen som vanligt)


Nedan följer ett exempel på scriptning där funktionen SetGvarIf() hindras från att skriva i cellen under diagramkörningen.

Scriptet skriver tiden i minuter till cell 80 då en ny signal inträffar. Därefter kan man läsa av hur lång tid i minuter det gått från det att detta inträffade.
Nollning av cellen görs när signalen inte längre gäller.

Scriptning:
med2:=mov(c,5,s)
minut_nu:=mult(frac(date()),1440)
datum_ok:=eqv(int(d),int(date()))
block_diag_skrivn:=and(datum_ok,eqv(cum(1),1))

i30(
buy2=gt(med2,aref(med2,1))

{ Skriv tid i cell 80 vid ny signal}
nysignal=and(buy2,eqv(GetGvar(80,N),0))
SetGvarIf(minut_nu,80,and(buy2,block_diag_skrivn),T)

minsedan_signal=if(gt(GetGvar(80,N),0),sub(minut_nu,GetGvar(80,N)),0)

Gör någonting med villkoret…

{ Nolla cell 80}
nollvillkor=and(not(buy2),gt(GetGvar(80,N),0))
SetGvarIf(0,80,and(nollvillkor,block_diag_skrivn),T) { nollställer cell 80 om ej signal }

Scriptet fortsätter…
)

Om man tar för vana att alltid lägga till ”block_diag_skrivn” i villkorsdelen av SetGvarIf()-funktionen kommer de globala cellerna att fungera utan strul, oavsett om man har diagramvisningen påslagen eller inte.

Rikard det vore bra om du kunde dementera eller bekräfta ”förklaringen”, jag givit ovan, till varför "blockning" fungerar.


EDIT: Ändring av variabelnamnet samt att jag lagt till ett Scriptexempel som man kan ha användning av.

[Rikard Nilsson]

Det stämmer att scriptet körs dels vid diagramritning och dels "live". Det är två olika körningar.

Det enda jag har att anmärka skulle väl vara "blocka_diagram" som egentligen är tvärtom, kanske borde heta "ej_diagram" för att markera att det är sant när det inte rör sig om en diagramritning.

Såg att det smugit sig in ett mellanslag efter likhetstecknet också. Kan ev ställa till problem.

Skönt att det funkar stabilt i alla fall!

[mikbob]

Nu har jag testat vidare.
Jag kan meddela att omskrivningen med cum() som Rikard föreslagit fungerar stabilt, trots att jag med diverse knep har försökt att slå ut den.


Hur kommer det sig att detta fungerar då?
Jag försöker svara på min egen fråga i inlägg #72.

Det verkar som att scriptet körs snabbt två gånger efter varandra när diagramritningen är påslagen. En gång när själva diagrammet uppdateras och en gång strax efter då enbart själva scriptet uppdateras.
Jag kallar de båda uppdateringarna ”diagramkörningen” och ”scriptkörningen”

Eftersom digrammet uppdateras i databastid, körs scriptet (under ”diagramkörningen”) också i databastid och därmed inträder det förhållandet att vissa villkor, som i systemtid är sanna, blir falska och andra villkor som i systemtid är falska blir sanna. Däremot när scriptet körs med egen uppdatering (”scriptkörningen”) uppdateras det i systemtid och villkor som, i systemtid, är sanna blir då sanna och villkor som är falska blir falska.

Detta innebär att om man låter båda uppdateringarna köra helt ohämmat efter varandra uppträder fenomenet att falska villkor blir sanna, och därmed uppkommer ”buggen” som jag tidigare varnat för (falsk=sant).

Vad jag har kunnat mäta mig till är tidsdifferensen mellan de två körningarna ca 4sek, och kan man då på något lämpligt sätt blockera att vissa funktioner ”exekveras/skriver” under ”diagramkörningen” och bara låta dem ”exekvera/skriva” under ”scriptkörningen” uppträder inte "buggen", och man är hemma.


Man kan blockera ”diagramkörningen” på två sätt:
1) Helt sonika genom att stänga av diagramritningen som Henrik föreslog. Då körs enbart ”scriptkörningen” och allt är frid och fröjd.
(Det fungerar)

2) Göra det som Rikard föreslog, nämligen att för vissa funktioner blockera ”exekvering/skrivning” vid ”diagramkörningen”.
(Det fungerar utmärkt och fördelen är förstås att man kan ha diagramritningen påslagen som vanligt)


Nedan följer ett exempel på scriptning där funktionen SetGvarIf() hindras från att skriva i cellen under diagramkörningen.

Scriptning:
med2=mov(c,5,s)
minut_nu=mult(frac(date()),1440)
datum_ok=eqv(int(d),int(date()))
blocka_diagram= and(datum_ok,eqv(cum(1),1))
buy2=gt(med2,aref(med2,1))

SetGvarIf(minut_nu,80,and(buy2,blocka_diagram),T)

Om man tar för vana att alltid lägga till ”blocka_diagram” i villkorsdelen av SetGvarIf()-funktionen kommer de globala cellerna att fungera utan strul, oavsett om man har diagramvisningen påslagen eller inte.

Rikard det vore bra om du kunde dementera eller bekräfta ”förklaringen”, jag givit ovan, till varför "blockning" fungerar.

Bra! Tror nog de flesta lärde sig en hel del om scriptning generellt genom att läsa igenom den här tråden