In my effort to migrate an SLC program to ControlLogix, I am utilizing the saveas->.acd command while also disabling the aliasing option. However, I have encountered a significant challenge during the conversion process. Many tags are being mistakenly converted into aliases. While N7:1 is properly translated to N7[1], N7:21 is transformed into N7_21 and then aliased to N7[21]. I am in need of a solution to prevent this unwanted aliasing behavior or to efficiently unalias them collectively, if feasible.
I had to go through this process a few times. I used to perform the AB conversion like you did, then export to L5K. I had an excel spreadsheet with both old N7 tags and new tags, which were converted from the comments on the N7s, displayed on one screen. I meticulously went through the process of finding and replacing the L5K in notepad++. Even though this was done a while ago, the reason I preferred editing the L5K file was that upon re-importing, the tags were no longer aliased tags, making the tag creation and tag value conversion much cleaner, as opposed to just the rung content. In general, I have a strong preference for the export/import method. Interestingly, none of the highly experienced engineers I collaborated with at the time were aware of a truly seamless way to convert programs.
No offense, but as an integrator, and especially as a customer, I would strongly dislike any conversion resulting in B, N, and T arrays. The conversion tool provided for migration by AB was severely lacking. I refuse to use it. I prefer to rewrite the code with proper user-defined types (UDTs) and organized tags to avoid creating a program that is hard to maintain and troubleshoot. While it may seem like a simple customer request, sometimes it is necessary to guide them towards a better solution, preventing potential issues down the road.
Robertmee expressed concerns about the use of conversion utilities that result in arrays like B, N, and T arrays. He believes that rewriting code using proper UDTs and organizing tags is a better approach than creating a difficult-to-maintain program. While it may initially seem like a customer-driven request, it is essential to guide customers to avoid potential pitfalls in the long run. Robertmee also highlighted the need to properly convert the program to facilitate batch tag name changes, which is the first step in the process. Additionally, he mentioned the challenges posed by the original programmer's heavy use of indirection and indirect referencing of filenames. It is crucial to address these issues as the customer seeking these modifications is Robertmee himself.
My most recent major migration involved transitioning from PLC5 to ControlLogix. During this process, I encountered numerous outdated remnants from previous migrations, such as from PLC2 to PLC5. To ensure a smooth transition, I meticulously transcribed the code with more detailed subdivisions than before. This meticulous approach proved to be successful. I have come across programs in the past that were difficult to troubleshoot due to the use of N7[x] arrays. I commend your decision to treat the migration tool as a preliminary step that requires cleanup before deployment. Your future self, as well as your customers, will appreciate the effort.
It's evident that not all aliases were created, as only some were set up. Unlike SLC and PLC5, CLogix lacks the ability to handle certain indirect addressing methods. For instance, the syntax N100[N7[21]] is incompatible with CLogix. However, using N100[N7_21] is approved, and as long as N7_21 is linked to N7[21] as an alias, any logic related to N7[21] within an array will still function. The conversion process must be comprehensive and address all scenarios. In CLogix, it's not possible to jump between different parent arrays using indirect addressing, necessitating additional code. For example, #N[N7:22]:0 doesn't have a direct equivalent in CLogix, so a PCE instruction will be substituted with a comment during the conversion process.
From my experience, there seems to be a limit in the translated tag array size when migrating from SLC to ControlLogix, which might be why you're seeing that issue with N7:21 becoming alias N7_21. To fix this, I'd suggest splitting the larger arrays into multiple smaller ones before running the translation. After this, further aliasing issues should cease. I hope this helps, and good luck with your project!
I've faced similar issues in the past and it can be quite frustrating. Try a two-step approach: first, convert the program to RSLogix 5000 - version 20, and then import it into Studio 5000. In my experience, doing it this way tends to reduce the anomaly of unwanted aliases. Also, you can look into a brilliant tool called Alias for RSLogix 5000, which can help further streamline the process. Remember, the key is to have a systematic, rather than ad-hoc, approach when handling mass aliasing issues. Hope this helps!
It sounds like you're dealing with a tricky migration! One potential solution to prevent unwanted aliasing is to double-check your tag naming conventions in the original SLC program. Simplifying or standardizing the way you name tags might help ControlLogix interpret them correctly during the save-as process. If you're still having issues, you could consider using scripts to batch rename or replace the aliases post-conversion, as that might save you a lot of manual effort. Also, don’t forget to explore the settings in your software to ensure that there are no other auto-aliasing options enabled that could be causing this. Good luck!
It sounds like you're dealing with quite a headache during your migration! One thing you might want to try is checking if there are any specific settings in the import/export options that can be tweaked to handle these tag conversions with more precision. Sometimes, adjusting the import template can help prevent unwanted aliases from being created. If that doesn’t work, using a script to bulk rename or unalias them in the ControlLogix environment could save you a lot of time—just be careful to test on a backup first! Good luck!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: - To prevent unwanted aliasing during the conversion process, ensure that the aliasing option is disabled. This can help avoid tags being mistakenly converted into aliases.
Answer: - One common reason for tags being mistakenly converted into aliases is the presence of colons in the tag names. For example, N7:21 may be transformed into N7_21 and then aliased to N7[21].
Answer: - Unfortunately, there may not be a direct method to unalias tags collectively after the conversion process. However, you may need to manually review and adjust the affected tags to correct any unwanted aliasing behavior.
Answer: - When migrating programs between SLC and ControlLogix platforms, it is recommended to avoid using special characters like colons in tag names to reduce the chances of aliasing issues. Additionally, double-checking the conversion settings and ensuring the aliasing option is disabled can help prevent unwanted aliasing behavior.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.