The Museum of HP Calculators

HP Forum Archive 17

[ Return to Index | Top of Index ]

Unrecoverable crash to lock-up
Message #1 Posted by John Wasilewski on 2 Oct 2007, 9:42 a.m.

Anyone seen this problem?
Any advice available?

Unrecoverable crash problem

Causing total loss of all previous software development work

In final tweak/adjust/debug stage, XEQuting a 473-line program caused the screen and keyboad to freeze. None of the keystroke combination reset procedures in the manual worked.

i.e. neither of the following freed the lock-up.
C + GTO
C + R/S + i

Consequences were very bad. I had to stick a pin in the back. I therefore lost not only this long program but also ALL other code I had entered for previous programs.

Hoping that this was just an unfortunate rare occurrence, I re-typed the entire 473-line program from notes I had kept. When I tried to XEQute it again to resume where I had left off, it worked partially as before and then at exactly the same place in the data entry, exactly the same problem happened again.

I'm therefore faced with having to type it all in yet again (that is, AT LEAST one more time, and probably more than one). Naturally, I'll try stepping through it next time, but when it crashes again, I will again be back to zero.

This is very exasperating and time-wasting.

It is also extremely discouraging. I had planned to build up gradually (and post to this site) a library of most-useful structural engineering code that would just lie in memory, preserved by always having a spare battery pair and replacing batteries carefully. This unrecoverable crash means I can expect to lose the lot. And that is a big big disincentive to software development on a system I can't trust, that has no possibility for external filesaves.

John Wasilewski
Civil engineer
Oxford and London

      
Re: Unrecoverable crash to lock-up
Message #2 Posted by Arne Halvorsen (Norway) on 2 Oct 2007, 10:07 a.m.,
in response to message #1 by John Wasilewski

And on what machine did this happen?

            
Re: Unrecoverable crash to lock-up
Message #3 Posted by randy on 2 Oct 2007, 11:52 a.m.,
in response to message #2 by Arne Halvorsen (Norway)

My semi-educated guess: 35S

And some wonder why others want still 41's, 67's and 97's. It's those blasted silly little magnetic cards... oops, forgot the 65.

IMO, the 35S is not a "system".

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

                  
Re: Unrecoverable crash to lock-up
Message #4 Posted by Arne Halvorsen (Norway) on 2 Oct 2007, 12:09 p.m.,
in response to message #3 by randy

Yep must be, checked the manual.

I wonder how much more expensive the bug would had been with the simplest form of I/O (USB or memory card) for program backup...

                  
Re: Unrecoverable crash to lock-up
Message #5 Posted by John Wasilewski on 2 Oct 2007, 1:07 p.m.,
in response to message #3 by randy

Good guess, Randy, it is a 35S.

Also, you may be right that I shouldn't refer to it as a 'system' and I'm grateful to you for the comment. Please note, however, that I posted the original message because I have a fairly major problem here, that I really do need some solid help with if I can possibly find it, so I hope everyone won't mind, and no-one will be offended, if I ask that we keep focused on the technical problem, and avoid side issues like this.

In particular,

1) Has anyone else had any similar experience?

2) Does anyone have any ideas of what type of code might cause it, so that I can search through my code to try to find MY bug?

3) Has anyone any ideas about how to force a non-destructive reset when the instructions in the manual don't succeed?

Be in no doubt, if this problem persists and we can't find out why then the HP35S, which is otherwise a superb calculator, becomes totally crippled for all serious users. You can't write serious programs on a "calculator-that-isn't-a-system" (!) if there is no save facility AND occasional crashes wipe all programming you have ever done.

I see this as very, very important.
---
John

            
Re: Unrecoverable crash to lock-up
Message #6 Posted by John Wasilewski on 2 Oct 2007, 12:50 p.m.,
in response to message #2 by Arne Halvorsen (Norway)

It happened/happens on an HP35s. Sorry I didn't make this clear - I forgot it was not a machine-specific section of the forum --- John

                  
Re: Unrecoverable crash to lock-up
Message #7 Posted by Patrick Rendulic on 2 Oct 2007, 1:01 p.m.,
in response to message #6 by John Wasilewski

Is it the HP35-scientific or the HP35-s*** ?

I may be very rude, but at this stage, the HP-35 cannot be trusted. There seem to be to many bugs or "undocumented features". Maybe most problems will get fixed, but that means replacing the calculator.

Nevertheless I hope that the given problem will be solved!

                        
Re: Unrecoverable crash to lock-up
Message #8 Posted by John Wasilewski on 2 Oct 2007, 1:12 p.m.,
in response to message #7 by Patrick Rendulic

Its the brand-new just-launched shiny new
HP 35s Scientific Calculator

Thanks for your encouragement and hopes for a solution Patrick,
---
John

                              
Re: Unrecoverable crash to lock-up
Message #9 Posted by John Wasilewski on 2 Oct 2007, 1:53 p.m.,
in response to message #8 by John Wasilewski

I have sent a detailed description of this problem to the calculators section of http://wwemail.support.hp.com and my report has been acknowledged by an autogen email from HP Calculator E-mail Support <calculator_support_en@mail.support.hp.com> with reference number KMM20282596V46293L0KM.

I'll pass on anything useful or otherwise I manage to obtain from HP.

If anyone would like to see the 473-line code that caused this, just let me have an email address to send it to you. I have a PC .txt file of it. The program does a rigorous parabolic-rectangular stress-block analysis of a rectangular RC section for a required moment of resistance in accordance with BS8110:Pt1:1997. It then recommends a section size (for the user to over-ride with his/her own choice), and, finally, optimises the compression and tension reinforcement bar sizes for minimum steel weight in the user's chosen section size.

----
John

                                    
Way to go!
Message #10 Posted by Arne Halvorsen (Norway) on 2 Oct 2007, 2:02 p.m.,
in response to message #9 by John Wasilewski

That was a novel idea! Actual complain to HP about 35s problem.

Anybody actual did that regarding the vector-syntax bug? Perhaps I should, thats *my* beef the with thing... Have not had to reset the 'system' though...., Mr. Wasilewski has my symphaties...

Edited: 2 Oct 2007, 2:03 p.m.

                                    
Re: Unrecoverable crash to lock-up
Message #11 Posted by Seth Morabito on 2 Oct 2007, 2:39 p.m.,
in response to message #9 by John Wasilewski

If possible, I would also suggest trying to bring this up directly to Cyrille de Brebisson. I know he reads the Usenet newsgroups, and he may read this board as well. He is very keen on documenting and fixing all the bugs in the 35s, as we discussed at HHC, although of course due to the rest of HP being involved, he cannot comment on exactly what bugs may get fixed, nor when they will get fixed. But I know he is personally invested in the 35s and wants to see it bug-free.

Googling for his name is probably a good way to get his contact information. He'll want to see the program that causes the lock-up, I'm sure.

Regards,

Seth

                                          
Re: Unrecoverable crash to lock-up
Message #12 Posted by John Wasilewski on 2 Oct 2007, 4:06 p.m.,
in response to message #11 by Seth Morabito

Thank you Seth.
I have just sent the following message by email:

to cyrille_de-brebisson@hp.com
date 2 Oct 2007 21:03
subject HP 35s unrecoverable crash problem

Dear Cyrille,

HP 35s Scientific calculator
Serial no. CNA72100255

Someone on the HP calculators users' forum at www.hpmuseum.org has suggested that I write to you about what may be a very serious fault with the seemingly excellent HP35s. I'm told you will certainly want to know about this.

I short, I may have discovered a system instability causing occasional unrecoverable crashes, under as-yet unknown circumstances. The gravity of this comes from the fact that, with no means of saving programs, crashes needing a hard reset (causing total memory erasure) will make it untenable to develop serious software because one loses everything. All software that a user has ever developed is lost.

Here's what has happened to me.

In final tweak/adjust/debug stage, XEQuting a 473-line program caused the screen and keyboad to freeze. None of the keystroke combination reset procedures in the manual worked.

i.e. neither of the following freed the lock-up.
C + GTO
C + R/S + i

Consequences were very bad. I had to stick a pin in the back. I therefore lost not only this long program but also ALL other code I had entered for previous programs.

Hoping that this was just an unfortunate rare occurrence, I re-typed the entire 473-line program from notes I had kept. When I tried to XEQute it again to resume where I had left off, it worked partially (just as before) and then, at exactly the same place in the data entry, exactly the same problem happened again.

I'm therefore faced with having to type it all in yet again (that is, AT LEAST one more time, and probably more than one). Naturally, I'll try stepping through it next time, but when it crashes again, I will again be back to zero.

This is very exasperating and time-wasting.

It is also extremely discouraging. I had planned to build up gradually (and post to an HP calculators users' forum site) a library of most-useful structural engineering code that would just lie in memory, preserved by always having a spare battery pair and replacing batteries carefully. This unrecoverable crash means I can expect to lose the lot. And that is a big big disincentive to software development on a calculator I can't trust, that has no possibility for external filesaves.

I have posted a request for help on the excellent calculator users forum at www.hpmuseum.org .

I have asked,

1) Has anyone else had any similar experience?

2) Does anyone have any ideas of what type of code might cause it, so that I can search through my code to try to find MY bug?

3) Has anyone any ideas about how to force a non-destructive reset when the instructions in the manual dont succeed?

Be in no doubt, if this problem persists and we can't find out why, then the HP35S, which is otherwise a superb calculator, becomes totally crippled for all serious users. One cannot write serious programs on a calculator with no save facility if it suffers from occasional crashes that wipe the entire library of all programming ever done on it.

I have sent a detailed description of this problem to the calculators section of http://wwemail.support.hp.com and my report has been acknowledged by an autogen email from HP Calculator E-mail Support <calculator_support_en@mail.support.hp.com> with reference number KMM20282596V46293L0KM.

I don't know if you will be interested to see the 473-line code that caused this, but I am attaching details in a PC Micro$oft Word file, just in case you would like to see it. The program is for structural engineering design. It does a rigorous parabolic-rectangular stress-block analysis of a rectangular RC section for a required moment of resistance in accordance with BS8110:Pt1:1997. It then recommends a section size (for the user to over-ride with his/her own choice), and, finally, optimises the compression and tension reinforcement bar sizes for minimum steel weight in the user's chosen section size.

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

Please note that the above program is still only in its final testing/debugging stage. The problem is not that the program doesn't work. Its that it kills the calculator so totally that I hae had to wipe out all programs in it with a hardware reset.

I hope you can help.
Many people on the users' forum are starting to say the same.
-----
John Wasilewski
Civil engineer
Oxford and London

                                                
Re: Unrecoverable crash to lock-up
Message #13 Posted by John Wasilewski on 2 Oct 2007, 10:22 p.m.,
in response to message #12 by John Wasilewski

On 02/10/2007, HP Calculator E-mail Support <calculator_support_en@mail.support.hp.com> wrote:
> Hello John,
> 
> Thank you for contacting HP Total Care.
> 
> 
> Unfortunately we do not support programming.  If it is a program from
> the manual or the HP website please link the url or a copy of the
> program code.  If it is a 3rd party program you would need to contact
> that party.
> 
> 
> 
> Sincerely,
> Mike
> HP Total Care
> 
> 
> Our advice is strictly limited to the question(s) asked and is based on
> the information provided to us.  HP does not assume any responsibility
> or liability for the advice given and shall not be liable for any
> direct, indirect, special, incidental or consequential damages in
> connection with the use of this information.  Always back up your data.
> For more information, including technical information updates, please
> visit our Web site at http://www.hp.com/support.

Dear Mike,

Thank you for your prompt reply. I'm sorry that my original message was rather long. I tried to be as informative as I could but the result was that I seem to have lost you, because I was not asking for programming support.

The problem I was reporting is a suspected hardware/firmware defect that could have very serious consequences for the HP35s product -- which will be a great pity.

Could you possibly look again more closely at my original message? You'll see that I was reporting some as-yet not fully identified condition that caused teh calculator to freeze so badly that none of the reset commands in the handbook worked, and it became necessary to wipe the entire memory of all programming to date. This is a very serious worry because if it can crash like this then users will never be able to make full use of this product.

Nobody can take the risk of losing days, weeks and months of work if unrecoverable crashes can happen, when there is no way of saving the work. I had hoped you would have something constructive or encouraging to say, like, "here is what to do when that happens" or, "we know about it and we're developing a fix", or "we agree, that is worrying, please tell us more."

Please take this seriously. I am not pestering you vexatiously. I'm worried about a possible serious latent defect in your product. I'd like to help you track it down if there is a problem, and I'd like some assurance (and support) that I can make full use of the calculator without having a great deal of my work being wiped out. --- John

                                    
Re: Unrecoverable crash to lock-up
Message #14 Posted by Katie Wasserman on 2 Oct 2007, 5:18 p.m.,
in response to message #9 by John Wasilewski

John,

I'd like to see your code that caused this problem, I'm sure that others here would like too as well, maybe you can just post it instead of dealing with separate emails.

Are you using vectors in the program? They seem particularly buggy and I've had lots of problems with them particularly in conjunction with "memory full" error messages.

-Katie

                                          
Re: Unrecoverable crash to lock-up
Message #15 Posted by John Wasilewski on 2 Oct 2007, 8:03 p.m.,
in response to message #14 by Katie Wasserman

As requested by Katie Wasserman, here's the program. Please bear in mind it was still in final testing stages.

The problem for us to resolve, remember, is not how to make my program work (it was very close to being all finished, debugged and tested). The problem here, though, is to discover why the HP35s filled up suddenly with liquid nitrogen, and how to defrost it if it happens again without having to poke it in the warm-me-up-hole in the back, which consigns its contents to oblivion.

I've tried in haste to make the listing readable using limited character set available in this forum web editor. If anyone wants the M$Word version (more readable, more reliable) just email me at John@Wasilewski.co.uk (shock horror, a real email address!).

HP35s program : Beam 8110 John Wasilewski 02 Oct 07

TECHNICAL REFERENCE Reynolds and Steadman, Reinforced COncrete Designer's Handbook, 10th Ed.

STORAGE 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

CODE 1. LBL B 2. SF 10 3. BEAM 8110 4. PSE 5. 0 6. STO O 7. STO P 8. STO Q 9. STO R 10. STO E 11. STO L 12. 1.05 13. STO U 14. 1.5 15. STO V 16. CF 1 17. SF 5 18. FIX 0 19. GTO B157 20. Get next bar size 21. x>y? 22. GTO B042 23. 10 24. x>y? 25. GTO B042 26. 12 27. x>y? 28. GTO B042 29. 16 30. x>y? 31. GTO B042 32. 20 33. x>y? 34. GTO B042 35. 25 36. x>y? 37. GTO B042 38. 32 39. x>y? 40. GTO B042 41. 40 42. X<>y 43. R| 44. RTN 45. RCL H Calc steel-to-steel lever arm Z 46. RCL O 47. RCL Q 48. + 49. 2 50. 51. 52. RCL C 53. 2 54. x 55. 56. RTN 57. RCL Y (1 fy/700Gm) depending on calling 1 58. x 59. 700 60. 61. RCL U 62. 63. 1 64. + 65. RTN 66. RCL D 67. STO X Initial value of X 68. 0.25 69. RCL I 70. x 71. RCL J 72. .25 k1/k2 73. RCL N 74. RCL B 75. 76. RCL D 77. x2 78. M/BD2 79. x>y? 80. GTO B98 If M/BD2 > .25 k1/k2 then keep X=1 81. RCL D 82. 2 83. 84. RCL J 85. 86. STO X D/2k1 87. x2 88. RCL N 89. RCL I 90. 91. RCL J 92. 93. RCL B 94. 95. - (D/2k1)2 M /(B k1 k2) 96. SQRTx 97. STO- X X = D/2k1 - ((D/2k1)2 M /(B k1 k2)) 98. RCL D X = the calculated value but not > D 99. 1 100. XEQ B57 (1 + fy/700Gm) 101. Keep X <= (D /(1 + fy/700Gm)) 102. RCL X 103. x<>y 104. x>y? X > (D /(1 + fy/700Gm)) ? 105. GTO B107 Yes; leave as-is 106. STO X Else change X to (D /(1 + fy/700Gm)) 107. CF 1 108. RCL D Calculate Z 109. STO Z 110. RCL J 111. RCLx X 112. STO- Z Z = D-k2X 113. RTN 114. RCL D Calculate total moment of resistance 115. RCL C 116. 117. RCL Q 118. 2 119. 120. 121. RCL Z 122. - D Z cover D/2 123. RCL T 124. x (DZcoverD/2)As 125. RCL Q 126. x2 127. x (Z-Z) As D2 = (DZcoverD/2) As D2 128. RCL S 129. RCL O 130. x2 131. x 132. RCL Z 133. X 134. + 135. Pi 136. x 137. RCL Y 138. x 139. 4 140. 141. RCL U 142. 143. FIX 3 144. RTN MR = Pi fy(As D2 + (Z-Z) As D2) / 4Gm 145. RCL O Weight of tension and compression bars 146. x2 147. RCL S 148. x 149. RCL Q 150. x2 151. RCL T 152. x 153. + 154. 162.1961 155. 156. RTN kg/m of reinforcement 157. INPUT M MAIN PROGRAM 158. F(Y) 159. PSE 160. INPUT Y 161. F(CU) 162. PSE 163. INPUT F 164. COVER 165. PSE 166. INPUT C 167. 2 168. 3 169. 170. RCL F 171. x 172. RCL V 173. 174. 1 175. 64.96875 176. 177. RCL F 178. RCL V 179. 180. 1.5 181. yx 182. x 183. 184. STO I 185. RCL F 186. RCL V 187. 188. SQRTx 189. 144.4375 190. 191. STO K 192. 4 193. 194. 1 195. x<>y 196. 197. RCL K 198. x 199. 3 200. 201. 0.5 202. x<>y 203. 204. 1 205. RCL K 206. 3 207. 208. 209. 210. STO J 211. 1 212. RCL J 213. 2 214. 215. 216. RCL I 217. 4 218. 219. x 220. RCL M 221. x<>y 222. 223. 3 224. 1/x 225. yx 226. 3 227. + 228. RCL C 229. + 230. 0.97 231. 232. STO H 233. INPUT H 234. 19 235. 236. 5 237. + 238. 2 239. 240. RCL C 241. + 242. RCL H 243. X<>y 244. 245. STO D H cover (H/19 + 5)/2 246. x2 247. 1 248. RCL J 249. 2 250. 251. 252. x 253. RCL I 254. 2 255. 256. x 257. RCL M 258. x<>y 259. 260. STO B 261. INPUT B 262. RCL Q 263. RCL O 264. C,T BAR SIZES 265. STO O 266. R| 267. STO Q 268. STO L 269. RCL H 270. RCL C 271. 272. RCL O 273. 2 274. 275. 276. STO D 277. RCL B 278. RCL D 279. x 280. .008 281. x 282. Pi 283. 284. RCL Q 285. x=0? 286. GTO B309 No comp bars entered yet 287. x2 288. For comp steel >= 0.2%BD, No of bars=.008 BD/ Pi d2 289. INTG 290. x>0? 291. GTO B292 292. 1 293. 1 294. + 295. STO R No of comp bars = .008 BD/ Pi d2 but at least 2 296. Pi 297. x 298. RCL Q 299. x2 300. x 301. 4 302. Area of at least 2 bars with >= 0.2%BD 303. RCL Y 304. x 305. RCL U 306. Comp force in min comp bars 307. XEQ B45 Steel-to-steel lever arm Z 308. x M from minimum comp bars 309. +/- 310. STO N -M from minimum comp bars (0 if none entered) 311. RCL M 312. STO+ N Balance of M still needed after min comp M 313. XEQ B66 X for balance of M still needed but not > D 314. RCL D 315. 2 316. 317. RCL X 318. x<=y? 319. GTO B332 320. RCL Q 321. x>0? Comp bars entered? If not then get some 322. GTO B360 323. RCL L 324. X>0? 325. GTO B329 326. RCL O 327. 3 328. 329. XEQ B020 Get next bar size 330. STO Q 331. GTO B277 332. RCL Q 333. x=0? 334. GTO B343 No comp bars entered 335. 2 336. 337. RCL C 338. + D 339. -1 340. XEQ B057 1 - fy/700Gm 341. x<>y 342. Xmin for full fy/Gm = D/(1-fy/700Gm) 343. RCL X 344. x>y? 345. GTO B354 X is > Xmin 346. R| X is too small. Increase it 347. STO X 348. SF 1 Flag the change in X 349. 1 350. XEQ B057 1 + fy/700Gm 351. RCL D 352. x<>y 353. Xmax for full fy/Gm = D/(1+fy/700Gm) 354. RCL X 355. x<=y? 356. GTO B360 X is < Xmax 357. R| X is too large. Reduce it 358. STO X 359. SF 1 Flag the change in X 360. FS? 1 Has X changed? 361. XEQ B107 Yes it has. Recalculate Z 362. RCL M 363. STO N 364. RCL I 365. RCL B 366. x 367. RCL X 368. x 369. STO A 370. RCL Z 371. x 372. STO- N 373. RCL A 374. RCL Y 375. 376. RCL U 377. x 378. STO P 379. RCL Q 380. x=0? 381. GTO B391 382. RCL N 383. XEQ B45 384. 385. RCL Y 386. 387. RCL U 388. x 389. STO+ P 390. STO R 391. RCL P 392. 4 393. x 394. Pi 395. 396. RCL O 397. x2 398. 399. STO P 400. RCL Q 401. x=0? 402. GTO B412 403. RCL R 404. 4 405. x 406. Pi 407. 408. RCL Q 409. x2 410. 411. STO R 412. 2.0000001 413. RCL R 414. X<y? 415. GTO B422 416. INTG 417. 1 418. + 419. STO T 420. RCL Q Calc clear space between comp bars 421. x 422. +/- 423. RCL C 424. 2 425. x 426. - 427. RCL B 428. + 429. RCL T 430. 1 431. - 432. Clear space betwn bars = (B-2xcover-nd)/(n-1) 433. RCL Q Calc min reqd clear space betwn bars 434. XEQ B020 435. 10 436. + Min (1) = (say) next bar size plus 10 437. X>y? 438. GTO B323 Too small cos too many bars. Use next bar size 439. R| 440. 25 Min (2) = Agg size plus 5mm = (say) 25mm 441. X>y? 442. GTO B323 Too small cos too many bars. Use next bar size 443. RCL P 444. INTG 445. 1 446. + 447. STO S 448. XEQ B145 Calc weight of tens + comp bars 449. STO E 450. COMP,TENS BARS 451. PSE 452. CF 10 453. [T,Q] 454. [S,O] 455. STOP 456. XEQ B145 Calc weight of tens + comp bars 457. STO G 458. XEQ B114 459. STO A 460. RCL R 461. STO T 462. RCL P 463. STO S 464. XEQ B114 465. RCL A 466. x<>y 467. FIX 0 468. STOP 469. FIX 2 470. XEQ B145 Calc weight of tens + comp bars 471. RCL G 472. x<>y 473. RTN

THINGS TO INVESTIGATE Resolve the mix-up between storage registers E and G (have I accidentally assigned both to the same use, when I intended them for different purposes?). I haven't had time to check this yet. Did a misplaced CF 10 instruction cause the program to hang? In the code that caused the crash, line 452 was between 411 and 412. I've run a simple test to see if clearing flag 10 before encountering teh text string display lines at 450 and 451 would cause a crash and it seems not to. I therefore do NOT think that this misplaced CF 10 instruction cause the program to hang.

                                                
Re: Unrecoverable crash to lock-up
Message #16 Posted by Meenzer on 3 Oct 2007, 3:52 a.m.,
in response to message #15 by John Wasilewski

Just to clarify before I (maybe) start keying this in my HP 35s: line 357 is supposed to mean "R down"?
What was your input when you ran the program to its crash?

I think I will SF/CF flag 10 before and after each text message, just to make sure...

                                                      
Re: Unrecoverable crash to lock-up
Message #17 Posted by John Wasilewski on 3 Oct 2007, 4:30 p.m.,
in response to message #16 by Meenzer

Yes, R| means 'Roll down.'

If I can have your email address, I'll send you a more reliable M$Word listing of the code.

About the program test data... --------------------------- I forget what exactly my input was but it was something like the following. I don't know whether the units will be meaningful to you but I've included them below in case they are. Ignore if not.

Moment of resistance M=40,000,000 (or maybe 100,000,000)kn-m

Steel characteristic strength f(y) Y=460 N/mm2

Concrete characteristic strength f(cu) F=35 N/mm2

Cover to the reinforcement (top, bottom and sides) C=25 or maybe 40mm

Program then suggests a beam depth (eg H=450) Over-ride it with a shallower depth H=350 mm

Program then suggests a beam width (eg B=517) Over-ride it with a narrower width H=240 mm

Note that the suggested depth and width, if accepted or over-ridden with slightly larger sizes will result in a singly reinforced beam, needing only tension reinforcement. Using a smaller beam size than suggested will force the program to include compression reinforcement.

Standard reinforcement bar sizes are 6, 8, 10, 12, 16, 20, 25, 32 and 40mm

Program now asks for reinforcing bar diameters. There will be a prompt and a pause, then NO prompt. Enter one or the other of the following (these are my suggested reinforcing bar sizes):

20 R/S for tension steel only -or- 16 ENTER 20 R/S for sizes of both compression steel (top) and tension steel (btm)

IT IS AT THIS POINT WHERE MY CRASH-TO-LOCK-UP HAS OCCURED ON TWO SUCCESIVE OCCASIONS. Both tests were with under-sized beams, to force the prog to test the compression steel routines.

Program is supposed to:

Try to find a design with the chosen bar sizes. If it works then enter a loop of retries with ever increasing compression bar sizes until the bar configuration is found that minimises the weight of steel.

eg display reads [4,16] [3,20]

This would mean use four 16mm compression bars and three 20mm tension bars for optimised design.

If no compression bar size is entered, and the program finds it needs compr steel then it should decide its own initial compression bar size and then enter the same optimisation loop.

Program also checks clear space between bars. If too small then increases the bar diameter (which reduces the number needed and increases the clear space between them.

Most of the above is written and was being tested when I discovered this crash-and-die behaviour. The only things missing were checks on tension bar spacing and an outer loop to optimise for tension steel bar size. These details are in there for compression steel though.

I hope the above will be sufficient for you. Very many thanks for considering that you might have a look at this problem. --- John

                                                            
Re: Unrecoverable crash to lock-up
Message #18 Posted by Meenzer on 4 Oct 2007, 2:13 a.m.,
in response to message #17 by John Wasilewski

I'm still considering keying that stuff in - but to be honest, the chances are very weak ;-)
Anyway you should send these above informations to HP, too.

And to be frank: as the program uses no rocket science functionality, I'd grab the cheapest calculator I have on my shelf that I can connect to the PC (i.e. the Casio CFX-9850GB+) and do it on that one, while having the convenience to type it on the PC keyboard and running it on an emulator first. You could even have 7-line-menues and coloured graphs for the result ;-)
If it is not obvious by now, I only use the HP 35s for some ad hoc programming and every day calculating - no problem if all stored data gets lost in a crash.

                                                                  
Re: Unrecoverable crash to lock-up
Message #19 Posted by John Wasilewski on 4 Oct 2007, 3:14 p.m.,
in response to message #18 by Meenzer

But I actually WANT to do it on an HP35s.
Why?

Because I... 1) prefer the RP notation to infix very greatly, 2) rather like this new machine (though less and less!), 2) prefer HP key presses above all others, 3) like to impress other engineers with my flash calculator, 4) don't want more than one calculator. --- John

                                                                        
Re: Unrecoverable crash to lock-up
Message #20 Posted by Meenzer on 4 Oct 2007, 3:30 p.m.,
in response to message #19 by John Wasilewski

Quote:
But I actually WANT to do it on an HP35s.
Why?

Because I... 1) prefer the RP notation to infix very greatly, 2) rather like this new machine (though less and less!), 2) prefer HP key presses above all others, 3) like to impress other engineers with my flash calculator, 4) don't want more than one calculator. --- John


;-) For 1, 2a, 2b, and 4 you could use the HP 48G AND have the link option. I concede it's no good for impressing anyone ;-)

                                                            
Re: Unrecoverable crash to lock-up
Message #21 Posted by Antoine M. Coutte on 4 Oct 2007, 3:25 a.m.,
in response to message #17 by John Wasilewski

Oct 04 th, 2007

Dear John and Meenzer,

Certainly it is extremely sad to go through the hard if not painful experience of losing your entire data/programs you have taken so much time refining, John. It can ruin your day, or even week, or even worse.

So in order to help, I am just offering the following comments with the - hopefully right - assumption that HP35s language is pretty similar to HP 41 language as detailed here under. If such is not the case, then all the following lines are irrelevant, and I do apologize for bringing up some " unwanted noise " to this high quality Forum.

Most the following comments are plain good sense, and I certainly would not like to offend both of you through these " over simplistic " or underlined comments. In my own experience, even after many, very many ... HP41 programming hours/days/weeks and months ( far too many in my Wifes opinion and judgement ) I still occasionnaly get caught short and keep stumbling on " easy to avoid " traps. The only advantage experience has brought to me here is that I generally can debug my own programs much faster than in ealier times because I have acquired some kind of a " feeling " about the potential areas where my own programming instructions might eventually go wrong

Through reading your last detailed comments on your program, John, I am just wondering whether your various computation loops are correctly labelled and also whether they do not exceed the maximum authorized " depth level " ( if any applicable on the HP35s ).

I am not familiar with HP35s programming, still HP35s language at a first glance seems to be rather similar to a combination of HP41 and HP25 languages with line adressing ( like in the HP25 C ) rather than label adressing ( like in the HP 41 ). This line adressing feature does save programming space, but it forces one to very/extremely carefully keep track of line numbers. Since any time you add or remove one instruction, all subsequent instructions are " line renumbered " and therefore have a different line address, it in turn implies to modify all subsequent/relevant line number references into your XEQs and GTOs instructions.

So, before any more in depth crosschecking - and by comparison with HP 41 and HP 25 C programming practices - I would check :

- that all GTOs and XEQs instructions refer to correctly numbered ( or correctly " newly/recently renumbered " ) lines,

- that all GTOs and XEQs instructions finish up where they are supposed to. My guess is that if they are similar to the HP 41 loops adressing system, all " XEQ " instructions will finish at the first " RTN " or " END " instruction and then resume to the line immediately after the initial " XEQ " , while all " GTO " instructions are simply " plain branching/jumping instructions " just going from one point to another in the programm. So it is extremely important to realize that an " XEQ " instruction cannot be inadvertently replaced by a " GTO " instruction, since, among unwanted results, it WILL ( sorry to write loud ... ) have an ( again most ) undesirable effect on loop(s) depth.

- and most importantly, that the " loop depth " does not exceed the authorized " depth level " in the HP 35s. Loop depth on HP41 is a maximum of 6 pending returns if you want to finally exit all loops where you started them. What is " loop depth " on the HP45s ???

Again, I certainly do not want to offend both of you through my " over simplistic and dumb " thoughts. All these comments just to help, unfortunately and maybe not very much of an immediate help since the cross checking path I am suggesting requires a lot of extremely careful understanding /checking /testing about what is going on.

Since at a first glance, your Program seems quite " compact and condensed " - which is a very beautiful feature John - maybe it is worth verifying all the hereabove.

Another way to look at it is realizing that " nothing is more stupid that a Computer or a Calculator " but once you " cornered it " into doing exactly what you want it to do, then nothing is more " computation/numbers crunching efficient " .

Hope it does help

Hello from " Douce France " in Vende where we are currently enjoying a wonderful and warm night with a beautiful 1/3 Moon just next to Pollux !

Best Regards and Good Luck - and keep us posted - from

Antoine

PS : BTW, I am no longer flying the good old Cargo DC10-30 Aircraft, but just transitioned to the B 757/767 flying again passengers now. Love flying, more than ever

For HrastProgrammer, on last Friday early afternoon, I flew just a few miles north of Zagreb, and had - again - a quite thankful thought about you and about your wonderful HP 41 Emulator for the HP 48/49/50. Thank you again here !

                                                                  
Re: Unrecoverable crash to lock-up
Message #22 Posted by HrastProgrammer on 4 Oct 2007, 11:57 a.m.,
in response to message #21 by Antoine M. Coutte

Why didn't you land? :-)

                                                                  
Re: Unrecoverable crash to lock-up
Message #23 Posted by Thor Lansen on 4 Oct 2007, 12:41 p.m.,
in response to message #21 by Antoine M. Coutte

My question is, in those many hours of programming have you had a complete crash of your HP41 (as apparently happened with the HP35s)? I do not own and I have no desire for a HP35s, but I own a HP41CX and a HP25C and I had programmed them a great deal (not anymore) and to my recollection (even stuck in infinite loops) I have never experienced something like John mentions. I can relate the problem he described to the annoying blue screens I get with "el crapo" OS that came with my PC (fortunately I have a hard drive to save my work to). It seems to me this is totally unacceptable and even more HP's response (or lack of) to the problem.

Regards, Thor

                                                                        
Re: Unrecoverable crash to lock-up
Message #24 Posted by Arne Halvorsen (Norway) on 4 Oct 2007, 12:58 p.m.,
in response to message #23 by Thor Lansen

Kind of my thoughts to! While I havent had a serious problem as the one described in this thread I have spent more time that I would like knowing getting out of the 'vector syntax bug state' doing this project on the HP-35s. It has turned out the be a fight between me and the machine.

Remember having no such problems with my old 41! Note to self: Get my act together and ship the good old one to fixthatcalc!

To bad hp rushed the 35s to the marked :-(

                                                                        
Re: Unrecoverable crash to lock-up
Message #25 Posted by Antoine M. Coutte on 4 Oct 2007, 1:51 p.m.,
in response to message #23 by Thor Lansen

You are very right, Thor : through using standard/conventional programming techniques never either did I experience one single serious HP41 crash similar to the one John described.

Still, it came to my mind to carefully check his HP35s program " loop structure " because line addressing is in essence certainly more delicate than using local or global labels. And John made a frequent use of the GTO and XEQ instructions.

In this current Program case, if one were absolutely sure that the entire " loop syntax " is fully respected and correct, then we would have a better documented case about a potentially quite serious Machine bug, even more crucial since apparently the HP35s seems to lack ( of ?) any convenient data saving tool.

From recent posts, and in particular for the one related to " vector syntax ", the HP 35s seems somewhat deficient, either because it might lack comprehensive and accurate documentation, or simply because it was not extensively tested prior to Market Introduction.

And as earlier stated, so long as my guesses about the HP35s programming techniques are valid, I am certainly not pretending to deliver a full and definite answer or explanation to John's serious problems, but just and only giving indications of an area probably worth exploring.

Best Regards, Antoine

                                                                              
Re: Unrecoverable crash to lock-up
Message #26 Posted by John Wasilewski on 4 Oct 2007, 3:22 p.m.,
in response to message #25 by Antoine M. Coutte

Good chance that loop structure is why the program fails.
That's not my problem.

The problem is why does THE CALCULATOR fail, not why does the program fail? And how do I prevent it?

We cannot have a programmable calculator that can't be used to try running any code that might have bugs in it!

How can we develop and debug new code if the calculator might wipe out all our work unless the code is already perfect before we start debugging? --- John

                                                                  
Re: Unrecoverable crash to lock-up
Message #27 Posted by John Wasilewski on 4 Oct 2007, 3:06 p.m.,
in response to message #21 by Antoine M. Coutte

It was very kind of you to take time to prepare such a good list of tips and I am not in the least offended.  They look really interesting and I will study them.  I'm sure I won't have thought of all of them.

Please bear in mind, however, that my problem is not how to debug my program - I have no worries about finding the last few glitches. The problem is how eitehr to prevent calculator crashes to a locked-up state or how to recover if it happens again, without wiping out all my work ---- John

                                                            
Re: Unrecoverable crash to lock-up
Message #28 Posted by Meenzer on 4 Oct 2007, 6:45 a.m.,
in response to message #17 by John Wasilewski

Puhh, I just keyed in the first 200 lines and am sorry to say: I've had it. No more. Basta! I really give up. If maybe one day there will be a beaming device to transfer code to the HP 35s, I might start anew ;-)

                                                
Re: Unrecoverable crash to lock-up
Message #29 Posted by Katie Wasserman on 4 Oct 2007, 9:59 a.m.,
in response to message #15 by John Wasilewski

John,

I think that I understand the mnemonics of all the lines in the program except number 264.

263.	RCL O	
264.	C,T BAR SIZES	
265.	STO O	

Is the "STO O" supposed to be a PSE?

-Katie

                                                      
Re: Unrecoverable crash to lock-up
Message #30 Posted by John Wasilewski on 4 Oct 2007, 2:39 p.m.,
in response to message #29 by Katie Wasserman

STO O means Store to register 'O'
(The alpha letter O not numeric zero). Like STO B only to O ! ---- John

                                                      
Re: Unrecoverable crash to lock-up
Message #31 Posted by John Wasilewski on 4 Oct 2007, 3:08 p.m.,
in response to message #29 by Katie Wasserman

Katie, what's your email address?  

I need to send you a properly formatted listing with recognisable characters. --- John@Wasilewski.co.uk

                                                      
Re: Unrecoverable crash to lock-up
Message #32 Posted by John Wasilewski on 4 Oct 2007, 3:33 p.m.,
in response to message #29 by Katie Wasserman

Sorry Katie, I explained 263, so I replied to the wrong question.

263. RCL O 264. C,T BAR SIZES 265. STO O

264 is a text string placed in the display using EQN, followed by a momentary PSE, to prompt the user to enter bar sizes. I did it this way because data entry at this point might consist of either tension steel bar size only (entered in the X line) or both compression an tension steel bar sizes (entered in the Y and X display lines)

eg

User data entry following this prompt might be just

16 R/S (for 16mm tension bars)

or

16 ENTER 25 R/S (for 16mm compression bars and 25mm tension bars)

---- John

                                                            
Re: Unrecoverable crash to lock-up
Message #33 Posted by Katie Wasserman on 4 Oct 2007, 4:53 p.m.,
in response to message #32 by John Wasilewski

Thanks for the explanation.

I've been playing with parts of your program trying to recreate the lock-up bug with no luck so far.

                                                
Re: Unrecoverable crash to lock-up
Message #34 Posted by John Limpert on 10 Oct 2007, 10:30 a.m.,
in response to message #15 by John Wasilewski

I typed in your program, although I won't guarantee that I didn't make any errors. My aging eyes have a hard time distinguishing between the symbols used for addition and division. It seemed to run OK, and it did not lockup or crash.

                                                      
John Wasilewski ... here's what I suggest...
Message #35 Posted by Gene Wright on 10 Oct 2007, 10:49 a.m.,
in response to message #34 by John Limpert

I'm not sure what country you are in, but I think you have a valid reason to return the unit for an exchange.

It seems that you have a machine with a problem that no one else is experiencing. Perhaps that is a result of a bad batch. More likely there is just something wrong with the innards of your machine.

Despite Katie's frustrations :-) many of us are using the 35s and taxing the unit in many ways without ever seeing any crashes or behavior that gives us problems the way you are seeing them.

So, call HP's phone number, patiently explain that your HP 35s is not operating properly. I would not say that you are programming the machine, etc, as that would confuse the issue with whoever answers the phone. I would say that it locks up and does not function correctly, that you cannot reset the machine using the steps described in the manual without using the reset pin on the back which causes you to lose your data.

Explain how your friends with a 35s are not experiencing this type of problem and that you want to exchange your unit for another one that should not have this problem.

Do remember that the person on the phone talking to you from HP is part of the entire HP corporate world and will probably know little to nothing about HP calculators.

Let us know what the response is. If they are not helpful, let me know. A 35s should not behave like this and yours should be exchanged.

ok? :-)

Gene

                                                      
Re: Unrecoverable crash to lock-up
Message #36 Posted by John Wasilewski on 11 Oct 2007, 4:37 p.m.,
in response to message #34 by John Limpert

Reply to John Limpert.

Thank you for taking so much trouble to help with this problem.

Did you over-ride the prompt-suggested depth and width sizes with smaller values as input? THis is necessary to force the program to calculate compression steel.

When the program reaches line 264 it issues an alpha prompt for comp and tension steel then stops to wait for input (this is the action obtained when no PSE statement follows an alpha string whilst flag 10 is set). id you then enter just a tension steel diameter and press R/S (eg 20 R/S)?

It is only after the above steps have been passed that the endless loop is reached which I can't break out of.

---
John

(ps sent from an Internet cafe)

      
Re: Unrecoverable crash to lock-up
Message #37 Posted by bill platt on 4 Oct 2007, 12:59 p.m.,
in response to message #1 by John Wasilewski

Hi John,

You wrote an impressive program, beautifully arranged, but I have to ask the question: why bother? I can't stand putting more than a few lines together on a calculator; I'd rather do that sort of thing on a proper computer. Nowadays, the only thing going for calculators is, well, calculating.

I am curious: you have a specific reason for putting that kind of program on a calculator?

            
Re: Unrecoverable crash to lock-up
Message #38 Posted by John Wasilewski on 4 Oct 2007, 3:00 p.m.,
in response to message #37 by bill platt

Programs like this get built gradually in spare moments, on train journeys.  One starts with a short bit of code that performs some useful function, and works.  Then add a little more functionality.  And again.  It grows.

I also DO WANT a small library on my calculator of really good programs that will do things for me that I don't do a lot, so might need to look stuff up in text books when occasionally I need to check something or make an ad hoc design calculation.

In my case I have in mind some tight, smart code for (eg) - Concrete beam analysis and design check - Bearing capacity calculation - Slope stability analysis - Section properties calculation - Principal stresses - Earth pressure calculations - Polynomial regression curve fit

My present guess is that that's about the limit that could fit into memory.

If I feel really ambitious I might also explore implementing a simple frame analysis program I once wrote for the TI59.

A library in my pocket of all the above, always instantly accessible, could be very valuable to me.

That's why. --- John

                  
Re: Unrecoverable crash to lock-up
Message #39 Posted by bill platt on 4 Oct 2007, 4:37 p.m.,
in response to message #38 by John Wasilewski

I appreciate the train journey aspect, being a train buff myself.

For me, I/O becomes important for larger programs, libraries etc. It seems to me that the 50G makes a lot more sense (or for retro a 48GX). You can run an emulator on it for the 41cx, and therefore you can develop in RPN rather than RPL if it suits you. And you have backup, and I/O.

Best regards,

Bill

            
Re: Unrecoverable crash to lock-up
Message #40 Posted by DaveJ on 4 Oct 2007, 8:06 p.m.,
in response to message #37 by bill platt

Quote:
Hi John,

You wrote an impressive program, beautifully arranged, but I have to ask the question: why bother? I can't stand putting more than a few lines together on a calculator; I'd rather do that sort of thing on a proper computer. Nowadays, the only thing going for calculators is, well, calculating.

I am curious: you have a specific reason for putting that kind of program on a calculator?


That is precisely why I don't understand the reasoning behind the new 35S. Fair enough having programming capability on a non-I/O calculator, it's very useful, but why optimise the keypad layout for programming at the expense of ease of regular calculations? They changed this from the 33S to the 35S, why?

Dave.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall