HP35s Stopping a program, help!

[Pablo P (Spain)]

I was developing a program to calculate preferred values of resistors. After typing the program I executed it as normal. The problem is that it has entered in a loop and I cannot stop it even pressing R/S.

I have a lot of programs in this calculator and I do not want to lose them doing a reset. ¿Any suggestions?

[Bart (UK)]

Unfortunately you may have to do a reset or pull the battries. In any event it is very likely to lead to "MEMORY CLEAR".

See the HP-35S bug list, number 16.

I have had this happen to me and now make sure I have typed copies of all my programs. It will still take many hours to re-enter them though.

Edited: 17 May 2010, 10:33 a.m.

[Gerson W. Barbosa]

I'm not sure the following will help. Anyway, here's the link:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=126772

[Bart (UK)]

Quote:

---

I'm not sure the following will help. Anyway, here's the link:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=126772

---

From the thread quoted by Gerson:

Quote:

---

The danger posed by the above, which is what happened to me, is that, if this aberrant behaviour occurs whilst test-running a program for debugging, and an error in the program code causes the processor to enter an endless loop, then you are completely stuffed. Nothing but nothing will interrupt it, short of paper-clip-resetting in the hole at the back, and this wipes all of the work, in all programs. Memory cleared.

---

This has been my experience. Sorry for the bad news.

[Maarten Ambaum (Reading, UK)]

Same here; thankfully this happened before I had too many programs in memory. I did lose a substantial equation list which was more annoying to me.

Surely this must be one of the most serious 35s bugs....

[Pablo P (Spain)]

"Bug number 16: Some programs cannot be interrupted."

Oh! Surprise! Now, I know this horrible bug. I had to reset the calculator and consequently I lost all my programs. I have a hard copy of them (except last programs) but due to the lack of I/O I have to type them again and so I will lose a lot of time.

The next time I will check all my programs before executing them but anyway I think that this bug makes this calculator very untrustworthy. This is unacceptable in a modern calculator. Do you agree?

If anyone is interested my hp35s is a recent model with CNA 850.....

_____

Pablo P. (electronic engineering student)

Edited: 17 May 2010, 8:05 p.m.

[bill platt]

Back to the HP 50G?

[Pablo P (Spain)]

Quote:

---

Back to the HP 50G?

---

Hi Bill, I know you warned me about the issues with this calculator but anyway I cannot use an HP 50G in tests. So, for now and despite problems, I will go on using this calculator. Probably in a future...

[bill platt]

Hi Pablo,

Ugh, that's right--tests!

Not really any alternates then.

[Martin Pinckney]

Quote:

---

This is unacceptable in a modern calculator. Do you agree?

---

I think nearly all will agree.

[Bart (UK)]

Quote:

---

I think nearly all will agree.

---

Nearly all?? Oh ,yes, except HP of course ;)

[Martin Pinckney]

Well, usually when there is a thread where folks are very vocal about how HP really shouldn't have released such and such model with such and such defects, or without such and such features, the discussion eventually degenerates into heated debates over development costs, production costs, testing methods, business practices, marketing strategies, etc., etc. So I did not want to speak for everyone.

Edited: 18 May 2010, 11:21 a.m.

[Bart (UK)]

Quote:

---

but due to the lack of I/O I have to type them again and so I will lose a lot of time.

---

Lack of I/O is another gripe for many users, but HP probably did this to make it acceptable for use in certain exams.

I spent several days re-typing in my programs (total ~15k).

Quote:

---

This is unacceptable in a modern calculator.

---

Yes, this bug list has been out for almost 3 years now, although some issues were added more recently. However, if HP had bothered to implement a fix say a year ago (when most issues including this one were known), it probably would be in the current units on sale. Even if they did not offer an update/exchange, I think that many would be willing to purchase a fixed unit.

-B

[bill platt]

I just thought of something stupid.

Better to have two 35s machines. You would test and debug programs on one machine--and then you can save that program on the other machine.

Or you just buy another machine every time you come up with another big program that might crash...seems to get expensive.......

[Pablo P (Spain)]

If I were a rich man,
Ya ha deedle deedle, bubba bubba deedle deedle dum.

Hehe, it is not a bad idea but it is cheaper to carefully review you program before running it...

[bill platt]

Hi Pablo,

You are probably a much better programmer than I ever was. When it comes to debugging, whether it is on an RPN classic, or Pascal, back in university, I always find out that I missed something...until I actually run it, I don't know for sure...this always seems to get me when there is logical branching. (The "do while true" versus "repeat..until" comes to mind...)

[Howard Owen]

Quote:

---

Hehe, it is not a bad idea but it is cheaper to carefully review you program before running it...

---

Assuming you are aware of the problem.

[Howard Owen]

Quote:

---

Better to have two 35s machines. You would test and debug programs on

---

How about zero 35s machines? There are other calculator vendors out there.

I never thought I'd see the day when I would recommend TI to anyone, but here it is. This bug is appalling. The worst thing an information device can do is lose data. In a machine that can't be backed up, the fault is unforgivable.

I don't blame the developer for the bug - bugs happen. I do question the QA that allowed this bug to slip through, but again, that's not unexpected. I blame HP for allowing that flaw to remain in current production models. I realize that HP's budget for the calculator business is thin. It must also be the case that this bug bites infrequently, or they never would have neglected it this long. But allowing such a fatal flaw to stay on a production machine over multiple years is a travesty. It shows the futility of trying to produce a quality calculator at HP, as Sam Kim tried to do. It saddens me because the 35s seemed to incorporate a lot of the values this community championed for years. But this bug gives the lie to all that. Data integrity is the first hurdle a machine must surmount in the race to quality. Unfortunately, HP stumbled out of the gate on that one.

Regards,
Howard