Help needed NOW (real time) - stuck in a loop



#2

URGENT - IMMED. HELP NEEDED IN REAL TIME.

Please see the "Unrecoverable crash to lock-up" thread, which I started a few days ago.

That problem went unsolved. This is a continuation but with a new clue and a great deal more urgency. I have keyed in the whole 473-line program a THIRD time to test a third time. Made some tiny changes (see below). I am now, repeat NOW (as I type this) stuck in a loop which I cannot get out of and I need immediate, repeat, IMMEDIATE help.

I've tried:
C
R/S
C+R/S
C+GTO
C+R/S+i

Nothing will break the loop.

WHAT I CHANGED (not important)
(see "Unrecoverable crash to lock-up" for a listing)

I changed line
323 RCL L
to
323 RCL Q
324 x<>L

Then I inserted, after the old-numbered
329 XEQ B020

(new numbers)
333 COMP BARS
334 PSE

I am now stuck in a loop that keeps displaying
COMP BARS (0.5 seconds)...RUNNING (2.5 seconds)...
COMP BARS (0.5 seconds)...RUNNING (2.5 seconds)...
COMP BARS (0.5 seconds)...RUNNING (2.5 seconds)...
COMP BARS (0.5 seconds)...RUNNING (2.5 seconds)...
COMP BARS (0.5 seconds)...RUNNING (2.5 seconds)...
COMP BARS (0.5 seconds)...RUNNING (2.5 seconds)...etc...

I can wait maybe another two hours hoping for
someone to help me breal the loop, but then
I',ll have to poke the back and lose all my hours of work
(A-G-A-I-N).

Help please someone!


#3

I got no help from HP last time. THey just fobbed me off with platitudes then ignored me.

I've just sent the following message to them:

From John@Wasilewski.co.uk to the HP helpdesk at
http://wwemail.support.hp.com/fd2/EmailSend .

The HP35s scient.calculator becomes stuck in a loop which I cannot break out of. I've tried C R/S, C+R/S, C+GTO, C+GTO+i, (from the manual) and none of these works. I have now lost all of my work THREE TIMES by having to use pin-reset, which clears everything from memory. I've lost three programs, one of which was 473-lines long, which I am now facing having to key in for a fourth time before I can debug it. TELL ME HOW TO BREAK OUT OF A LOOP WITHOUT LOSING ALL MY CONSIDERABLE AMOUNT OF WORK! Please don't reject my request with an unhelpful comment and then just ignore me this time.

-----

John@Wasilewski.co.uk

#4

The calculator is the HP35s scientiic.


#5

I can't even turn it OFF unless I take both batteries out or push a pin in the back. I am just SO FED UP with all this work going down the drain on this machine. -- John


#6

John,

I feel your pain but unfortunately can not offer any suggestions for recovery that you haven't already tried. I've had such bad experiences with this machine that I've put it in my display case never to be used again.

I've read through your code and think that you can save considerable space by making use of STO and RCL arithmetic and other coding shortcuts such as user flags. I'll bet that with a little bit of work this application can fit on a 32SII and I'm sure it can fit on a 33S.

-Katie


#7

Thanks Katie. I appreciate your commiserations and I'll look at your suggestions if I ever get any further with this wretched problem. I have been using some STO and RCL arithmentic but if you think I have missed a few such optimisations I will look out for them. John


#8

All done.  
I have lost all my work AGAIN.
I tried the pin-in-the-back for a split second.
Memory cleared.

I have since experimented with short programs with loops, counters and PSE instructions. I can get it stuck in a loop of course but I cannot put it into a loop from which it it is impossible to break out.

I can only deduce that the problem with my 473-line program is that the locked-in-a-loop behaviour has something to do with,
- length of the program,
- flag settings,
- internal delays when searching for loop destinations,
- or something like that.

I wondered if it was cause by the SF 5 statement in my program but, from a simple test, it doesn't seem to be that.


#9

Hi John,

I really think you need to buy a 50G and get on with it.

If you really need to use "obsolete" programming paradigms, the 33s is just as new as the 35s, and it is less expensive, and the bugs are worked out. Just a thought.

#10

Hi Katie, all;

Please, Katie, forgive me if I am asking a silly question. I'm following (for as long as I can) some threads about the HP35S, and it seems to me HP lost the calculators' "mother of the recipes". My question is related to the second part of your sentence I partially quoted in the subject, i.e., it seems you gave the HP35S up. Appart of the (bad) experiences posted here, are there any others you can add to these so we can be aware of them? I'm willing to collect all of the information related to the HP35S here, but I'd like to know what is going to be missed.

Yeap, I have one, now!

Thak you and forgive me again.

Luiz (Brazil)

Edited: 9 Oct 2007, 6:02 p.m.


#11

As a straight calculator and equation solver it certainly seems very nice. The buttons work well, the display is fairly good, two lines is a great thing, there is no fear of running out of memory, and the equation list editing is a huge improvement over the 32sii and 33s.

It seems to me from listening to the problems reported by others that the worst of them are related to new features (vectors, non-decimal math, etc), and second to "assembly-like" line programming (RPN or ALG) rather than with basic features.

I haven't had any crashes or lockups with it myself. I haven't pushed it hard though. I've been too busy these past few months (in a good way though!).

Edited: 9 Oct 2007, 9:35 p.m.

#12

Hi, Katie:

Kastie posted:

