RSLogix 5000 FRD instruction Help.

Hi There,

When i did FRD instruction in SLC 500 its working, when i try to simulate in RSLogix 5000 same way as i did in SLC 500 which is not working. Any ideas ?

What i did is there

In SLC FRD instruction
Source N7:150
Destination N7 152

when i enter binary format source 1000 1000 which converts to 88 in destination field.

when i do same in RSLogix 5000 it didnt show 88 on destination filed,

what does RSLogix 5000 show in the source field?

The RSLogix 5000 program below looks like it works as expected; I hit PrtSc when the counter reached 136 dec (= 88 hex).


(RSLogix 5000 V16 / WinXP)





I notice that in RSLogix 500 that the FRD Source is shown in BCD/Hex format, but in RSLogix 5000 it is shown in decimal


N.B. the program below is not running, which is why N7:0 is not 88.

The counter accumulator value is already is in Decimal notation. I don't know why you are trying to convert it from BCD using FRD.

If, however, you want to convert the counter accumulator to BCD, perhaps for a digital display, then you need to use the TOD (To BCD) instruction.

The counter accumulator, being a decimal number, will produce bit patterns (If you display it in Binary notation), that are NOT true BCD, for instance 0000_0000_0000_1100 = 12 decimal.

An FRD in Logix500 would detect that the 1100 part is not BCD 0-9, it would set the overflow flag, and put 32,768 into the destination.

An FRD in Logix5000 is a stupid fudge of an instruction that will successfully convert the 1100 bit pattern to 12, treating it like a HEX value.

To change the display format for tags in Logix5000, go to the tag properties (right-click the tag, choose properties), and at the bottom change the "Style" of the tag to how you want to see it.

Again, if you want to present the counter accumulator to a BCD display, then the decimal value 136 would need to be converted To BCD (TOD instruction)

daba said:

The counter accumulator value is already is in Decimal notation. I don't know why you are trying to convert it from BCD using FRD. ...

Click to expand...

Of course.


But to address the OP's query the example uses the counter accumulator to generate two nibbles that vary over time to drive the FRD. It is the behavior of the FRD that is of interest; the decimal value of the source itself is meaningless.


I originally had a program that had one rung with one FRD with 136 ([binary 1000 1000] = 0x88 = 88h) as the input bits, but that was uninteresting, so I switched to the timer+counter combination to automatically vary the bits.


As you note, the counter generates bit patterns that are not valid BCD i.e. nibbles greater than 9, which FRD converts incorrectly e.g. Source = [0100 1010] = 4Ah yields Dest = 74 ((4 * 16) + 10).


I think you (@daba) posted an FRD-equivalent AOI the other day, AIR?

drbitboy said:

I think you (@daba) posted an FRD-equivalent AOI the other day, AIR?

Click to expand...

Yes, correct ..... it's here

But I still cannot fathom why you would want to convert a non-BCD number (i.e. Decimal) to BCD - it doesn't make sense ....

Interesting that BCD has come up a number of times recently.
The conversion from BCD to integer in some circumstances will generate an error i.e. > 9, although it is possible on many platforms to reset the error to stop the PLC from faulting or generate a non BCD to integer equivalent there is a simple solution without any complicated logic. This may not suit all applications but it will allow for example non BCD > Decimal or fault conditions (PLC Faulting) without reset of the fault bit.
Just create the logic for a non BCD to enable a bit that generates a custom made fault bit and not allow the conversion i.e. The conversion stays at it's last state.
Using combination logic on one rung for each nibble i.e.
OR Bit 1, OR Bit 2, AND Bit 3 = Error, just add another branch for each nibble Daba has created an AOI but this may not be possible on some platforms, In the case as Daba correctly pointed out, where some BCD switches generate non BCD during adjustment of the switch this gets round that problem. By generating a error bit it is possible to ignore none BCD transitions.

daba said:

But I still cannot fathom why you would want to convert a non-BCD number (i.e. Decimal) to BCD - it doesn't make sense ....

Click to expand...

there is no such thing as a decimal, or even a BCD, number in a computer. there are only bits; how they are interpreted is a different kettle of fish; for example [0100 0000] is 40 BCD/hexadecimal, or 64 decimal, or the character @ in ASCII.



The OP has some bits [1000 1000] that they want interpreted as BCD. The fact that those bits, before the BCD instruction, can also be interpreted as 136 decimal is beside the point.


Being concerned about the decimal meaning of the counter accumulator bits was not part of the design choice regarding the fidelity of my model; whether it makes sense is irrelevant.

parky said:

By generating a error bit it is possible to ignore none BCD transitions.

Click to expand...

This is part of the logic in the AOI I developed

Great example of DeMorgan's laws there, between @parky's and @daba's (logically identical) examples.

drbitboy said:

there is no such thing as a decimal, or even a BCD, number in a computer. there are only bits; how they are interpreted is a different kettle of fish; for example [0100 0000] is 40 BCD/hexadecimal, or 64 decimal, or the character @ in ASCII.

The OP has some bits [1000 1000] that they want interpreted as BCD. The fact that those bits, before the BCD instruction, can also be interpreted as 136 decimal is beside the point.

Being concerned about the decimal meaning of the counter accumulator bits was not part of the design choice regarding the fidelity of my model; whether it makes sense is irrelevant.

Click to expand...

I did my best at answering the OPs original question in Post #4. I explained how the FRD instructions in the two families are totally different, in fact the Logix5000 version should be called FRH (From HEX)

daba said:

I did my best at answering the OPs original question in Post #4. I explained how the FRD instructions in the two families are totally different, in fact the Logix5000 version should be called FRH (From HEX)

Click to expand...

Hol' on there baba louie!


I'm not saying you didn't answer the OP; in fact you answered very well IMNSHO.


I'm just saying that, when running a test program, it does not matter what bits are passed in to the FRD; the result is what it is, it's only an independent test trying to duplicate or illuminate the OP's situation; that's why I did the screen dump when the Source value was [1000 1000], commonly interpreted as 136 decimal.

drbitboy said:

Hol' on there baba louie!


I'm not saying you didn't answer the OP; in fact you answered very well IMNSHO.


I'm just saying that, when running a test program, it does not matter what bits are passed in to the FRD; the result is what it is, it's only an independent test trying to duplicate or illuminate the OP's situation; that's why I did the screen dump when the Source value was [1000 1000], commonly interpreted as 136 decimal.

Click to expand...

I wasn't being fractious, I just cannot see the point of attempting to convert a non-BCD encoded number from BCD to decimal. It makes no sense mathematically.

But, as you say it may just have been a test to see the reaction of the FRD to illegal bit patterns. We will not know unless the OP visits again to give us his take ....

This is too funny. Mine was the test program.


OP started with [1000 1000] i.e. 88h, in the FRD source, and was expecting to see 88 "decimal" (1011000) in the FRD dest, but was not for some reason.