FBC after PLC5>CLX translation:

New Questions: translated FBC length.
I've recently translated a furnace program from PLC5 to ControlLogix. Daba and RonJohn helped be figure out my broken FALs(due to indirect addressing in the original PLC5 version).
I think I'm 'this close' to finishing, but at top of Alarm Collection/Alarm Build I have a FBC that does not work:

Original PLC5 FBC:
Src B63:20 (my latched alarm bits)
Ref B63:260 (my reference alarm bits)
Res N120:40
Control R66:21 LEN 320
Results R66:24 LEN 320

On CLX FBC:
*initially PCE error, it looks like FBC on CLX must be DINTs (these ranges of bits are INTs)

SO I figured I'll copy INT to DINT, then FBC, Then DINTresult back to INT)Here are the rungs:

RUNG 0=
COP B63:20 to DINT_B63_LAT length20
&branch COP B63:260 to DINT_B63_REF length20

RUNG 1=(the clx fbc)
Src DINT_B63_LAT (rung0 dint copy of my latched alarm bits)
Ref DINT_B63_REF (rung0 dint copy of my reference alarm bits)
Res DINT_N120
Control R66:21 LEN 320
Results R66:24 LEN 320

RUNG 2=
then I FAL DINT_N120 to ints N120[40] length20 (*this works and they match, remainder of code continues).

Okay, finally the actual questions:
1. I presume the length is the number of bits in the source file. So on PLC5 length was "320," I must have been comparing 20 words of 16bit INTs (b63:20-b63:39) to another 20 words (b63:260-b63:279)?

2. Is the new one wrong because now I'm FBCing DINTs and thus need to double my control lengths to 640 (20 DINT words x 32 bits)?
Doing so major faulted the CLX. Fault pointed to 'pos or len at compare control r66. I switched them it back to 320 and it cleared.

3. I've fiddled with control, how do i change the length to 640 (if that is what is nec to ensure correct fbc)?

Thanks again folks,
~JamesL

JamesL said:

Original PLC5 FBC:
Src B63:20 (my latched alarm bits)
Ref B63:260 (my reference alarm bits)
Res N120:40
Control R66:21 LEN 320
Results R66:24 LEN 320

Click to expand...

It helps if you look at the bit addresses for Source and Destination, rather than the Word addresses, because the LEN parameter is the number of bits.