"I've had such bad experiences with this
machine that I've put it in my display case never to be used again."

    On the other hand, I've used mine very extensively, writing all kinds of complicated programs using very long equations, vectors, complex values and whatever, all of it very experimental, some of them running unattended for up to 24 hours in a row, in search of weird programming tricks, and not even once have I experienced any abnormal behavior, crash, unbreakable loop, or even the infamous problem with vectors. Not-even-once.

    The only 'weird' things I've encountered were some unexpected side effects while doing bizarre things with equations, but they were fully explainable once you studied what happened and within working parameters, no bugs at all, just 'unexpected' (I'll comment on them in a future Datafile article).

    So I'm pretty amazed at the negative experiences other people seem to have with this machine, yourself included. You say you'll never use yours again, Vincze (remember him ?) said that he had destroyed his HP35s by throwing it against the nearest wall, etc, etc.

    Perhaps it depends on the production batch ? Certainly mine works flawlessly despite the many nasty tricks I've tried on it, and it's grown on me as a pretty solid, reliable machine with a very good keyboard and excellent ergonomics (e.g., it doesn't slip when placed on a table, it firmly sticks to it no matter how hard you press the keys).

Best regards from V.


#13

Hi Valentin; (say Laura ´Hello´ for me to, please!)

Quote:
Vincze (remember him ?) said that he had destroyed his HP35s by throwing it against the nearest wall
I missed that. When did it happen? Did he mention it in a thread or was it after private e-mails? I hope John Wasilewski does not follow this idea... I am curious because I am giving an HP35S a try for a couple of days and I can follow your own view about it, Valentin: no complaints so far.

Best regards.

Luiz (Brazil)


#14

Hi, Luiz:

Luiz posted:

"I missed that. When did it happen? Did he mention it in a thread or was it after private e-mails ?"

    He mentioned that much in a thread here in the Forum, a few weeks ago, at a time he was posting assiduously. Funnily enough, if I remember correctly, his HP35s wasn't misbehaving at all, it was just that he couldn't grasp how to do something simple on his own (polar/rectangular conversions or something like that) and he stamped the poor thing against the wall and proudly told us, at a time where most everyone else was drooling at the mere thought of getting to own one. That's Vinzce for you ! :-)


"I hope John Wasilewski does not follow this idea..."

    Oh but he would actually be entitled to do it, considering his extreme trials and tribulations. Though the machine itself is not the only one to blame in this case, methinks.

"I am curious because I am giving an HP35S a try for a couple of days and I can follow your own view about it, Valentin: no complaints so far"

    Nope, no complaints at all, exactly the opposite: I am delighted with it, and though I can recognize its many flaws and shortcomings, none of them have manifested themselves as bugs or unusability as far as I'm concerned.

    And for one whose first HP was an HP-25C,then an HP-67, etc, this machine is, as we say in Spain, "como para darse con un canto en los dientes" which roughly means: recognize the good you have and be grateful for it instead of unnecessarily complaining.

Best regards from V.


#15

Hello my old friend Valentin, I am one of those with a HP25C and I am not complaining about the HP35s either (because I do not have one), but to consider John's lost of a four hundred plus program lines of "unnecessarily complaining" would be like that Spanish saying I heard: "casi nada lo del ojo y lo tenia en la mano" (what happened to his eye was nothing to worry about and he had it in his hand).

It seems to me that for a machine that has no way of backing up a program/data it is even more critical to be full proof in its operation (i.e. not locking up and loosing everything you painstakingly just entered ONE finger key stroke after another). You indicate yours works fine, have you tried running John's program?

Regards, Thor


Edited: 10 Oct 2007, 2:56 a.m.


#16

Hi, Thor !

Thor posted:

"[...] to consider John's lost of a four hundred plus program lines of "unnecessarily complaining" would be like that Spanish saying I heard: "casi nada lo del ojo y lo tenia en la mano"

    LOL ! You've quoted it perfectly, and it's very funny and appropriate in most cases !

    But not here. I've noticed that oftentimes my posts are misunderstood and people tend to read meanings vastly different from what I actually had in mind at the time of writing. I'm sure most of the blame is mine because I tend to use exceedingly terse language at times, mostly when it's 3:00 AM or so, I'm absolutely tired, and further I'm writing in near darkness so as not to disturb anyone's sleep.

    In this case, the "unnecessarily complaining" actually referred to me (!) because after using the HP35s for a month there were some times when I would "swear in Aramaic" because Sqrt(x) wouldn't work on complex numbers (so forcing me to change an elegant program to something less elegant), then x^2 also refused to square a complex number, there was no elegant/fast/accurate way of retrieving the parts of a complex number of vector, some side effects that should work didn't, etc, etc.

    I was complaining all the time, to myself, to my wife, to everyone in a radius of 5 meters or so. Until then, at some moment, I had an epiphany and remembered when I was oh so much happy with my 49-step HP-25 without subroutines and losing everything every time I turned it off. Then I decided the HP 35s is an incredible machine, very capable, very solid, an HP will probably earn very little from it, if at all. It's the work of love of Cyrille and a few other 'lunatic' HP calc fans.

    Thus I stopped my "unnecessary complaining" for good. Now you see what I meant.

"It seems to me that for a machine that has no way of backing up a program/data it is even more critical to be full proof in its operation (i.e. not locking up and loosing
everything you painstakingly just entered ONE finger key stroke after another)."

    Absolutely true. However, I'm convinced it is a miracle in itself that we have such a machine as the HP35s, because it doesn't make any business sense for HP and I can't imagine just how many doors Cyrille and other such people have knocked to the point of wearing them down in order to get it done, at the lowest possible cost.

    I guess that ensuring "version 1.0" is nearly bugless before bringing it to the market was simply economically impossible, so it probably was a choice to either market it right away and let people be "acting guinea pigs" to help iron out the worst bugs, or else not releasing it ever, period. So I won't complain.

"You indicate yours works fine, have you tried running John's program ?"

    No, sorry. I just don't have the time required to do it, I've been finishing my two latest articles for Datafile and had to go to sleep at 5:00 AM on two consecutive days (and then going out to work at 7:00 AM) simply to meet the October 6th deadline. No time for anything else.
Thanks for your friendly comments and

Best regards from V.

#17

I cannot leave one of Valentin's comments unanswered.

Valentin, you wrote,

Though the machine itself is not the only one to blame in this case, methinks.

I do not for a minute think you intended to cause offence but
it is difficult not to feel a little hurt by this comment.

How exactly do you suppose that I and my program might be
partially to blame? Yes, no doubt, the program has bugs.
Yes, no doubt, it is my fault that it is stuck in a loop.
This is what debugging is for. But how could it be partly
my fault that the calculator refuses to break out of the
loop unless I do a hard reset and clear all memory?
---
John


#18

Hi, John:

