Controllogix Copy or Move Size

[daba]

RES on the CONTROL tag of a FAL performs exactly the same actions as "Enable-In False" condition.

All control bits are cleared, and the .POS value is reset to zero.

The choice of whether to use RES or XIO Control.DN boils down to whether you need the instruction to operate every time it is scanned.

Using XIO of the .DN bit to perform an instruction reset, means that the instruction will not operate again on that scan, but will have to wait until it is scanned once more to "Enable" it again. This means a FAL in "ALL" mode will only operate every alternate scan.

 

[NetNathan]

Good explanation...thanks Daba
The FAL is moving a set of bits in a DINT Range to a set of bits an INT range for reading into the FIX32 HMI, with an ABR IO server that will not accept a DINT.
Alternate scans will by far be sufficient.

The fact that it appears the PLC5 to Controllogix conversion decided to change all the INTs to DINTs (Is this true?) has caused a few nightmares on this job....

This logic was originally built by a "group" of engineers that were assigned to develop a certain routine. Then the routines were then blended together, so here is all sorts of "mapping". 32 Routines total to control the equipment.

The alarm bits (about 200, broke in Severe, Critical and Warning groups) are moved to one routine for the Panelview, then the groups are moved from there to an area that does a bit test for new alarms.
Then moved to an area and routine where they are moved to the FIX32 HMI.
Then moved to another "collection" area routine where they are stored till the Fix32 HMI confirms they have been received by the Oracle server.
The after a BIT test confirms they are in the "collection" they are cleared from the previous registers and the process starts over....When a BIT test finds a new alarm.
All this is also blended with logic looking for if they are acknowledged or not by either the Panelview or from Fix32..
Arghhhh....
Somewhere in this series it is broken, because the alarms are not making into the 'collection' registers.

And on top of this.... it is my FIRST Controllogix platform and minimal knowledge of PLC5.
Now you now why I have been asking a few questions recently.
This forum has been an unbelievably great help.

 

[OkiePC]

The fact that it appears the PLC5 to Controllogix conversion decided to change all the INTs to DINTs (Is this true?)

I am not sure if it does that 100% of the time, having never used the utility in a real world case. The reason for this is because the 32 bit processing in Logix5000 processors handles DINTs more efficiently than it can handle INTs. At least that is the explanation I have been given.

I have had to chase problems in complex systems designed by teams that made them much more complicated than necessary. I recall one system that was a mix of PLC-5 and SLC controllers with RIO connections. A proximity switch failed. We chased the logic through no less than 7 layers of interfacing bits including some which were buried in the PLC-5 scanner settings (who knew you could assign a rack value in a scanner to an integer file to pull in real I/O from another processor?) before we were able to find out what the cause was. What should have taken 30 seconds took two hours. This was on a working system after it was running for a year or so.

I am sure the design team job was made simpler with all the extra files and interfacing logic to tie all the individuals' work together, but the time they saved was likely lost in the first few years due to increased downtime and head scratching.

It sounds like you are getting a handle on things, though, and this forum is a great place to lean on for help.

And another bit of advice if you find yourself stuck... Figure out what the intended results need to be for your broken stuff, and then just rewrite those parts.

Paul

 

[cwal61]

Take a look at the BTD Instruction (Bit Field Distribute) it would Accomplish the Same Thing. It would require more lines of code but it is an alternative method that you may find useful at some other time.

 

[daba]

Take a look at the BTD Instruction (Bit Field Distribute) it would Accomplish the Same Thing. It would require more lines of code but it is an alternative method that you may find useful at some other time.

NetNathan said that his original INT's were all values no greater than 32000, and no negative values, so in this case BTD could be used to map the lower 16 bits of a DINT into an INT, but that is exactly what a MOV would do under those circumstances. MOV would be cheaper than BTD.

However, if all 16-bits of the PLC5 INT were used (someone mentioned Alarm bits?), then the conversion of PLC5 INTs to Logix5000 DINTs would have moved bit 15 up to bit 31 in the DINT, to preserve the sign of the INT when converted. That would completely screw things up big-time, and only a MOV DINT to INT would restore the original bit pattern.

Best bet is to reduce the newly created DINT arrays back to INT arrays, simplest all round I believe.

 

[NetNathan]

NetNathan said that his original INT's were all values no greater than 32000, and no negative values, so in this case BTD could be used to map the lower 16 bits of a DINT into an INT, but that is exactly what a MOV would do under those circumstances. MOV would be cheaper than BTD.

However, if all 16-bits of the PLC5 INT were used (someone mentioned Alarm bits?), then the conversion of PLC5 INTs to Logix5000 DINTs would have moved bit 15 up to bit 31 in the DINT, to preserve the sign of the INT when converted. That would completely screw things up big-time, and only a MOV DINT to INT would restore the original bit pattern.

Best bet is to reduce the newly created DINT arrays back to INT arrays, simplest all round I believe.

Originally, in the PLC5, they were COP instruction of INT arrays to INT arrays.

