CLDs Download from Controller to EWS
Voted best answer
In addition to Rob's comprehensive post
1.) Make sure that you are using the "right" project. The changes were most likely made with Composer so maybe the "right" code is in a backup somewhere. Best case, if you find the CLDs in another copy of the project and they verify OK you can either move the sheets to your project or copy the configuration manually. Much quicker than building CLDs from .cfg files.
2.) Save the controller configuration into Composer. Give the .cfg file a unique name so that it won't get overwritten by a compile. This gives you a backup in the event the controller fails in the interim as well as a snapshot of the controller configuration for reference.
3.) Verify, verify, verify.
As Rob mentioned use the verify to make manual changes and then finish off with a verify with upload specs option to upload specification changes from the controller to the CLDs. However, this needs to be done with some care to ensure that specs in the controller are the "right ones".
You didn't mention what type of differences you have so taking it from the top.
Blocks that change their specs during "normal" operation.
FC68, S4 and FC117/118, s1 through s10 can and do change during normal operation of the plant and can often be uploaded from the controller directly to the CLDs with a final verify, upload specs operation. This statement depends on how your site uses these function codes.
Other spec changes
Most other spec changes can be uploaded but obviously the differences should be understood before doing so.
Beware of uploading changes to FC50 (on/off, s1), FC110/111/112 (rung block, S1), enhanced IO override enable specs and anything else that might have been used as a force, bypass or temporary workaround applied by others. Once the differences get uploaded they become invisible in Composer.
Another way to do spec changes is to open the CLD, start monitoring and then double click on the affected block. The dialogue box will pull the specs from the controller and update the specs on the CLD. Once all the affected blocks have been done on sheet you can simply save and move to the next CLD. Personally I prefer this method as it gives a better picture of the impact of the change. It also allows changes to be made gradually, wheras the verify, upload specs option does the entire controller at once.
Signal connection changes
Signal connection changes cannot be uploaded into the CLDs with the verify, upload specs operation and have to be manually updated in the CLDs.
Missing / Extra blocks
Any missing or extra blocks have to be manually edited in the CLDs.
With the ABB Engineering tools (not sure if you are using Composer or S+ Engineering), there is not a way to have the system automatically "reverse draw" the logic from the controller into CLD documents or automatically update your drawings. What you need to use the is the Verify feature, which I am guessing that you are already using, based on the fact that you mentioned that you know that there a number of differences between the CLDs and the module. What you need to do is use the Verify feature to compare the CLDs to the module and identify the differences and then based on the report, make the changes manually.
Now there are a few things that can be automated, such as updating of specs in the CLDs based on the information in the drawings.
Our typical procedure is the following.
1. First, as the controller logic is what is installed and running the plant, we assume this to be the defacto baseline standard and correct.
2. We run a Verify of the CLDs vs. the Controller and turn on the "update" specs feature. This will basically update all FC specifications in the CLD, with the exception of the signal connections between blocks, to match what is running in the module. This Verify will tell you all the differences in specifications as well as Function Code/Block differences between the Module and CLD.
3. We then re-run the same verify, now that the specs have been updated, to identify the differences that could not be resolved by a specification update.
4. Based on the differences found, we make any required changes (e.g. FC additions/delections, etc). To get the CLDs to match the module. We will continue performing verifies until the two match.
1. As the Verify of the CLD vs. Module does not actually tell you differences in signal line connections, at least not as far as we are aware, once the CLD vs. the Module match...
5. We compile the CLDs and generate a new CFG file.
6. We then Verify the Module vs. the new CFG file. This will now tell us any differences in signal line connections found.
7. Based on the results of the Verify between the Module vs. the new CFG file, we update the CLD files and recompile and run another Verify of the Module vs. CFG file.
We continue step 7 until the CFG and the module match, at which point we know that the CLDs, the CFG on the EWS and the module all match.
Typically, we normally only run four Verify operations, two CLD vs. Module and then two CFG vs. Module to get everything to match.
I hope that this helps.
Thank you Rob & Alan for your detailed ansewer.
We are using composer as engineering software.
See Picture 1 attached, We received a CIU Error 105 on a block. Then we compared the logics and found 502 errors between controller and EWS (See Pictures 2, 3 and 4).
Now we want to equalize the logics. As per my understanding the plant is running on the logic in controller and we are not facing any issues, means the logic in controller is working well.
We can update the sepcs difference as you mentioned by checking the UPDATE as mentioned by you.
Now a few questions;
Please review the attached pictures and guide us how we can do better?
What is the Error "CIU Error 105" means?
How to add the block in CLDs that are available in controller but not in CLD? How to verify these blocks specification, signal lines of these blocks?
Is there any method to download a single CLD? rather than downloading the whole controller.
Error 105 is undefined block number, the block number is valid but not found in the controller. In the case of picture1.jpg, block 8506 is the CLD but not in the controller itself. You will need to add the block and signal connections to make the CLDs match the controller.
Do you use the version management feature in Composer? Could old / uninstalled versions of CLDs have been made active? If so the correct CLDs might be still be in the project.
First off, looking at picture3.jpg you have block 7238, a FC216
S1 is the slave address and has 29 in the CLD but 1989 in the controller, which is outside of the acceptable range (0-63).
S3 is the channel number and is 15 in the CLD and 135 in the controller (1-16 is acceptable).
S4 is 22 in the CLD (DIN PT100) and 8 in the controller (Chinese type S).
S11 is the A/D precision and has 20 in the CLD and 71 in the controller, which is outside of the acceptable range (16-24).
Other specs that have 0 in the CLD have seemingly random numbers in the controller.
The spec data from controller for this block appears to be junk, and I would be reluctant to just update the CLDs without understanding more about why the controller has these spec values for some blocks.
You could a.) inspect the block properties from the CLD and see if you get the same data as the verify provided and b.) Perform a block details from the HMI, again to see if the data is the same. This will prove the communications was not corrupted during the verify.
Have you verified other controllers in the project? It would be good to confirm that any issue is just with the one controller and not with the entire project.
You could also try saving the controller configuration (Runtime>Save from Controller>Create New) to Composer and then verifying between this saved configuration and the CLDs.The verify output should be the same as when verifying with the controller directly.
If you are happy to use the controller configuration as the master configuration...
EXTRA BLOCKS are in the controller but not in the CLDs.
This is fairly straightforwards to fix.
a.) Add the blocks to a CLD.
b.) Run another verify and this will then tell you how to connect the EXTRA blocks just added. Connect as per the second verify report and then verify again.
c.) Once you have the blocks and signal connections you can determine which CLD to move the logic to.
MISSING BLOCKS are in the CLDs but not in the controller.
These blocks and associated signal lines can potentially just be deleted from the CLD.
Remember to backup regularly during the process.
Try one or two changes at a time and save the verifies. Use a file compare utility on teh verify reports to confirm the changes made.