John posted:

    "I cannot leave one of Valentin's comments unanswered."

      Good. Thanks for your dedication.


    "Valentin, you wrote: "Though the machine itself is not the only one to blame in this case, methinks." I do not for a minute think you intended to cause offence but
    it is difficult not to feel a little hurt by this comment.

    How exactly do you suppose that I and my program might be
    partially to blame?
    Yes, no doubt, the program has bugs.
    Yes, no doubt, it is my fault that it is stuck in a loop.
    This is what debugging is for. But how could it be partly
    my fault that the calculator refuses to break out of the
    loop unless I do a hard reset and clear all memory?"

      Please quote exactly where in my post do I ever mention that you or your program are partially to blame. Then we can discuss the matter.

      In the meantime, while expecting your quoting, let me give you a piece of advice or two for free:

      • To successfully deal in any kind of Internet forum, you've got to have or quickly develop a hard skin and also reduce your sensitivity to the environment lest you'll frequently get bruised and hurt.

      • To successfully deal in any kind of Internet forum, you've got to develop a clear understanding of what you're reading and what it really means, not what your heightened sensitivity thinks it means lest you erroneously feel attacked and threatened and victimized when you weren't actually mentioned at all.

      Just for the record, my sentence you did quote, namely "Though the machine itself is not the only one to blame in this case, methinks"
      was indirectly addressing current HP's poor customer attention and the way in which they ignored you and your problem.

      If the machine is buggy, the machine is certainly to blame, but that was enormously alleviated in the past when you would call HP's service and they would acknowledge the problem, research into it, suggest some workaround if at all possible, and even recall whole batches replacing them with new machines or ROMs free of charge !

      As you have experienced in your own flesh, that's not exactly the case right now, that's why I think that an enormous part of the blame goes to HP's piss-poor service, not only to the underpaid, overworked people who manufactured it.

      Hope that makes it crystal clear for you. And please, next time do not put in my mouth or pen comments I haven't uttered or written.

    Best of lucks with your sad affair and
Best regards from V.
#19

I think there might been some fixing or some bad batches... Because I would be very supprised if I gave you *mine*, and you did the type of stuff you said you do and did not start to experience some problems after some (short) time...

For example have you written and edited a program using vector in *equations* and *not* got in to problems? You would on mine...


#20

Quote:
For example have you written and edited a program using vector in *equations* and *not* got in to problems? You would on mine...

I have without problems. See the game I posted a while back.

My experiences with the 35s are similar to Valentin's. No problems yet and not for want of trying. I've not run it out of memory which might have something to do with my good fortune.


- Pauli


#21

Ok, there are buggy machines out there then! HP should replace us that been unlucky...

#22

Hi again, Arne:

Arne posted:

"For example have you written and edited a program using vector in *equations* and *not* got in to problems?"

    Yes, many times. Matter of fact one of my HP35S articles to appear in the very next issue of Datafile, which will be released within a week or so, does include vectors in very long equations, both of the constant type and of the dynamic, components-computed-on-the-fly-with-tons-of-side-effects type, and I've edited them equations and run the program any number of times, even calling it as subroutines in loops, with not even the slightest trace of a problem.

    I'm convinced this is either sheer luck, or much more probably, a different batch.

Best regards from V.
#23

Luiz and V-

Perhaps it's the way I press the keys on the 35s, but I have missed keystrokes frequently -- pretty much every time I use it. This never happens to me on the 32Sii (my regular calculator form many years). I've also experienced the vector syntax error several times now and I'm really irked by uselessness of the ALL display mode and CHECKSUM function. These are my biggest complaints.

The larger memory is nice but the speed of the calculator (or rather lack of it) means that it's impractical to do anything on a large set of numbers. I think that the 32Sii has just the right balance of memory, speed and power consumption for a simple programmable calculator with no i/o.

BTW, I measured the power consumption on the 35s -- it sucks 4.5ma from each of the CR2032 cells when it's running, this is higher than the rated maximum continuous discharge and no doubt degrades the capacity of the cell. I'd estimate the run time battery life on the 35s to be around 20 hours. The 32Sii draws just 1ma when running with similar capacity cells (silver oxide 357). My guess is that it would run at least 4 times longer.

-Katie


#24

Quote:
BTW, I measured the power consumption on the 35s -- it sucks 4.5ma from each of the CR2032 cells when it's running, this is higher than the rated maximum continuous discharge and no doubt degrades the capacity of the cell. I'd estimate the run time battery life on the 35s to be around 20 hours. The 32Sii draws just 1ma when running with similar capacity cells (silver oxide 357). My guess is that it would run at least 4 times longer.

A 357 silver oxide cell is about 1/3 the capacity of a lithium manganese 2032 in watt-hours.

I have never seen a rated "maximum continuous discharge" figure for a 2032 cell. The maximum continuous current is effectively limited by the internal resistance (around 20ohms), but yes, the capacity changes based on load current

Dave.


#25

The CR2032 maximum discharge seems to be rated by at least a few manufacturers, for example:
Renata lists it as 3ma Sanyo as 4ma EEMB as 3ma.

Yes, the total watt-hours of a 357 cell is about .25W and a CR2032 is .63.

The 35s uses 2 cells (1.26Wh total) with a run-time consumption of .027 watts . The 32sii uses 3 cells (.75Wh total) with a run-time consumption of .0045 watts. So just on this basis the 32sii should run 3.5 times longer, but the excessive load on the CR2032 likely makes this factor even larger.

Edited: 10 Oct 2007, 5:17 a.m.


#26

Very interesting (really!), Katie.

Could you list all HP-models power consumption for calculators you own or you know about?

How do you measure such power consumption? (This could sound a silly question, but I'm a civil engineer who builds roads, so I've got no knowledge about electricity!)

-- Antonio


#27

You use an external power source with a ammeter in series with it. In the case of the 35s you need two such power sources and two meters since it draw powers from both cells and the cells are not in series. They're not in parallel either they've got some sort of circuit (which might be more than a couple of diodes) between the two cells.


#28

Quote:
You use an external power source with a ammeter in series with it. In the case of the 35s you need two such power sources and two meters since it draw powers from both cells and the cells are not in series. They're not in parallel either they've got some sort of circuit (which might be more than a couple of diodes) between the two cells.

What do you measure with just one or the other cell installed?

Dave.


#29

The calculator (at least mine) won't run with just one cell installed, it will retain memory however.


#30

Thanks, Katie.

Well, I own none of the tools you named (nonetheless, I guess it would be terribly hard for me to use them, even in case I owned them), so would you list here the power consumption for the models you measured?

I'd appreciate it very much.

I thank you in advance.

-- Antonio


#31

Antonio,

I haven't measured any other calculators current draw recently and don't have any records of the ones that I have. But I'll try to find some time and do that in the future. Are there any models in particular that you want to measure?

-Katie

#32

Hi.



I have just measured the power supply current of several models that I have.

Isb is the power supply current while power off.

Iidle is the power supply current after while power on.

Irun is measured while solving functionaly equal equations in the

actual application that calculate microstrip transmission line parameters.

Ta=26C
HP15C : Vbat =4.72V, Irun=1.2mA, Iidle= 27uA, Isb<0.1uA
HP42S : Vbat =4.70V, Irun=3.3mA, Iidle=380uA, Isb=8.9uA, (Note.32KB RAM)
HP32SII: Vbat =4.60V, Irun=1.0mA, Iidle=120uA, Isb<0.1uA
HP35S : VbatL=3.00V, Irun=4.5mA, Iidle= 28uA, Isb=10uA
: VbatR=3.01V, Irun=4.5mA, Iidle= 28uA, Isb=10uA

(I think the HP32SII is really fast with very low power consumption.)

Regards, Lyuka


Edited: 15 Oct 2007, 12:42 p.m.

#33

Quote:
The CR2032 maximum discharge seems to be rated by at least a few manufacturers, for example:
Renata lists it as 3ma Sanyo as 4ma EEMB as 3ma.

They are not absolute maximum figures, they are simply reference figures based on a 50% drop in usable capacity (due to the internal resistance). See Note 2 on the Sanyo datasheet which explains it.
There is no threshold value at which the usable capacity of the battery starts to decrease. It is a continuous (but non-linear) degradation in capacity from no load all the way up to a dead short.

So there is nothing wrong with using 2032 cells at 4mA, you just live with whatever capacity you get. If it was only 0.4mA, you get a different usable capacity again, and yet another one for 0.04mA etc. Until you approach the ideal "nominal capacity"

The extra consumption of the 35S over the 32S is disappointing, but not surprising. Much more careful engineering went into the 32S than the 35S. The 32S used a custom ASIC optimised for low power consumption, and all assembly language for a better performance/power ratio. And no doubt similar engineering went into the LCD and other aspects.

Dave.

#34

Hi again, Katie:

Katie posted:

"Perhaps it's the way I press the keys on the 35s, but I have missed keystrokes frequently -- pretty much every time I use it."

    This actually reinforces my feeling that there must be different batches some of which are defective as I've been using my HP 35s for at least 100 hours, interactively, and I haven't experienced even a single missing keystroke.

"BTW, I measured the power consumption on the 35s [...] I'd estimate the run time battery life on the 35s to be around 20 hours."

    See ? Another point were your experience and mine utterly differ. As I've said above, I guesstimate that I've been using mine interactively for some 100 hours, plus another 50 hours it's been running standalone (i.e., the whole night or the whole 24-hour day) and I'm still in the original set of batteries.

    Which is more, I got this machine secondhand and it came with signs of fairly heavy use and with batteries already installed in an unknown state of discharge. Guess what ? These batteries are still running perfectly fine after some 100+50 hours of my using it, give or take 20, plus an unknown number of hours they already had on them before I even turned it on for the first time.

    There MUST exist different batches, else your experiences and mine don't make sense when confronted.

Best regards from V.

#35

Hello Valentin and Katie,

I would find it very useful if you could post your respective serial numbers. Perhaps we can at least determine whether they were made during the same week, or at the same factory.

-Seth


#36

Hi, Seth:

    Your suggestion would indeed be the thing to do but most regrettably my HP 35S doesn't have a serial number.

Best regards from V.


#37

Quote:
Hi, Seth:

    Your suggestion would indeed be the thing to do but most regrettably my HP 35S doesn't have a serial number.

Best regards from V.


How many of those HP-35S calculators without serial numbers are there?

How can I get one?


#38

Quote:
How can I get one?

Most easily ;)
#39

Hi, Palmer:

    Sorry, the answer is the same for both questions: "no idea"

Best regards from V.


#40

Buenas noches, Valentin,

you wrote "no idea", but you must be kidding. A 35s without a serial number is obtained as easily as a labelless 35s. But you knew that...


#41

Hi, Walter:

Walter posted:

    "you wrote "no idea", but you must be kidding. A 35s without a serial number is obtained as easily as a labelless 35s."

      The story of my life: every time I'm kidding people think I'm dead serious, and every time I'm dead serious people think I'm kidding ... 8-P

      In this case I'm dead serious: my 35s doesn't have a serial number. It's not my fault, I didn't do anything, it was like that when I
      got here ! ...

Best regards from V.
#42

It could very well be that I have a defective one, it's serial number CNA 72500758, FYI.

As far as the current consumption is concerned perhaps my unit is bad as well, has anyone else reading this measured the current draw on theirs?

(I also have one late model 32sii -- the one with the horrible color scheme -- that has an excessive current draw but this is in the OFF state. It burns through the cells in 6 months of zero use.)


#43

Quote:
As far as the current consumption is concerned perhaps my unit is bad as well, has anyone else reading this measured the current draw on theirs?

I just measured the current draw in mine, which is one of the ones HP handed out at the conference a week and a half ago. The serial number is CNA 73400342.

I used my DVM in series with each of the batteries separately, so reading the current flow from just one cell at a time. This means the internal resistance of the battery (in this case, Panasonic CR 2032) helps limit the maximum current. I get essentially the SAME readings for each cell.

In the OFF state, the current draw is 11-12 microamps.

When turned ON, but doing no calculating, the current is between 26 and 31 microamps, with the peak reading occurring every one or two seconds. The fluctuations are very regular, and I assume they are related to some internal (housekeeping?) event which occurs regularly.

