33s CHECKSUM issue: old/new

[ECL]

Just got a new copy of the 33s and have this problem:

I entered a program from my old 33s and see the same checksum: LN=270, however when I run the program, I get different answer from my old 33s. Any ideas?

Also, noted these improvements:

1. Spacing between numbers in display is increased (VERY GOOD)

2. Decimal larger (VERY GOOD)

ECL

[bill platt]

Hi,

Please post your program code so that I may run it on mine.

(I have one of the 1st production series).

regards,

Bill

[ECL]

Bill,

I have found the problem. I mistook the meaning of LN=xxx under the -> MEM , PROGRAMS menu. I thought this was the check sum, but it is not. I suppose it is memory used by this label. Here is the code anyway, you may already have it, but I have updated it since I first posted it:

Eric Lundgren April 2005

Rev 2 - August 2005

HP 33s/ Location of Vertical Nuetral Axis, and Ix (Second Moment)for composite cross section:

Description: For a buildup of n rectangular sections (ibeam, c-channel, sandwich, etc.), this program computes the location of neutral axis (measured from bottom of section), and the moment of inertia. 

To use the program-

The program requires that FLAG 1 is set prior to running. I simply keep FLAG 1 set all the time.

Execute via XEQ I, and you are prompted for number of sections. A basic I-beam would have 3 sections (web, upper cap and lower cap). B = width of a section, and H = height of that section. 

Both lines of the screen are used for the result:

Upper line is the location of vertical neutral axis (centroid). Lower line is the second moment of inertia of the plane area defined by the combined rectangular sections. Note that you can model two plates that have open space between them (perhaps a foam core that does not contribute to stiffness) by entering the width as zero, and then height equals the empty space.

LBL I  

FS? 1

CLVARS

FS? 1

INPUT N

CF 1

INPUT B

INPUT H

RCL H

2

/

RCL +T

RCL B

RCL * H

*

RCL +Q

STO Q

RCL B

RCL H

*

RCL +R

STO R

1

RCL +V

STO V

RCL Q

RCL / R

RCL – C

X^2

RCL *A

RCL + I 

STO I 

RCL T

RCL H

2

/

+

RCL Q

RCL / R

-

X^2

RCL *B

RCL *H

RCL H

3

Y^X

RCL *B

12

/

+

RCL + I 

STO I 

RCL Q

RCL / R

STO C

RCL B

RCL * H

RCL + A

STO A

RCL T

RCL +H

STO T

RCL V

RCL N

X>Y?

GTO I  

SF 1

RCL C  **location of neutral axis**

RCL I  **value of composite Ix **

RTN

CK: 1A60(valid only on HP33s)

LN = 270

[Gene]

RCL wrote: "CK: 1A60(valid only on HP33s) LN = 270"

Gene: Did you mean here "valid only on new 33s" or ?

I'm not aware of any changes to the checksum determination with any 33s revision, but that doesn't mean it hasn't happened, of course.

If this is from a 32SII to a 33S version, then all bets are off. :-)

Gene

[Brian Healy]

does you program allow the consideration of a different width for the web versus the flanges (caps). I'm a structural engineer, I get into reinforcing steel wide flange (ibeams) from the AISC manual, and all of the shapes have webs that are thinner than the caps.

[ECL]

Brian,

A nice point is that it only uses one label. My code is for any cross-sect composed of n rectangular pieces.

I'll illustrate with an example of a basic I-beam, and note that I do not account for the radius at the web/flange intersection. Say you have a beam with:

upper flange= 3"x0.33" (width x height)

web = 0.35"x6" (width x height)

lower flange= 4"x0.25" (width x height)

My code would work like this, starting from the bottom surface of the lower flange:

N = 3 R/S

B = 4 R/S

H = 0.25 R/S

B = 0.35 R/S

H = 6 R/S

B = 3 R/S

H = 0.33 R/S

The output is:

3.25204 = Ybar (vertical coordinate of centroid from bottom. Units: inch)

25.99 = Ix (second moment, or area-moment of inertia. Units: inch^4)

Hope this helps. I've run it against some real beams and found very close to the published data. Of course, they account for radius and possible taper of web?
ECL

[bill platt]

Hi ECL,

No I remember! We talked about this some months back--and swapped programs. I also have written simple programs for this problem.

I have written programs for this problem a number oftimes--1st on the 11c, then the 32s, then the 41cv---I run the 41cv using Hrastprogrammer's emulator on a 48gx.

I "modularize" so that I run separate routine for each:

a: take rectangle width, height, above baseline
(this routine can be run over and to keep adding more components)

b: solve for inertia and section modulus. Takes as input the maximum fiber distance from the baseline.

c: a subrooutine that will add the area, self inertia about centroid, and distance to baseline, of any known shape--all you have to do is enter it's I, its A, and its distance from centroid to baseline.

Routine (c) and (a) can be run in any order--and even after running (b)---in other words you can find intermediate results.

I find these routines very useful for design work, especially if making some strange built-up sections. Also good for checking htat a spreadsheet soulution is working correctly before freezing the cells.

Regards,

Bill

[Karl Schneider]

ECL --

Are you using preformatting ("[pre]" using Forum special formatting), or with an HTML editor?

If so, please don't becuas it really impairs legibility. Preformatting is intended for code listings.

Thanks,

-- KS

[bill platt]

I was going to ask the same question.

I am curious if it is his browser rather than the "[pre]" thing

[ECL]

Sorry guys,

I thought I was doing everyone a favor by that. I thought carriage returns would not be preserved unless I used the [pre]. Ok, only for code listings from now :)

ECL

[Howard Owen]

Quote:

---

.. I thought carriage returns would not be preserved unless I used the [pre].

---

Not exactly. Two carriage returns in a row will show up as one line break without [pre], so your paragraphs will break naturally without worrying about them. You can also use [nl] to get the equivilant of an (X)HTML <br/>. But [pre] will preserve every carriage return, won't collapse consecutive white space, and will switch the font to fixed rather than proportional, just as with <pre> in HTML, so it's the right choice for listings.

[James M. Prange (Michigan)]

Yes, [pre]...[/pre] is perfect for program listings, tables, and so on, but it would be better not to include the ordinary text within the preformat delimiters. That way it wraps to whatever the size of the display box turns out to be, and assuming that no preformatted lines are terribly long, we won't have to scroll right to see the whole message.

Also see the advanced formatting techniques.

Regards,
James

Edited: 30 Oct 2005, 10:45 p.m.