HP Prime auto shut down behavior

[DrDarius]

I noticed the following behavior of my calculator (G2 running f/w 2020 01 21):
If I execute a program which runs longer than the shutdown value defined in TOff, the calculator immediately shuts down after the program terminates (regardless of key presses or screen touches during execution)--unless TOff is modified in this program; in the latter case the shut down time set by the program starts counting from the moment when it terminates.

Here is a simple program and experiment demonstrating the issue:

Code:

EXPORT WHATEVER()
BEGIN
//  TOff:=15000;
  PRINT();
  PRINT("STARTED...");
  LOCAL Time:=TICKS(),Elapsed; 
  REPEAT
    Elapsed:=TICKS()-Time;
    GETKEY();
    MOUSE();
    IF Elapsed==25000 THEN
      PRINT("NOW !");
    END;
  UNTIL Elapsed>=30000;
  PRINT("DONE");
  WAIT(1); 
END;

1. Set TOff to 15000 (15 sec) from the keyboard.
2. Run the program without touching keyboard or touch screen. The calculator will display: "STARTED..." at 0 sec, "NOW !" at 25 sec, and "DONE" at 30 sec. One second later (because of WAIT instruction) the calculator will shut down.
3. Run the program again, this time pressing any key (with exception of 'On', of course) when "NOW !" appears. The results will be the same as above.
4. Run the program again, this time touching the screen when "NOW !" appears. The results will be the same as above.
(Conclusion: under conditions described above, i.e., program execution time is longer than the shut down value defined by TOff, the calculator shuts down when the program terminates regardless of user interaction during program execution. If the key presses/touches affected shut down counter, in (3) and/or (4) the calculator would shut down 10 seconds after termination of the program.)
5. Modify the program by uncommenting 'TOff:=15000;' line.
6. Run the program without touching keyboard or touch screen. After displaying "DONE" and waiting additional 1 sec forced by WAIT, the calculator will remain on for next 15 seconds, and then will shut down.
7. The same behavior will be observed during conducting tests (3) and (4). (This test is not really necessary, but for the sake of completeness...)
(Conclusion: when TOff is modified within the program, the shut down time is reset, and the counting begins when the program terminates.)

I ran across this issue when I was using a program I had written, with which I was interacting by touching screen, and which kept running for longer than default 5 minutes (which I had never changed). After some time spent on trying to figure out what bug I planted in the code so the calculator shuts down, I discovered that it the behavior was shut down time related.
An additional discovery was calculator's behavior when TOff is modified during the program execution. I am guessing that when the program terminates, the OS "discovers" modified TOff value, and resets the shut down counter before the previous elapsed countdown value event takes effect.

In my opinion, when a program is ran on the calculator, regardless of user interaction during that time (i.e., regardless whether any key is pressed or the screen is touched), the shut down counter should be reset every time when the program terminates. In other words, regardless of how long the program runs, the calculator should remain on for a time defined by TOff after it terminates. This seems more intuitive to me.

A work around this issue is to put a clause in the program which reads TOff, and stores is back again.

Code:

...
TOff:=TOff;
...

seems to be working.

(Note: I have not checked how the previous versions of calculator f/w behave. I also assumed that the system installation on my calculator is clean, and it's not an artifact, but normal behavior, thus did not perform factory reset to start from the clean slate state. I also did not scan the user's manual looking for possible mentioning of this behavior buried deeply in hundreds of pages of text.)

Darius

[Carlos295pz]

That has always happened, I also consider it annoying since if at the end of the program it is assumed that you have not paused the calculator yet, it almost makes no sense to turn it off in that way. I think it is an error in capturing events, although I may be very wrong.

I usually use TOff at 1min, because of my obsession with the battery and similar things, and what I have verified is that if you stop pausing while you have an INPUT, the calculator turns off but turns on again on the INPUT, it is impressive although only with integrated interfaces.

[DrDarius]

(02-09-2020 07:50 PM)Carlos295pz Wrote:  That has always happened, I also consider it annoying since if at the end of the program it is assumed that you have not paused the calculator yet, it almost makes no sense to turn it off in that way.

So it's an old issue.
I have never noticed it. It happened to me a few times that I left the calculator running programs executing for more than 5 minutes, and the calculator was off when I returned, but I thought that the program had stopped, then 5 minutes elapsed, and then the calculator turned itself off. Only when I had to interact with the program during execution lasting more than 5 minutes I noticed that it works differently.
Thanks for clarifying it to me.

Darius

[Jacob Wall]

Similar experience that I also found quite annoying. My workaround was to capture TOff value to a variable at launch of program, then set TOff value again from said variable just prior to program finishing. It has been some time since I spent time on this, but from what I recall if you set TOff value has effect of resetting counter.

[DrDarius]

(02-10-2020 12:42 AM)Jacob Wall Wrote:  My workaround was to capture TOff value to a variable at launch of program, then set TOff value again from said variable just prior to program finishing. It has been some time since I spent time on this, but from what I recall if you set TOff value has effect of resetting counter.

Actually, I described the work around in my post, and it's almost the same.
I verified that you don't need to use additional variable. Assigning TOff to itself at any location of the code does the trick. It's the write to TOff that triggers the shut down counter reset, but it must be checked upon termination of the program. To certain extent it makes sense: the auto shut down is disabled during program execution time, so probably the signal indicating that the write took place is blocked as well.

Darius

[cyrille de brébisson]

Hello,

Time off ticker starts when the user presses keys, not when events associated with said keys finish...

I do not remember the reasoning for this, but it made sense at the time...

Cyrille

[CyberAngel]

(02-09-2020 07:16 PM)DrDarius Wrote:  X
A work around this issue is to put a clause in the program which reads TOff, and stores is back again.

Code:

...
TOff:=TOff;
...

seems to be working.
X
Darius

One more thing: on a long (t>TOff) program
does one put the
TOff:=TOff;
after the long computation, (at the end) TOff already activated
or rather at the very beginning
or just anywhere you want?

What if there is a
BREAK
or similar and the TOff has been passed?
- -
VPN

[Carlos295pz]

(02-10-2020 06:18 AM)cyrille de brébisson Wrote:  Time off ticker starts when the user presses keys, not when events associated with said keys finish...

I do not remember the reasoning for this, but it made sense at the time...

For a moment I also thought it made sense, after that I felt cheated by such behavior xD

(02-10-2020 06:30 AM)CyberAngel Wrote:  What if there is a
BREAK
or similar and the TOff has been passed?

I think it is not worth it to give that behavior a lot of spin, it is rare, but it would be like covering the sun with a finger. If one day it is corrected it will be congratulations

[DrDarius]

(02-10-2020 06:18 AM)cyrille de brébisson Wrote:  Hello,

Time off ticker starts when the user presses keys, not when events associated with said keys finish...

I do not remember the reasoning for this, but it made sense at the time...

Cyrille

My point was that if the program is running, the key presses (or screen touches) seem to be ignored by the system in the context of shut down time modification...

Please sacrifice a few minutes on running an example from my first post. It illustrates the issue.
(Or I am doing something wrong, which may as well be the case. Then please let me know what.)

Darius