I do not have any programs stored in my calc, so I just pushed the square root button to see what happened to the current draw. I get peaks of more than one milliamp on my meter. The peaks are probably too short to properly register on the DVM, so that is the minimum current draw while performing calculations.

Katie - what were your "idle" currents? If they are the 3-4 mA you mentioned, then I, too, believe you have a defective unit. If they refer to program execution, then your and my measurements are probably consistent (i.e. my 1+ mA could well be a few mA to which the meter is too slow to respond).

If the current flow as a function of time is deemed to be of great interest, I might to be able to hook the whole thing up to a 'scope and watch the current flow on the millisecond time scale!


#44

That sounds more like it.
You have to be careful taking these measurements though, as low current ranges on DVM's can use high value series shunt resistors. Typically 1Kohm on the uA range, and 10ohms on the mA range.
So it's best to use the mA or A range, but you don't get good resolution of course, but good enough for ballpark figures.

A 2032 battery has about a 20 ohms internal resistance when fresh.

Dave.


#45

I was using the 3 mA range on a Radio Shack DVM, so I don't think I was seriously limiting the total current because of the shunt value. The calculator displayed and operated normally while I was reading the current. I still had three digit precision (readout to the nearest 0.001 mA, or 1 microamp), so I suspect accuracy is OK.

#46

The run-time current draw I measured was when running a tight loop program (LBL A -- GTO A). The off state and idle state currents I measured were similar to what you measured. What do you get run you run a tight loop?

Edited: 10 Oct 2007, 11:54 p.m.


#47

I had to go find my better clip leads before I could measure the current while the calculator was hard at work.

When in a tight loop (LBL A, SQRT, GOTO A), I measure 4.74 mA for each cell, measuring one at a time. (You said the cells aren't in series, but whatever circuit they have is remarkably good at producing the same current draw from either cell. I can't see any difference between the current from either cell when the calc is OFF, ON but not doing anything, or performing calculations.)

To assauge DaveJ concerns, I also did a bit of microamp current testing of my mid-grade Radio Shack DVM. I put 50k (45.8k actual), 100k (97.0k), and 470k (455k) resisters in series with a 1.5 V (1.576 V actual) D cell - after measuring the actual resistance and battery voltage with the same meter - and measured currents of 36, 18, and 5 microamp respectively with the meter on its 3 mA scale, which has a least significant digit of 1 microamp. Based on the actual resistance and battery voltage values, 34, 16, and 3.5 microamp would be expected. So, I think the values I reported earlier are accurate, except for a bias of about +2 microamps.


#48

Quote:
To assauge DaveJ concerns, I also did a bit of microamp current testing of my mid-grade Radio Shack DVM. I put 50k (45.8k actual), 100k (97.0k), and 470k (455k) resisters in series with a 1.5 V (1.576 V actual) D cell - after measuring the actual resistance and battery voltage with the same meter - and measured currents of 36, 18, and 5 microamp respectively with the meter on its 3 mA scale, which has a least significant digit of 1 microamp. Based on the actual resistance and battery voltage values, 34, 16, and 3.5 microamp would be expected. So, I think the values I reported earlier are accurate, except for a bias of about +2 microamps.

Sounds right.
That would mean your Radio Shack DVM has a fairly standard 1Kohm shunt resistor on the uA range. You can easily confirm that by sticking your + probe into the uA jack and measuring it direct while on the ohms range.

Dave.

#49

Perhaps a long shot, but what current range did you use?
If you used the 10A range then the resolution on a typical meter will only be 1mA and can fluctuate a few counts around that. Perhaps that could explain it?

I find it hard to believe there are "defective" batches. There isn't much that can go wrong with a calculator like this. You have the battery, micro with oscillator, some simple power circuitry, a keypad and an LCD.
And the microcontroller is almost certainly mask programed, so they aren't going to be changing the code all that often.

Very puzzling.

Dave.


#50

I've got a good meter, an HP 34401A, it's plenty accurate and agrees perfectly with my other good meter a Fluke 867B. I'm quite sure I have the right readings, but not at all sure if my calculator is defective or not.

#51

I too had excellent experience with this calculator. That is, until I tried debugging my long program. It then behaved appallingly. Refuses to let me debug. Rfuses to break out of a loop. Forces me to wipe the memory, losing all my work on this program and all other programs already keyed in and stored.

In the circumstances, knowing that it can suddenly turn nasty without reason, I dare not try to develop anything complex, long, or interesting on it.

John

#52

Quote:
... I've put it in my display case never to be used again.
...
-Katie


;) That's also what I did. And mine has a scratched display although I only cleaned it once to remove some "China-dirt" sticking on the brand new screen..

Edited: 10 Oct 2007, 4:49 a.m.

#53

Katie,

I agree, I'm a 15C, 42s fan. The first thing I did when I received my 35s was to key in -4 SQRT and you know the rest.

tm

#54

I powered up my 35s, pressed reset once for a split sec (hole in back) and did not lose anything but the contents of X. All programs are intact.

I wrote the following:

Z001 LBL Z
Z002 GTO Z001
Ran it and ON killed it.

I ran it again, pressed reset once for a split sec and lost all memory.

If you cannot kill it I think you will lose all your memory again.

I suggest that you prototype your application using Free42. You can write all the code in any editor and use txt2raw.pl to convert it for Free42 or EMU42. Once you have it all worked out, then key it into the 35s. It is not 100% the same RPN, but is close enough.


#55

Thanks Egan.  I have just tried each of these:

C
Blue-shift-C
Yell-shift-C
Blue-shift-C-GTO
Yell-shift-C-GTO
Blue-shift-C-R/S
Yell-shift-C-R/S
None of them worked. Sodding thing is still looping away.

If no-one else comes up with any ideas I might try your idea of a split-second pin in the back.

I also like very much your idea of using an emulator for the debugging. Pathetic state of affairs, isn't it?


#56

I only write large programs for devices that I have emulators for and that will take programs from text editors. E.g. 50g, 48GX, 71B, 41CX, and 42S. I prefer the first 4 because I can go from editor directly into emulator or device. The 42S requires manual input, but its not that bad since I can use editor/emulator to write/test.

The 42S RPN is similar to the 35s RPN. I'd use that. Google for Free42 and get txt2raw.pl as well. Life is too short to key in 400+ lines more than once.

