New Version: 2.1.14181 (2018 10 16)

[smp]

(01-24-2019 04:28 PM)Benjer Wrote:  I'm having the same issue, as I mentioned earlier up above. Having used the calculator a lot since then, I have determined (like you) that the only common factor is that it occurs during or immediately after a key-press.

Like you, I've also tried various manners of rebooting/restarting, etc. I've taken to powering off/on frequently for the time being. I think the HP Prime is an excellent calculator otherwise so I'm very reluctant to give up on finding a solution.

Check out this thread:

http://www.hpmuseum.org/forum/thread-12210.html

Within it is a suggested list of actions to take which helped the OP.

I believe this is fixable for you. Good luck!

smp

[Benjer]

smp,

I believe I've tried these before, but for the sake of completeness I tried everything mentioned in that thread again.

Sometimes a day or two goes by before this error occurs, so I'll report back after some period of time.

Thanks for the suggestion.

[Benjer]

I don't know that anyone was keeping track or following along but just wanted to update since smp's post.

The issue hasn't resolved after applying the suggested fixes and while I can't be sure it's not just randomness at play, it seems to have increased in frequency as well.

In the meantime, shutting the calculator off immediately after performing an operation has now become the normal process to avoid losing data, although it will still sometimes reset on the first button-press.

[BBR]

No you're not alone, I'm still getting resets as well. We seem to be in the minority, however.

I tried all of those 'fixes' before I even posted the first time...I thought I had made that clear enough. At this point I wonder if it could be a hardware issue like a bad connection, capacitor, battery, pcb short, etc...

I'm still in the return window for about another week. It would be nice to know if this is a verified issue in the latest firmware or if we're just totally anomalies.

[DigiGal]

I'm bumping the old thread announcing the new version since starting a new thread didn't work for me.

I just picked up an HP Prime G2 Rev D:

Software Version: 2.0.0.13865 (2018 08 02)
Hardware Version: D
CAS Version: 1.4.9
Operating System: V2.060.650

Connectivity Kit Build: 2.1.14181 (2018 10 16) on Mac OS X 10.13.16 and have backed up my initial as shipped config using Conectivity Kit.

Checked for update and downloaded 20181016 but haven't installed it yet. Wanted to check with experienced Prime users if this is recommend since I'm seeing some reports of trouble after installing.

In addition to the current thread I found this page outside the forum in my search for answers...
https://www.hpcalc.org/details/7469

It seems there have been mixed results reported. I'm new to the HP Prime and the HP Prime is new picked it up at Best Buy 11/26/19 so it should be covered under warranty if the update bricks it.

Navigating HP's website today for their calculator info isn't a fun exercise. I don't know where to download HP Prime Virtual Calculator for Mac and PC. Are there trusted link(s) to have Mac version at home and PC version at work?

Should I risk installing the 20181016 on my HP Prime before proceeding further in learning this modern HP Calc?

[rprosperi]

The most reliable place to find official releases is here:

Index of http://ftp.ftp.hp.com/pub/calculators/Prime/

You can't use the link shown as the forum s/w mangles it and inserts what you see here; so just copy and paste the url into your address bar, and delete one of the leading "ftp." in front of hp.com.

That said, there is public Beta review going on now, you can find the thread (with links, etc.) in this same forum area.

As far as I know, that version (20181016 ) is the newest, most stable and with least bugs official release, however there are some small annoyances in this release (e.g. the ConnKit asks you to update it every time you start it - just say no).

You'll probably find more trouble posts about this release than any other, not because it is bad, but simply because it is in use by more people and has been the current version for the longest period, since the Prime was released.

[DigiGal]

Thank you, I couldn't get that ftp link for Virtual Prime(s) to work as suggested or any other variations of it.

I get the following message...

Forbidden
You don't have permission to access /pub/calculators/Prime/ on this server.


I did find the Mac version here https://www.hpcalc.org/details/7799 and installed it.

