BobLfoot

CPT Instruction "freeze"

6 posts in this topic

I'm quite puzzled today when I went online with a PLC and found the four (4) Compute (CPT) instructions in this periodic task were "frozen" at the values displayed in the picture.  In the case of all of them the "FI####" variable is real and the "FTI####" variable is a DINT.  The "freexe" number just happens to be greater than or equal to  2^28 in all four cases.  And before anyone asks, yes the task is periodic and scanning.  

Doing the math on rung 0 - 25440.0/3600 = 7.06  and 268455840 + 7 should equal 268455847 but the addition never happens.

Forcing a reset to zero (0) started all counter working again.

625056e3e0d92_EACOPLC.thumb.PNG.886cad00

 

Share this post


Link to post
Share on other sites

The addition is happening in floating point, where the addend is lost in the lower bits.  Any CPT that handles a float executes entirely with floats.

The only safe way to do totalizing like this is to maintain two tags: one 32-bit integer for the total, the other a 32-bit float for the fraction.  Plus an integer temporary variable.  Code would look like (output is FITxyz):

CPT FITxyzFraction "FITxyzFraction+FIxyz/3600.0"

MOV FITxyzFraction FITxyzInt

ADD FITxyz FITxyzInt FITxyz

SUB FITxyzFraction FITxyzInt FITxyzFraction

Share this post


Link to post
Share on other sites

@pturmel  This is ControlLogix which I thought used 64 bit float and therefore wouldn't have issues until 2^55 or larger.  But then it is Logix 5000 Revision 12 so it could be 32 bit float.

Share this post


Link to post
Share on other sites

Yeah, pretty sure v12 didn't have any 64 bit types.

Share this post


Link to post
Share on other sites

My understanding is that 64 bit data types can only be used in the L8 controllers, V28 and above.

1 person likes this

Share this post


Link to post
Share on other sites
On 4/8/2022 at 11:41 AM, BobLfoot said:

The "freexe" number just happens to be greater than or equal to  2^28 in all four cases.  And before anyone asks, yes the task is periodic and scanning.  

makes sense... 32-bit reals use only 23-bits for significant (remaining 9 bits are used for sign and exponent). so they are only good for about 7 significant figures when viewed in decimal... which is why 268455840 or 268455847 makes no difference, both get rounded to a same value.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now