#57

Hi John. Your trials and tribulations on the 35s sound frustrating. What's the s/n on your 35s?

Just a thought... have you tried removing the batteries, waiting a few minutes, reinserting the batteries and then resetting the 35s?

Here's a tip from educalc.net for resetting memory:

"The following procedure will total erase all the memory and program store in the HP 35s. Press the following three keys all at the same time - [C] [R / S] [i]. It correctly reset, it should show "MEMORY CLEAR" on HP35S display."

http://www.educalc.net/1207487.page

Good luck and regards,

John


#58

1.
SN = CNA 72100255

2.
Good idea about removing the batteries for a few secs.
I will try that.

3.
The "tip from educalc.net" is in the manual.
I tried it. It failed to break the loop.
---
John


#59

Hello John,

That is one of the lowest serial numbers I have ever seen! It almost certainly came from the first batch off the assembly line made for public purchase.

I will try out your program later today if I have time [I'm located in California, so my "today" is not the same as your "today" :) ]. I also have a calculator from the first week, SN CNA 72101944. If I have similar results, perhaps that would lend strength to the "different batches" theory. It wouldn't make it any less frustrating, of course.

#60

Hello!

Quote:
... I have keyed in the whole 473-line program a THIRD time to test a third time. ...

I am really a patient and quiet person, but I think in your position, what I would do (and with the greatest of pleasures and satisfaction!), is the following:

I would go to the garage and fetch my anvil. Then I would go to the garage again and fetch my largest hammer (and it is really large, I used it to drive the fenceposts in). This second walk to the garage is necessary, because anvil and hammer are to heavy to be carried together, at least for me. Then I would place the malfunctioning piece of equipment quitely and delicately on the anvil. I would quitely talk to it one more time and give it ten seconds to recover from its stalled condition. If it still dosen't want to listen, a very short while later I would be the proud owner of the world's thinnest pocket calculator :-)

Greetings, Max

NB: An alternative treatment is this one, that I applied to my first Ti30 when the keyboard went completely unusable: I removed the back cover. Then I plugged two cables into the 220V (as it was then, now we have 240V which works even better) wall outlet. Then I put on protective glasses. And only then, I connected one cable to one corner of the PCB and the other cable to the opposite corner.

Edited: 9 Oct 2007, 4:15 p.m.


#61

Excellent plan. I was thinking of using the HP35s as part of the packing in the anvil of a Delmag D40 diesel piling hammer. That is a something I think it would be really good for. It is always so rewarding to know that things can be put to good use...

#62

Quote:
NB: An alternative treatment is this one, that I applied to my first Ti30 when the keyboard went completely unusable: I removed the back cover. Then I plugged two cables into the 220V (as it was then, now we have 240V which works even better) wall outlet. Then I put on protective glasses. And only then, I connected one cable to one corner of the PCB and the other cable to the opposite corner.

LOL! You don't happen to have a video??? Maybe John W can make a video if he decides to flatten his 35S .


#63

Hello!

Quote:
LOL! You don't happen to have a video???

No, this was long before home video became affordable... I got the idea to finish the calculator in this manner when I tried to repair my psychedelic lights (anybody remember those?) with a grounded soldering iron while the unit was still connected to the mains. Somehow it is kind of a miracle that we all survived our teenage years, isn't it?

Greetings, Max

BTW: Instead of sending the calculator to the "Blender Man" mentioned elsewhere, one could also send it to the bikini girls here. They will give it its deserved treatment with much more style: http://www.bikinirama.de/img/user/Videos/BIKINIRAMA_iPhone_011_3224.mov


#64

Quote:
[...]mentioned elsewhere, one could also send it to the bikini girls here. They will give it its deserved treatment with much more style: http://www.bikinirama.de/img/user/Videos/BIKINIRAMA_iPhone_011_3224.mov

Style? It's just plain sexist.
#65

Ooooh ouch, that movie's really hardcore ;)) (Naja, mit der Schraubzwinge muss sie noch ein bisschen üben ;)

Thanks for sharing!

Edited: 10 Oct 2007, 3:27 a.m.

#66

As someone experienced with the wanton destruction of electronic equipment, I recommend applying the 240V, THEN the sledge hammer!



John


#67

the sad fact of history in the 21st century--if it ain't on youtube, it didn't happen ... [g]

/guy

#68

No, send it to This Guy
He will make a video and post, and then we can all see if the 35S can be blended!

Dave.

#69

HI, John;

I'm willing to enter the program you listed and run it. To do so, I want to know if you have a coulpe of executable examples with the expected results/behavior. Would that be possible? I'll also try to follow the listings and get the expressions/equations/formulas you had used.

In a previous post, you added:

Quote:
Probably-suitable date with which to test it are:

M=100,000,000

Y=460

F=35

C=40

H=360 (over-ride suggested value)

B=300 (over-ride suggested value)

Bar diameter = 20


Are these still valid data? In another thread you describe the following variables and their corresponding registers:
Quote:
A	Working storage register
B Breadth of beam
C Cover (assumed same top, bottom, sides)
D Effective depth (depth to centre of tens bars)
E ??? Previous weight of tens + comp bars ???
F fcu
G ??? Previous weight of tens + comp bars ???
H Depth of beam
I k1
J k2
K k3
L Prev comp bar size
M MR
N M carried on concrete
O Tens bar diameter d
P No of tens bars
Q Comp bar diameter d’
R No of comp bars
S Area of tens steel
T Area of comp steel
U Gm (steel) = 1.05
V Gm (concr) = 1.5
W
X Depth of neutral axis
Y fy
Z Lever arm tens bars to centre of conc comp

Later, you follow a more complete description with some values like:
Moment of resistance
M=40,000,000 (or maybe 100,000,000)kn-m
Steel characteristic strength f(y)
Y=460 N/mm2
and so. Any changes? Comments?

I'll take my two-days vacation time plus the weekend, and do some things I like the most, using calculators being one of them.

Best regards.

Luiz (Brazil)


#70

Luis,