64 bit PC version found here https://www.hpcalc.org/details/8939

Installed the 20181016 update on my G2 Rev D and everything appears to be working.

Software Version: 2.1.14181 (2018 10 16)
Hardware Version: D
CAS Version: 1.4.9
Operating System: V2.060.650

Guess I'm all set to begin learning this new machine, it is quite a departure from the HP calculators I'm used to.

[Guenter Schink]

(12-01-2019 09:47 PM)rprosperi Wrote:  The most reliable place to find official releases is here:

Index of http://ftp.ftp.hp.com/pub/calculators/Prime/

You can't use the link shown as the forum s/w mangles it and inserts what you see here; so just copy and paste the url into your address bar, and delete one of the leading "ftp." in front of hp.com.

It's not enough - as you'll get the "forbidden" message. This link "ftp://ftp.hp.com/pub/calculators/Prime/" works.

Günter

[rprosperi]

(12-02-2019 09:32 PM)Guenter Schink Wrote:  

(12-01-2019 09:47 PM)rprosperi Wrote:  The most reliable place to find official releases is here:

Index of http://ftp.ftp.hp.com/pub/calculators/Prime/

You can't use the link shown as the forum s/w mangles it and inserts what you see here; so just copy and paste the url into your address bar, and delete one of the leading "ftp." in front of hp.com.

It's not enough - as you'll get the "forbidden" message. This link "ftp://ftp.hp.com/pub/calculators/Prime/" works.

Günter

Thanks Günter, I just saw that the forum s/w mangled my link. I've no idea why the forum s/w automatically creates links when I don't want it to, and won't do it automatically when I do want it to... But it seems you may have found the answer, by enclosing the ftp address in quotes. But you also are using unix style forward slashes, so not sure which is magic dust.

I'll try it here both ways to find out:

Using quotes:

"ftp:\\ftp.hp.com\pub\calculators\Prime"

Using forward slashes:

http://ftp.ftp.hp.com/pub/calculators/Prime <==== BAD Do not use this link

Note: Both lines above were typed-in using the exact same characters, except the lower line omits the quotes and uses forward slashes. Also, no links were inserted by me)

And so, the trick to prevent the forum s/w from inserting mangled links is to use quotes surrounding the url.

Thanks Günter!

[Guenter Schink]

(12-02-2019 09:58 PM)rprosperi Wrote:  Using quotes:

"ftp:\\ftp.hp.com\pub\calculators\Prime"

Using forward slashes:

http://ftp.ftp.hp.com/pub/calculators/Prime <==== BAD Do not use this link

Note: Both lines above were typed-in using the exact same characters, except the lower line omits the quotes and uses forward slashes. Also, no links were inserted by me)

And so, the trick to prevent the forum s/w from inserting mangled links is to use quotes surrounding the url.

Thanks Günter!

You aren't limited to quotes