That is what is now being done with the FAL instructions.
Moving DINT arrays to INT arrays (ie....Dint [100] into INT[200])
BUT.... I am occasionally getting an overfow on the FAL.
The problem seems to be that if enough bits are set to 1 then the INT goes into overflow, because the BIT total adds up to over 32,767.

Originally, in the PLC5, they were COP instruction of INT arrays to INT arrays.
I believe the problem with the overflow even existed with the PLC5 but a COP will not show an overflow...correct?

The BTD is used to look for new alarms (Bit =1) and no alarms (BIT=0) as they are moved, or permitted to be moved, to the different arrays.
This function is performed on 3 different arrays of "alarm groups" (Severe, Critical, and Warning alarms). However all the alarms are moved to sequential DINTS or INTS for the test. N67 is an INT [800] where the alarms bits finally end up as they are shifted to different POS areas by the FAL according to what "alarm group" they belong in.

 

[daba]

NetNathan, I believe that bit 15 of the PLC5 INT is being used...

An "overflow" (and "negative") will be generated by the FAL if bit 15 is set in the DINT that is moved into the INT, because the processor sees the destination as only 15 bits long, and the conversion of 2#0000_0000_0000_0000_1000_0000_0000_0000 (32768) generates 2#1000_0000_0000_0000 (-32768) in the INT.

Clearly this is incorrect numerically, but the bit patterns are replicated in the destination anyway. You can ignore the overflow in this case.

The picture shows two FALs working... the first moving only the first 4 DINTs to the INTs, the second moving all 5.

Overflow isn't generated by the move of the 0111_1111_1111_1111 bit pattern, because that is 32,767, and can be stored successfully into an INT. However, the second FAL generates overflow as it tries to store 1111_1111_1111_1111 (65,535) into an INT. Although it does move the bits, the instruction says "something is wrong".

And yes, you are correct, COP does not affect the Arithmetic flags.

 

[cwal61]

Daba, could you Make A UDT thats has 16 Bools? Basically making what some other type processors consider a UINT. (Unsigned INT)

I guessing it wouldn't work for a FAL but maybe the MOV?

 

[daba]

Daba, could you Make A UDT thats has 16 Bools? Basically making what some other type processors consider a UINT. (Unsigned INT)

I guessing it wouldn't work for a FAL but maybe the MOV?

No, I don't think it would work for either, and making UDTs here is further complicating it.

If I am right, and the original code used all 16-bits of the INT as alarm bits (and I can't think of a reason why the programmer wouldn't have used them all), then, as I stated above, the FAL from DINTs to INTs is OK, the bit pattern is replicated, and the overflow caused by the potential sign-change, is insignificant.

However, to avoid future complications, and possible misuse of "unusable" bits in the DINTs, my recommendation would be to change the data-type of all the alarm files back to what they were programmed in, INT data-type. Having done that, all the FAL instructions can be replaced with COP instructions, since we are only interested in bit locations.

COP works much faster, because it doesn't have to look at data-types at all, just copies byte-by-byte until the number of bytes specified by the destination data-type byte count x the Length specified in the COP instruction.

 

[daba]

All of the preceding discussions have come about because of the aggressive nature of the PLC5 to Logix5000 "conversion" that A-B have provided.

Yes, it will convert INT arrays to DINT arrays, and I cannot explain why.

Agreed, the 32-bit DINT data-type is the most efficient to use. But a conversion should replicate the original data-type, giving a warning if it wants to. Considering a modern Logix5000 processor scans logic at a much faster rate than a PLC5, any "loss" due to converting directly to the smaller, less-efficient data-types INT and SINT, is far far outweighed by the huge speed increase offered by the Logix5000 processor.

There are several things that makes "conversion" a risky game. Yes it can be a good starting-point for completing a program in Logix5000, but in no way can it be considered to be the only job necessary.

I would always advocate that the new program is checked thoroughly after conversion, preferably by someone experienced with Logix5000.

 

[NetNathan]

After further evaluation of the amount of INTs needed to talk to the FIX32 system and also the problem with the DINT to INT conversions not lining up the bits sequentially in the Alarm and Data collection logic...also accessed by the FIX32 system....
We have resorted to changing the DINTs back to INTs, only if they are accessed by the Alarm or Data handling logic or the FIX32 system.
So most of the FALs will be changed back to COP. for moving the arrays.

 

[daba]

After further evaluation of the amount of INTs needed to talk to the FIX32 system and also the problem with the DINT to INT conversions not lining up the bits sequentially in the Alarm and Data collection logic...also accessed by the FIX32 system....
We have resorted to changing the DINTs back to INTs, only if they are accessed by the Alarm or Data handling logic or the FIX32 system.
So most of the FALs will be changed back to COP. for moving the arrays.

As it was, worked.

My case, rested here....

Using the conversion tool is not always going to give you a working program, it has absolutely no idea what you are doing with your data, it cannot analyse your code, it just converts what it sees, to the larger platform.