The data you quote from my previous postings are fine.
Just be sure to over-ride the suggested section depth and
width with smaller values (which will make it necessary
to include conpression steel), but then enter tension steel
bar diameter only (leaving the program to decide on the
compression steel bar diameter).

Also, please email me with your email address so that
I can send you a properly formatted listing that has
correct characters and is much easier to read.

NB I hope you also saw my message yesterday in which I
described two small changes to the program before my
most recent debgging attempt, which showed that it was
stuck in a loop.

---
John


#71

I did type your program into my 35S. I ran it per your directions, and I have not had any problem with it. The serial number on mine is CNA 72600768 in case someone knows how to decode that and tell if ours are from a different batch. I've had no strange behavior with mine other than missing and 'ENTER' or a '0' a few times (but I tend to push those in rapid succession).


#72

Your serial number indicates that your 35s was made at Chinese Factory "A" [CNA], in 2007 [7], in the 26th week of the year [26], and that it was number 768 made during that week [00768].

As soon as I have some time, I will try keying in John's program on my calculator, which came out of one of the first baches (CNA 72101944).


#73

[pre]
I have submitted this to HP:

HP 32sII scientific calculator e-mail support

Please verify that all the information below is correct, and then at the bottom of this page click Send to send your e-mail, or click Back to make any changes.


Select a problem area.*
hardware

When did you purchase your product?*
Sep2007

What is your serial number (SN)?*
CNA 72100255

If there is an error message, please specify.
None

What is your model/product series number?
HP 35s Scientific calculator

Please provide the exact problem description.*

THIS IS NOT A REQUEST FOR HELP WITH MY PROGRAM.
It is a report of a disastrous hadware fault that prevents me from developing serious software and forces me to erase all of the work stored on the calculator every time it happens. In short, when a simple bug in my program puts the calculator in an endless loop, it refuses to accept any keyboard command to make it stop and let me find my error, and I am forced to erase all memory every time.

The HP35s scient.calculator sometimes becomes stuck in a loop which I cannot break out of. Ive tried C R/S, C+R/S, C+GTO, C+GTO+i, (from the manual) and none of these works. I have now lost all of my work THREE TIMES by having to use pin-reset, which clears everything from memory.

Ive lost three programs, one of which was 473-lines long, which I am now facing having to key in for a fourth time before I can debug it. The problem is that the calculator cannot be interrupted when stuck in a loop. This does not happen with all continuous loops but it does happen EVERY TIME with a particular piece of code. Result: impossible to debug a simple program and I lose ALL MY WORK since the beginning of time on the HP35s. Please dont reject my request with an unhelpful comment and then just ignore me.

THIS IS NOT A REQUEST FOR HELP WITH MY PROGRAM.

It is a report of a hadware fault - the calculator becomes uncontrollable unless I erase everything.

Please list previous troubleshooting steps, or information that can help HP assist you.

After having the calculator just hang for the first two times that I had to cold-reboot with the pin in teh back, I added some debug steps before trying again. Unfortunately, I used a PSE not a STOP statement, but this is why I know it is stuck in a loop. It just keeps displaying my PSE message for half a second then displaying "RUNNING" for 2.5 secs,
then repeating forever, whilst refusing to let me interrupt it.

From a user-group forum, I now know that my calculator, serial number CNA 72100255, is an early one. I have learned also that the same calculator from a later manufacturing batch does not display this errant behaviour. The serial number of the "good" calculator was CNA72600768. For more information please see http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=126072#126072

----
John Wasilewski
54 Yarnells Hill
North Hinksey
Oxford
OX2 9BE

Has anything changed since the unit functioned properly (installation of SW, settings, cabling, etc.).

Nothing.
Except that I have had my 10 Oct 2007 12:51 request for technical support on this (HP ref KMM20289652V17107L0KM) rejected by "Mike" of HPs "Total Care" at support-e@hpcalcs.com because I dont live in North America apparently.

Define your technical skill area:
advanced

first name*
John

last name*
Wasilewski

e-mail address*
John@Wasilewski.co.uk

confirm e-mail address*
John@Wasilewski.co.uk

phone number*
+44(0)77900891107

country/region*
United Kingdom

I agree to receive HP email messages including free support updates, newsletters, exclusive offers and more. yes

[/pre]


#74

No need to worry. The proper people will get your report.

What to do?

Return the calculator to get another by returning it to where you bought it from and exchange it for another.

#75

Mark, please explain.

Do you mean the program went wrong (as it should because it is still not correct) and became stuck in a loop because of my programming error(s), and that, most importantly, you were then able to break out of the endless loop? A more detailed report would be very helpful, especially after you went to such a great effort to type in so many lines of draft code

-- John --


#76

"Do you mean the program went wrong (as it should because it is still not correct)"

I don't know what your program does, I don't know if it generates a correct answer or not. I just typed it in, and when it seemed to not give a correct answer I re-read through the listing to be sure I made no mistakes.

"and became stuck in a loop because of my programming error(s), and that, most importantly, you were then able to break out of the endless loop?"

It's never got stuck in a loop.

" A more detailed report would be very helpful, especially after you went to such a great effort to type in so many lines of draft code"

Again, I don't know the problem your program is trying to solve, but it isn't locking up the calculator.


#77

Do you still have the code in the calculator, Mark?
If so, could you run this test for me?

Input is prompted with M=? etc except where shown
differently in the data below.

XEQ B
M=150,000,000 R/S
Y=460 R/S
F=36 R/S

At this point the program computes suggested
values of H and B then prompts for user input.

Please over-ride the suggested values by reducing
them by about 20% to 30%.

i.e.
H={put in about 70% to 80% of suggested value} R/S
D={put in about 70% to 80% of suggested value} R/S

Program will now prompt for "C,T BAR SIZES"
then stop waiting for input, without a "?" prompt.
It is asking for either a value in X and another in Y
or just a value in X

please choose the latter and enter only this:
20 R/S

Now watch.
The program should enter an endless loop because
of a mistake in my source code.

I need to know
1. If it DOES enter an endless loop,
2. Whether you can or cannot break the loop,
3. Your serial number.

That is all.

If you are able to run this test for me then
thanks in advance!
---
John

#78

Hi, John;

please, feel free sending me a MS Word-formatted copy of the lisiting:

