H0-CTRIO2 Math in DL05

[sgsims]

What is the proper way to do some basic addition to a Dword that is mapped to the CTRIO Counter?

I seem to remember the number format from the CTRIO being Binary?  So does that mean I have to use the ADDBD function to add a Kvalue to the current encoder count to get my desired result?  But the ADDBD function is not available in the DL05.  So do I need to convert the Dword value mapped from the encoder to a BCD value then do regular ADDD?

Or am I totally off base all together.

[BobO]

CTRIO/2 can be configured to output BCD instead of binary, by using a Scale. or yes, you can convert the binary value to BCD in the PLC.

[sgsims]

Thanks Bob,

Just to conclude my education here...If I am using the non-scaled Binary format from the CTRIO and then using the ADDD function using a K-Value I will eventually run into trouble as the binary encoder number gets larger right?

[BobO]

Sorry...my DL-fu is a bit rusty...but if I understand the question, BCD does greatly reduce the useful range of the accumulator, increasing the rate at which you will overrun it.

[sgsims]

Actually I was trying to understand what would happen if I kept my logic as-is.  In other words not heeding your suggestion to either scale the Binary Value to BCD in the CTRIO or convert the Binary value to BCD in the PLC.

So right now I am taking the Binary value from the CTRIO and using ADDD to add a K-Value...in this case K360 then using OUTD.  In my testing it seems to work fine but I guess I am really mixing formats ading the BCD K value to a Binary encoder count.  It is working when the encoder value is small but as that Binary encoder count grows the math will eventually be off.

Is that right?  I am going to heed your suggestion and scale the value in the CTRIO to BCD but was asking the above question just to see if I globally understood the mistake I was making.

Oh and yes I do understand that if I scale the binary encoder count to BCD is will limit the max encoder count before roll-over...no problem there.

Cheers

[b_carlton]

You will get in trouble as soon as the counter's Binary value has a representation outside the BCD allowed ranges (any 4 bit nibble with a value greater than '9'). The instruction will refuse to ADDD. Even if the counter's representation was according to BCD format the result of the ADDD would be incorrect because of the mixed types.

And, of course, another problem is that BCD math is  S L O W  compared to Binary.

Since you are limited to the DL05 then BCD is your only choice. At least you get up to 99999999.

[sgsims]

B-Carlton...nicely worded!  Thanks..You and Bob O are always spot on in these forums!

[franji1]

The "double" version of the math accumulator instructions are for what you are adding TO the accumulator, not the accumulator value.  The accumulator is ALWAYS 32 bits wide.

Hence,
LDD V2000 (some big 4billion number)
ADDB K1  (adds 1 to the 32 bit accumulator)
OUTD V2002  (some big 4billion number, plus 1)

So as long as your K is NOT bigger than KFFFF (i.e. 65535), you should be able to use ADDB (yes, you have to use HEX constant in your BINARY ADD).

[b_carlton]

This from the Directsoft Help File

Add Binary is a 16 bit instruction that adds the binary value in the lower 16 bits of the accumulator with a binary value (Aaaa), which is either a V memory location or a 16-bit constant. The result can be up to 32 bits and resides in the accumulator.

Does the "lower 16 bits" have any effect or is it a misstatement?

 

[franji1]

Misstatement.  It is adding a 16 bit binary value (V or K) to a 32 bit value (the accumulator).

I think they do that to NOT confuse people that the result is ALWAYS a 32 bit value, it's just that most of the time, when you are dealing with 16 bit registers, the upper word is all 0's.  Hence, they "imply" a 16 bit calculation.

But then it says "The result can be up to 32 bits...".