<ftp://ftp.hp.com/pub/calculators/Prime
[ftp://ftp.hp.com/pub/calculators/Prime
{ftp://ftp.hp.com/pub/calculators/Prime
-ftp://ftp.hp.com/pub/calculators/Prime
:ftp://ftp.hp.com/pub/calculators/Prime
'ftp://ftp.hp.com/pub/calculators/Prime
#ftp://ftp.hp.com/pub/calculators/Prime
,ftp://ftp.hp.com/pub/calculators/Prime
.ftp://ftp.hp.com/pub/calculators/Prime
fake-ftp://ftp.hp.com/pub/calculators/Prime

a lot of delimeters are useable, and slash or backslash obviously doesn't matter. It seems that it's only necessary to invalidate the format of the internet address.

Günter

[rprosperi]

(12-02-2019 10:26 PM)Guenter Schink Wrote:  You aren't limited to quotes

<ftp://ftp.hp.com/pub/calculators/Prime
[ftp://ftp.hp.com/pub/calculators/Prime
{ftp://ftp.hp.com/pub/calculators/Prime
-ftp://ftp.hp.com/pub/calculators/Prime
:ftp://ftp.hp.com/pub/calculators/Prime
'ftp://ftp.hp.com/pub/calculators/Prime
#ftp://ftp.hp.com/pub/calculators/Prime
,ftp://ftp.hp.com/pub/calculators/Prime
.ftp://ftp.hp.com/pub/calculators/Prime
fake-ftp://ftp.hp.com/pub/calculators/Prime

a lot of delimeters are useable, and slash or backslash obviously doesn't matter. It seems that it's only necessary to invalidate the format of the internet address.

Günter

Very good, thanks for experimenting and sharing. After so long, it turns out to be so easy...

[Eric Rechlin]

(12-27-2018 03:56 AM)Jacob Wall Wrote:  

(12-27-2018 02:11 AM)Spybot Wrote:  Hello!
I just realized my program SLK 4.1b (http://www.hpmuseum.org/forum/thread-3861.html) got broken when trying to run it on Firmware 14181. I don't understand why it used to work fine on FW 13865 and now returns variables names instead of numbers as a result.

I Just wanted to let you guys know this.

Thank you.

I had a quick look at your code, and I'm surprised it worked before since I always assumed that concatenating strings required all objects to be strings.

Instead of this

Code:

PRINT("
  Vertical line!
  The distance between these 
  Points is: "+r+"
");

Convert variable 'r' to a string like

Code:

PRINT("
  Vertical line!
  The distance between these 
  Points is: "+STRING(r)+"
");

You can look at the help for the STRING command for formatting options that are available.

I looked into this, and the lack of STRING isn't the issue at all. I added the call to STRING as you suggested, and it had no effect. This is only a problem with the "r" variable here; substitute for any other variable that's defined here (like a, b, c, d, etc)

I am not sure why his code doesn't work with current ROM versions, but I think it might be related to the way he wrote this:

Code:


r:=approx(r);
F:=fp(r);
r:=exact(r);

It seems r has somehow become the literal "r" here and not the contents of what was in r.

Unfortunately, my knowledge of HPPL isn't good enough to figure this out. Maybe someone else knows better.

[Jacob Wall]

(04-12-2020 09:37 PM)Eric Rechlin Wrote:  I looked into this, and the lack of STRING isn't the issue at all. I added the call to STRING as you suggested, and it had no effect. This is only a problem with the "r" variable here; substitute for any other variable that's defined here (like a, b, c, d, etc)

I am not sure why his code doesn't work with current ROM versions, but I think it might be related to the way he wrote this:

Code:


r:=approx(r);
F:=fp(r);
r:=exact(r);

It seems r has somehow become the literal "r" here and not the contents of what was in r.

Unfortunately, my knowledge of HPPL isn't good enough to figure this out. Maybe someone else knows better.

You're correct, it has nothing to do with the lack of STRING, I remember being surprised that it worked, however it was my lack of understanding at the time of object types in PPL.

I looked at this again now, and the issue is the use of IFERR when combined with CAS commands. Take this example:

Code:

EXPORT slk3()
BEGIN
  LOCAL a:=0,b:=0,c:=0,d:=0,r:=0;
  LOCAL OP3:=0,F:=0,Z22:=0;
  PRINT();
  INPUT({{a,[0],{10,20,1}},{b,[0],{40,20,1}},{c,[0],{10,20,2}},{d,[0],{40,20,2}}},"Distance Between 2 Points",{"X₁:","Y₁:","X₂:","Y₂:"},{"Enter a Value for X₁ (Any Real Number).","Enter a Value for Y₁ (Any Real Number).","Enter a Value for X₂ (Any Real Number).","Enter a Value for Y₂ (Any Real Number)."});
  IF 0 THEN BREAK;
  END;
  // IFERR 3/0 THEN END;
  r:=√((c-a)^2+(d-b)^2);
  MSGBOX(r);
  r:=approx(r);
  MSGBOX(r);
  F:=fp(r);
  r:=exact(r);
  MSGBOX(r);
END;

Run it as is and should show the distance in each of the three MSGBOX instances, then un-comment the line with IFERR which has a divide by zero error on purpose. I think the first time running with that line un-commented will still work, but then something happens and the next run and you'll see just 'r' in the second and third MSGBOX, which follow the CAS commands.

If no errors get triggered by IFERR, then everything should be just fine. My workaround for this was to just write my own PPL commands to substitute for the CAS commands I was using, there was no other solution that I found because the IFERR in my case was to catch a ON key press.

Related topic https://www.hpmuseum.org/forum/thread-10995.html

[Eric Rechlin]

(04-13-2020 12:55 AM)Jacob Wall Wrote:  I looked at this again now, and the issue is the use of IFERR when combined with CAS commands. Take this example:

Code:

EXPORT slk3()
BEGIN
  LOCAL a:=0,b:=0,c:=0,d:=0,r:=0;
  LOCAL OP3:=0,F:=0,Z22:=0;
  PRINT();
  INPUT({{a,[0],{10,20,1}},{b,[0],{40,20,1}},{c,[0],{10,20,2}},{d,[0],{40,20,2}}},"Distance Between 2 Points",{"X₁:","Y₁:","X₂:","Y₂:"},{"Enter a Value for X₁ (Any Real Number).","Enter a Value for Y₁ (Any Real Number).","Enter a Value for X₂ (Any Real Number).","Enter a Value for Y₂ (Any Real Number)."});
  IF 0 THEN BREAK;
  END;
  // IFERR 3/0 THEN END;
  r:=√((c-a)^2+(d-b)^2);
  MSGBOX(r);
  r:=approx(r);
  MSGBOX(r);
  F:=fp(r);
  r:=exact(r);
  MSGBOX(r);
END;

Run it as is and should show the distance in each of the three MSGBOX instances, then un-comment the line with IFERR which has a divide by zero error on purpose. I think the first time running with that line un-commented will still work, but then something happens and the next run and you'll see just 'r' in the second and third MSGBOX, which follow the CAS commands.

If no errors get triggered by IFERR, then everything should be just fine. My workaround for this was to just write my own PPL commands to substitute for the CAS commands I was using, there was no other solution that I found because the IFERR in my case was to catch a ON key press.

Related topic https://www.hpmuseum.org/forum/thread-10995.html

Thanks for looking into it. I wonder if maybe there was a bug introduced into HP-PPL that is causing this? I'm testing with the 2020-01-16 release so the behavior remains the same now as it was when this issue was first noticed after the 2018-10-16 release. It doesn't make sense to me that the IFERR processing would "corrupt" the unrelated variable like that.

[CyberAngel]

(04-13-2020 12:55 AM)Jacob Wall Wrote:  

(04-12-2020 09:37 PM)Eric Rechlin Wrote:  I looked into this, and the lack of STRING isn't the issue at all. I added the call to STRING as you suggested, and it had no effect. This is only a problem with the "r" variable here; substitute for any other variable that's defined here (like a, b, c, d, etc)

I am not sure why his code doesn't work with current ROM versions, but I think it might be related to the way he wrote this:

Code:


r:=approx(r);
F:=fp(r);
r:=exact(r);

It seems r has somehow become the literal "r" here and not the contents of what was in r.

Unfortunately, my knowledge of HPPL isn't good enough to figure this out. Maybe someone else knows better.

You're correct, it has nothing to do with the lack of STRING, I remember being surprised that it worked, however it was my lack of understanding at the time of object types in PPL.

I looked at this again now, and the issue is the use of IFERR when combined with CAS commands. Take this example:

Code:

EXPORT slk3()
BEGIN
  LOCAL a:=0,b:=0,c:=0,d:=0,r:=0;
  LOCAL OP3:=0,F:=0,Z22:=0;
  PRINT();
  INPUT({{a,[0],{10,20,1}},{b,[0],{40,20,1}},{c,[0],{10,20,2}},{d,[0],{40,20,2}}},"Distance Between 2 Points",{"X₁:","Y₁:","X₂:","Y₂:"},{"Enter a Value for X₁ (Any Real Number).","Enter a Value for Y₁ (Any Real Number).","Enter a Value for X₂ (Any Real Number).","Enter a Value for Y₂ (Any Real Number)."});
  IF 0 THEN BREAK;
  END;
  // IFERR 3/0 THEN END;
  r:=√((c-a)^2+(d-b)^2);
  MSGBOX(r);
  r:=approx(r);
  MSGBOX(r);
  F:=fp(r);
  r:=exact(r);
  MSGBOX(r);
END;

Run it as is and should show the distance in each of the three MSGBOX instances, then un-comment the line with IFERR which has a divide by zero error on purpose. I think the first time running with that line un-commented will still work, but then something happens and the next run and you'll see just 'r' in the second and third MSGBOX, which follow the CAS commands.

If no errors get triggered by IFERR, then everything should be just fine. My workaround for this was to just write my own PPL commands to substitute for the CAS commands I was using, there was no other solution that I found because the IFERR in my case was to catch a ON key press.

Related topic https://www.hpmuseum.org/forum/thread-10995.html

Why would you override the reserved system variable F?
LOCAL OP3:=0,F:=0,Z22:=0;
- -
VPN

[toml_12953]

(12-02-2019 09:32 PM)Guenter Schink Wrote:  

(12-01-2019 09:47 PM)rprosperi Wrote:  The most reliable place to find official releases is here:

Index of http://ftp.ftp.hp.com/pub/calculators/Prime/

You can't use the link shown as the forum s/w mangles it and inserts what you see here; so just copy and paste the url into your address bar, and delete one of the leading "ftp." in front of hp.com.

It's not enough - as you'll get the "forbidden" message. This link "ftp://ftp.hp.com/pub/calculators/Prime/" works.

Günter

When I use the link icon, it gives me the link below which does work. I use Microsoft Edge and Google Chrome. Both of those give good links.

ftp://ftp.hp.com/pub/calculators/Prime/

[Guenter Schink]

(04-13-2020 11:59 AM)toml_12953 Wrote:  

(12-02-2019 09:32 PM)Guenter Schink Wrote:  It's not enough - as you'll get the "forbidden" message. This link "ftp://ftp.hp.com/pub/calculators/Prime/" works.

Günter

When I use the link icon, it gives me the link below which does work. I use Microsoft Edge and Google Chrome. Both of those give good links.

ftp://ftp.hp.com/pub/calculators/Prime/

Yes the forum software has been rectified in between

Günter

[Jacob Wall]

(04-13-2020 05:02 AM)CyberAngel Wrote:  Why would you override the reserved system variable F?
LOCAL OP3:=0,F:=0,Z22:=0;
- -
VPN

Although not my program code, take note that F here is LOCAL, and as per Cyrille's explanation here https://www.hpmuseum.org/forum/thread-14577.html

Quote:Symbols can be in LOTS of places in the system (see order of resolution)...

1) Local variables (CAS or PPL). Note that when calling the CAS from PPL, all the current PPL Local variables are accessible from the CAS (normally)
2) Current Program globals (variables declared out of the scope of functions)
3) App variables (AVars)
4) App build in variables (Xmax, Xmin...)
5) Other programs globals (exported, or not if fully qualified)...
6) Other apps globals (AVars and build in)...
7) Home and CAS global variables (including home build in: A-Z, Z0-Z9 + HVars)

Home and CAS global variables are last in order of resolution, so LOCAL F is totally valid inside a program and will not in any way affect the built in global variable.