I noticed that some of the jscalls were taking much longer than the norm, so I began to time the calls.
All innerHTML text changes are routed through a single sub, which can measure the jscall duration. As measured this way, the initial duration might be 32mS. However, most calls take a bit longer and some calls take much longer (over a second in the example below, and I have seen several seconds) with the maximum becoming progressively longer, so I suspect something untoward is happening. The code reports the duration if it exceeds the previous longest.
This is part of a recent log, from startup, with just the relevant entries showing the longest call up to that point, to show the problem. Most updates are a short string representing numerics, some are messages of perhaps 20 bytes.
Code: [Local Link Removed for Guests]
[11/04/24-21:16:35 _6 ch SRpZhCb:CpbU] draw web table <- empty table drawn, then initial updates
- timestamp - version - system state - function performed
[11/04/24-21:16:35 _6 ch SRpZhCb:CpbU] max mS:32 hwtemp )
- html id -
[11/04/24-21:16:35 _6 ch SRpZhCb:CpbU] max mS:33 rettemp ) updates as things change
[11/04/24-21:16:35 _6 ch SRpZhCb:CpbU] max mS:34 retmessage )
[11/04/24-21:16:35 _6 ch SRpZhCb:CpbU] max mS:35 localexttempmessage )
[11/04/24-21:16:41 _6 ch SRpZhCb:CpbU] max mS:151 scandur
[11/04/24-21:21:12 _6 ch SRpZhCb:CpbU] max mS:191 clock <- regular clock updates
[11/04/24-21:22:13 _6 ch SRpZhCb:CpbU] max mS:211 rettemp
[11/04/24-21:24:57 _6 ch SRPZhCB:CpBU] max mS:251 flowtemp
[11/04/24-21:26:54 _6 ch SRPZhCB:CpBU] max mS:271 localexttemp
[11/04/24-21:27:33 _6 ch SRPZhCb:CpbU] max mS:291 flowtemp
[11/04/24-22:06:59 _6 ch SRpZhCb:CpbU] max mS:371 rettemp progressive increase in max time
[11/04/24-22:33:03 _6 SRPzhcb:CpBU] max mS:531 clock for a function that initially only takes 32mS
[11/04/24-22:46:21 _6 SRpzhcb:CpBU] max mS:551 elapsed
[11/04/24-23:00:46 _6 SRpzhcb:CpBU] max mS:552 elapsed
[11/04/24-23:07:23 _6 SRpZhcb:CpBU] max mS:652 clock
[12/04/24-04:47:18 _6 SRpzhcb:CpBU] max mS:672 localexttemp
[12/04/24-09:20:16 _6 ch SRPZhCb:CpbU] max mS:911 localexttemp
[12/04/24-10:36:50 _6 SRpzhcb:CpbU] max mS:1072 clock
[12/04/24-12:38:31 _6 SRpzhcb:CpbU] max mS:1073 clock
[13/04/24-06:38:32 _6 ch SRPZhCB:CpBU] max mS:1095 clock
[13/04/24-06:38:37 _6 ch SRPZhCB:CpBU] html reload [loadhtml] table <- first look in the morning
[13/04/24-06:38:37 _6 ch SRPZhCB:CpBU] draw web table
immediately followed by:
[13/04/24-49.4 _6 ch SRPZhCB:CpBU] max mS:1096 clock <- the 49.4 is likely to be temperature data, in the wrong place
[13/04/24-49.4 _6 ch SRPZhCB:CpBU] max mS:1120 flowtemp suggesting some sort of variable overwriting
at which point it immediately rebooted
Code: [Local Link Removed for Guests]
change_text "flowtemp", flow_temp$, last_flow_temp$, textcolour$
Code: [Local Link Removed for Guests]
sub change_text (targ$,newtext$,last_newtext$,colour$)
if (last_newtext$ = newtext$) then exit sub
in_millis = millis
last_newtext$ = newtext$ 'save value via pass-by-name
jscall |_$("|+targ$+|").innerHTML ="| + newtext$ +| "|
if colour$ <> null$ then jscall |document.getElementById("|+targ$+|").style.color = "|+colour$+|";|
scan_duration = millis - in_millis
if scan_duration>max_scan_duration then max_scan_duration=scan_duration:timestamp "max mS:"+str$(max_scan_duration)
end sub
The core question therefore is: why would jscalls occasionally take progressively longer than the norm, sometimes much longer, and possibly linked with unexplained program restarts? Would the restarts be related to the data corruption noted in the last two lines of the log?
Stuart