i.e. It compares the 320 bits in B63:20 thru 39 (B63/320 thru B63/639 - to the bits in B63:260 thru B63:279 (B63/4160 thru B63/4479)

JamesL said:

On CLX FBC:
*initially PCE error, it looks like FBC on CLX must be DINTs (these ranges of bits are INTs)

Click to expand...

Yes, Source and Destination must be DINT array tags...

JamesL said:

RUNG 0=
COP B63:20 to DINT_B63_LAT length20
&branch COP B63:260 to DINT_B63_REF length20

Click to expand...

Your LEN is wrong, the COP instruction LEN is the number of elements of the Destination, and it automatically calculates the number of bytes to copy from the Source as the number of bytes of the destination data-type (4) multiplied by the specified length (20). That will attempt to copy 80 bytes from the Source to the Destination, which is 640 bits, not 320.

Since your Destination will have to be a DINT data-type, the LEN for the COP needs to be 10.

In your case, nothing untoward will have happened, because the processor will stop copying when the destination array end is reached, but it is not good practice to rely on this trait.

JamesL said:

RUNG 1=(the clx fbc)
Src DINT_B63_LAT (rung0 dint copy of my latched alarm bits)
Ref DINT_B63_REF (rung0 dint copy of my reference alarm bits)
Res DINT_N120
Control R66:21 LEN 320 POS 0
Results R66:24 LEN 320 POS 0

Click to expand...

Looks OK, but you need to specify POS initial condition, as I 've added above.

JamesL said:

RUNG 2=
then I FAL DINT_N120 to ints N120[40] length20 (*this works and they match, remainder of code continues).

Click to expand...

Why not use COP instead...
COP DINT_N120[0] N120[40] LEN 20


.... to be continued

JamesL said:

Okay, finally the actual questions:
1. I presume the length is the number of bits in the source file. So on PLC5 length was "320," I must have been comparing 20 words of 16bit INTs (b63:20-b63:39) to another 20 words (b63:260-b63:279)?

2. Is the new one wrong because now I'm FBCing DINTs and thus need to double my control lengths to 640 (20 DINT words x 32 bits)?
Doing so major faulted the CLX. Fault pointed to 'pos or len at compare control r66. I switched them it back to 320 and it cleared.

3. I've fiddled with control, how do i change the length to 640 (if that is what is nec to ensure correct fbc)?

Click to expand...

A bit mixed up, as LENgth is dependant upon the instruction it is used in.....

1 (and 2 !!). FBC LENgth is the number of bits to compare, which doesn't change whether you are in PLC5, SLC or Logix5000. The number of bits is the same in the source and reference files.

(and 3 !!) FBC length is 320 bits, regardless of data-type where the bits are stored.


Hope this helps....

Thanks again Daba

daba said:

A bit mixed up, as LENgth is dependant upon the instruction it is used in.....
1 (and 2 !!). FBC LENgth is the number of bits to compare, which doesn't change whether you are in PLC5, SLC or Logix5000. The number of bits is the same in the source and reference files.
(and 3 !!) FBC length is 320 bits, regardless of data-type where the bits are stored.

Hope this helps....

Click to expand...

Daba,
Yes, absolutely this is helpful!!
This is a tough way to learn PLCs, so I really appreciate your explanations. I'd hop to UK for your training if the boss would spring for airfare!
I'll tweak my code in the morning and let you know how things go.
Thanks again,
James

daba said:

A bit mixed up, as LENgth is dependant upon the instruction it is used in.....
1 (and 2 !!). FBC LENgth is the number of bits to compare, which doesn't change whether you are in PLC5, SLC or Logix5000. The number of bits is the same in the source and reference files.
(and 3 !!) FBC length is 320 bits, regardless of data-type where the bits are stored.
Hope this helps....

Click to expand...

Daba, I think it's working! I toggled a severe alarm bit, got the appropriate abort, and the correct alarm info made it to Scada.
See the attached .doc to see the original PLC5 3 rungs, the initial plc5>clx translated FBC, and then the just tested current CLX rungs. Please take one more look and see if you think it looks like it's doing the same job.
Notice the XIC XIO in Rung4 that sets the 'new alarm' bit, why is the translation so convoluted? Does it work the same way?
Thanks,
James

JamesL said:

Daba, I think it's working! I toggled a severe alarm bit, got the appropriate abort, and the correct alarm info made it to Scada.
See the attached .doc to see the original PLC5 3 rungs, the initial plc5>clx translated FBC, and then the just tested current CLX rungs. Please take one more look and see if you think it looks like it's doing the same job.
Notice the XIC XIO in Rung4 that sets the 'new alarm' bit, why is the translation so convoluted? Does it work the same way?
Thanks,
James

Click to expand...

I believe it is because the translation tool has translated the original binary files into INT files in the CLX. That is why those XIC and XIO have convoluted array indices, accessing word/bit equivalents in the INT file B63, against the original "bit number" in the PLC5 Binary file.

daba said:

I believe it is because the translation tool has translated the original binary files into INT files in the CLX. That is why those XIC and XIO have convoluted array indices, accessing word/bit equivalents in the INT file B63, against the original "bit number" in the PLC5 Binary file.

Click to expand...

Ahhhh, I think I know what you mean. I thought it might be because they where originally translated to dints from ints, but I changed them back (any thing scada was looking for). Alas I'm a rookie and would probably not do that the next time around, but they otherwise work.
I tried simplifying them like the original plc5 instruction, but the CLX would not take them. I suppose if they are responding the same as before then it's all good.

Anyway, I did get the alarms I triggered, so it seems to be working, so thank you for all your info/examples. A little more testing and I'll feel more certain.

I'm working on the slow PC / PLC performance with my ftp fetching at the end of cycle (there's a vb program that grabs all the alarms & machine data at the end of the cycle and puts it in Oracle. It 'works' it's just very slow. I've been tweaking the vb, addressing etc. Maybe there is something on the CLX that needs to be optimized as well...