lcdata [at] quantica (dot) com {dot} br

You will surelly know how to un-SPAM the e-address above, right?

About the small changes you suggested: yes, I read about them. But for the fact that the calculator locks up, these modifications may not actually change it, they will actually update L-register contents with current Q-register contents (step #323) and allow the message 'COMP BARS' to be shown when the program is computing their value (is that correct?). In fact, as far as I could check, nothing leads to a lock-up condition.

I had some spare moments to have a look at the program listings, and I checked a couple of routines that seemed fine:

B045 - returns ((beam depth)×(d-d')/2)-(2×cover)

B057 - (1 ± fy/(700×Gm))

B157 - Main program - computes K1, K2 and K3 (up tp B210)

Some things that called my attention:

B020 - it reads 'Get next bar size', but it has no valid code in this particulart step it.

Also, it seems to me something is missing in this particular routine. Consider that we have any valid numbers in X- and Y-register, like A (X) and B (Y). B021 compares them both (x>y?), and program execution may jump to step #B042 (true) or follow #B023 (false). If false, '10,00' is placed in X-register, the stack lifts and A is placed in the Y-register. Step #B024 compares 10 with A; again, program execution may jump to step #B042 (true) or follow #B026 (false). If false, '12,00' is placed in X-register, the stack lifts and '10,00' is placed in the Y-register. If this point is reached, program execution always jumps to #B042 (12 in X is greater than 10 in Y), whatever value is A, given that A>B, A<10, and the routine will return with '10,00' in the X-register.

Steps #B290 to #B294 also need attention. Please, follow:

290.	x>0?
291. GTO B292
292. 1
293. 1
294. +
Whatever you have in the X-register, being it zero or not, the sequence always returns 2 in the X-register.

A little improvement. Steps #B174 to #B176, you have:

174.	1	
175. 64.96875
176. ÷
It could be shortened in one step (and use one single stack register) with::
174.	64.96875	
175. 1/x
In fact, if you go further, the whole sequence (step #B174 to #B182) might be improved. From the original:
174.	1	
175. 64.96875
176. ÷
177. RCL F
178. RCL V
179. ÷
180. 1.5
181. yx
182. x
it could be:
174.	RCL F
175. RCL V
176. ÷
177. 1.5
178. yx
179. 64.96875
180. ÷
Just an improvement, does not change the result.

I'll keep investigating tonight, but I have not yet entered the program in the calculator. There is a program in memory I'm recording, but I guess I'll do it tonight.

Best regards.

Luiz (Brazil)

Edited: 10 Oct 2007, 5:52 p.m.


#79

Great to have your input Luiz. I've emailed teh code as an M$Word attachment. I'll look at optimising the code if and if ever I get the calculator to work. Your ideas will be most welcome.

Pls note I will be offline for a fw days.

IF ANYONE ELSE WANTS A COPY OF THE CODE PLEASE SEND IT TO THEM

---

John


#80

I too would like a copy of the program in MS Word format, if you are still online. If not, Luiz, would you be so kind as to send it to me? My address is sethm {at} loomcom {dot} com

Thank you!


#81

Hi, Seth;

you have mail...

Best regards.

Luiz (Brazil)

#82

Quote:
IF ANYONE ELSE WANTS A COPY OF THE CODE PLEASE SEND IT TO THEM
---
John

After typing the whole program into my HP35S (thanks, John, for the formatted listing), I can fully confirm John's frustrating experience.

NO WAY to stop the running cycle but the pin-reset which clears everything. I'll type my set of short functions back but I definitely won't try to use HP35S for any longer code - no time to risk a total loss of data/code with an unstable calc (with no I/O to backup). What a shame.

Maybe others don't have problems like this which would be very interesting to know - can more other users do the test and send their experience (and S/N)?

My S/N is CNA 72100299, only 44 items from John's calc, most likely the same production day. Bought in UK by mail delivery. If it proves to be only a problem of a specific batch, I would consider returning/replacing the calc, though for me (not living in UK), the costs and troubles related to postage etc. make the warranty rather unattractive.

The recent experience, at least for me, raises very strong doubts about the HP35S:

1. The calc is far from optimal for hand calculations (Shifted STO, ENTER needs to be pressed when invoking any programmed function, R/S badly positioned far from the 'centre', cumbersome use of indirect addressing in hand calculations and more issues discussed in other posts). Probably worse than HP33S for hand calcs.

2. Keyboard layout looks more suitable for programming, BUT NOT ALLOWING RELIABLE DEBUGGING OF A LONGER CODE!

Maybe too sceptical conclusion, but a large ENTER key and a retro look is not all that matters :-( Sorry.

VQ, Prague, Czech Rep.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Four-Level RPN and the Real World Matt Agajanian 14 2,420 12-13-2013, 03:57 PM
Last Post: Manolo Sobrino
  [HP Prime]How to get Discrete-Time Fourier Transform uklo 0 554 11-18-2013, 08:02 PM
Last Post: uklo
  "HexZombie - a tool for real programmers" Thomas Chrapkiewicz 8 1,127 11-16-2013, 12:46 AM
Last Post: Kiyoshi Akima
  Date/time formats R. Pienne 4 858 11-01-2013, 12:43 PM
Last Post: Marcus von Cube, Germany
  How to set the Date.Time etc on a WP34S Harold A Climer 4 805 10-29-2013, 09:32 PM
Last Post: FORTIN Pascal
  Prime: Exam mode (possible duplicate after funny response first time) Paul Townsend (UK) 1 521 10-24-2013, 03:09 PM
Last Post: Tim Wessman
  WP34s integration trapped in infinite loop Bernd Grubert 25 2,531 10-17-2013, 08:50 AM
Last Post: Dieter
  Unexpected problem with the real Prime Javier Goizueta 4 785 10-08-2013, 01:00 PM
Last Post: Marcus von Cube, Germany
  Date/time programs for the HP 35s R. Pienne 0 413 10-03-2013, 02:37 PM
Last Post: R. Pienne
  New community-maintained version of "Calculators benchmark: add loop" Pier Aiello 20 2,435 09-12-2013, 02:42 AM
Last Post: Pier Aiello

Forum Jump: