Issues Converting Program Stage To Decimal

[jcottrill]

Hey Guys,

I am seeing some inconsistencies with a calculated expression.  I am using the following equation to convert the bits of the stage registers to a decimal number for use by my HMI.  My design is such that only one state/stage is enabled at a time.  For most cases, this calculation appears to work fine.  However, when S15 is enabled (S0_15 = 0x8000), the execution of the calculation returns a decimal value of 14.  I am stumped as to why it would be fine for some cases but not others.  For example S5 is converted properly to a decimal value of 5.  Any thoughts?

Code: [Select]

IF(TestPlatform.S0_15 > 0, ((LN(TestPlatform.S0_15) / LN(2)) + 0), 0)
+ IF(TestPlatform.S16_31 > 0, ((LN(TestPlatform.S16_31) / LN(2)) + 16), 0)
+ IF(TestPlatform.S32_47 > 0, ((LN(TestPlatform.S32_47) / LN(2)) + 32), 0)
+ IF(TestPlatform.S48_63 > 0, ((LN(TestPlatform.S48_63) / LN(2)) + 48), 0)
+ IF(TestPlatform.S64_79 > 0, ((LN(TestPlatform.S64_79) / LN(2)) + 64), 0)
+ IF(TestPlatform.S80_95 > 0, ((LN(TestPlatform.S80_95) / LN(2)) + 80), 0)
+ IF(TestPlatform.S96_111 > 0, ((LN(TestPlatform.S96_111) / LN(2)) + 96), 0)
+ IF(TestPlatform.S112_127 > 0, ((LN(TestPlatform.S112_127) / LN(2)) + 112), 0)


[BobO]

I'm guessing it's a signed/unsigned thing, but I'm not at a place I can test it. Fyi, Host is actually shut down this week, but I expect to be in the office for a few hours tomorrow.

[Mike Nash]

You must be reading it as an integer. The MATH result for LN(32768)/LN(2) is 14.999999. Dataview rounded it to 15.0000 on my SIM. If you can ROUND(Your Math Result) before the HMI gets it it should be OK.

On second thought, you may be putting the result straight into an integer. Put it into a Real first, then round. Putting a bunch of ROUNDS into that MATH box might get ugly.

[BobO]

The math result will be real. It is fine to wrap the entire expression in ROUND() and assign to an integer.

[Mike Nash]

The math result will be real. It is fine to wrap the entire expression in ROUND() and assign to an integer.

That's cool. I forget what we can and can't do at times. I love that MATH is so powerful, but my ability to look at the expression of some of the creations it allows and quickly parse it out is um, lacking. It doesn't stop me from doing it, but it does slow me down, once.

Is TestPlatform.S0_15 a user structure?

On my current project I debated with myself back and forth to use them or not because the Modbus TCP was going to require integers and my Structure really wanted a little of everything. I won all those debates, (and lost them all too.) But I finally went for it and am using whatever I need to to move things in and out, converting and scaling as I go. The best realization is that this is going to allow me to have one structure type regardless of whether the device is one model or the other "different" one that really wants 32 bit words instead of 16 like the first. All of these are now in an array of that user structure. With 2 basic ladder programs as templates I can paste as many as I need into separate programs and easily search and replace MyThingy0 with MyThingy1, 2, 3, etc. Replace the integers for the MRXs and MRWs and I'm nearly done. And all of those will contain my really convoluted single MATH box "solution" to clutter. Oh, and Nicknames for MyThingyx are once each and done and now C-more gets to access them directly. Harder on the Do-more, but the time intensive stuff is in another PLC and it is using native types for everything.

Sorry if I derailed your thread.

[jcottrill]

BobO,

I assumed/hoped you guys would be out this week but figured I'd get it out here before I forgot.  Thanks again for the speedy reply.  Wrapping the expression in a ROUND() worked perfectly. 

[BobO]

Those are a union view of stage bits in a program block.

The basic rule with math is that once a stack level promotes to real, it remains real. Int/int yields int, int/real yields real, and of course real/real yields real.

[Mike Nash]

This PLC stuff (that I'm not responsible for) is such an interesting past-time.

You don't need the > 0 test if the only bits ever on are 0-15. And I went ahead and added the ROUND per BobO.

Code: [Select]

ROUND(IF(TestPlatform.S0_15, ((LN(TestPlatform.S0_15) / LN(2)) + 0), 0)
+ IF(TestPlatform.S16_31, ((LN(TestPlatform.S16_31) / LN(2)) + 16), 0)
+ IF(TestPlatform.S32_47, ((LN(TestPlatform.S32_47) / LN(2)) + 32), 0)
+ IF(TestPlatform.S48_63, ((LN(TestPlatform.S48_63) / LN(2)) + 48), 0)
+ IF(TestPlatform.S64_79, ((LN(TestPlatform.S64_79) / LN(2)) + 64), 0)
+ IF(TestPlatform.S80_95, ((LN(TestPlatform.S80_95) / LN(2)) + 80), 0)
+ IF(TestPlatform.S96_111, ((LN(TestPlatform.S96_111) / LN(2)) + 96), 0)
+ IF(TestPlatform.S112_127, ((LN(TestPlatform.S112_127) / LN(2)) + 112), 0))

[jcottrill]

Thanks Mike,

The stages in my program (TestPlatform) range from S0 to S100 so there is no guarantee that any of the bits will be set in the different blocks.  The > 0 check helps avoid the invalid result of LN(0).

[Mike Nash]

IF(ElementName, 1, 0) is Equivalent_note to IF(ElementName != 0, 1, 0)

I did put the code I posted in the SIM and tested it. Zeros are not an issue. I substituted D1 thru D8 for your elements, but only tested bits 0-15 on one at a time.

BobO and franji1 are full of great suggestions and this was one I think franji1 mentioned once.

But works and done is cool too.

Note: I cringe to state that because I am sure there is some caveat I am missing.

[jcottrill]

I see what you are saying now Mike.  Dropping the explicit comparison definitely cleans up the expression.  I think I was just being overly paranoid.  Too many weakly typed programming languages I guess.