After analyzing TN 50182, it appears that while it hints at subroutines not quite matching up to AOIs in terms of "Data Encapsulation" and "Execution Performance," the superiority of AOIs is still evident. Despite the lack of a clear answer from the chart, I have decided to continue using AOIs for now. The workaround for online editing by partially importing subroutines can lead to clutter and confusion, unlike the seamless process with AOIs.
The comparison between AOIs and the latest subroutine technology in Logix highlights a potential inferiority of subroutines. However, the transformative impact of AOIs and UDTs on programming, leading to object-oriented programs and positive feedback, cannot be denied. Although the Design Considerations document may seem outdated, the comparison on page 49 emphasizes the advantages of AOIs.
While considering the appropriateness of using AOIs and subroutines, the focus remains on the comparison between the two technologies in Logix. The goal is to determine if subroutines are still inferior to AOIs. A detailed analysis to provide a clear comparison and contrast statement is what is desired to avoid wasting time on potentially inferior technologies.
Exploring the latest feature- the new feature is so fresh that very few people have hands-on experience with it so far. It might be difficult to find a definitive answer to your query, especially on this forum. Your approach of organizing everything into different AOIs is unique, making it a bit challenging to understand your exact focus. Are you essentially comparing a Program to an AOI? Considering that Programs offer tags and logic that can be created modularly, it seems more fitting. On the other hand, routines mainly consist of logic without the ability to pass parameters in and out. The new Program Parameters feature appears to facilitate direct interaction between programs, allowing data mapping similar to an AOI. Previously, controller scoped tags were necessary for programs to communicate as program scoped tags are limited to the program itself. By using a "program scoped tag" and linking it to a "controller scoped tag," the benefits of program tags and global communication of controller scoped tags could be combined. Based on my understanding, Program Parameters aim to eliminate the need for controller scoped tags. While I lack practical experience with this feature, it's worth exploring Lab #3 for further insights: [link to lab guide].
Thank you, Paully, for your input. However, the answer to your question in the second paragraph is negative. I am specifically looking for a comparison between routines and AOI, rather than programs and AOI. I appreciate your insights and information but I am eager to hear from others on this topic. If no one is able to provide the comparison I am seeking, I will conduct the analysis myself once I have access to the internet and share my findings online.
williamlove mentioned that if no one else is able to accomplish it, they will take on the task themselves once they have access to an online system. They will then share the outcomes of their efforts. In the meantime, interested individuals can refer to the Logix5000 Controllers Program Parameters document at the provided link for more information.
Also, check out: Publication 9324-WP007A-EN-P from August 2015 protected by copyright.
After testing it on a live system, I promised to provide an update on the topic. The focus here is on scenarios involving 20 burner sequences and the preference for creating a single routine instead of multiple routines. The options include writing twenty routines with direct addresses, using indexed addressing, implementing parametrized subroutines, or utilizing an AOI.
1. Twenty direct address routines: Although beneficial for logic monitoring and enabling online editing, creating and maintaining multiple routines can be time-consuming. This disadvantage becomes more evident when dealing with a larger number of routines.
2. Indexed Addressing: This method, used by me two decades ago, involves calling the routine with a set index, incrementing it, and repeating the process until all cases are handled. While simple, it lacks the visual clarity of normal logic and requires indexing for local variables like timers and one shots.
3. Parametrized Subroutines: Despite initial hopes of matching AOI functionality, this method fell short in comparison. After in-depth exploration and practical testing, it was deemed inferior to AOI due to the blurred representation of cases in the logic.
4. AOI: The advantages of AOI include ease in managing common local variables and the ability to monitor logic for specific cases. Online editing limitations can be addressed by importing changes under a different name, although it may lead to clutter until offline cleanup and download.
In conclusion, while each method has its merits, the choice ultimately boils down to personal preference. Evaluating these options can assist in determining the most suitable approach for efficient and effective programming.
Hello, it's me again. Thank you for providing an update, it's always great to see things come full circle. Have you considered using multiple programs for your comparisons? While you mentioned subroutines and parametrized subroutines, a program is more akin to an AOI in achieving your goals. As far as I know, Programs have the new parameter feature, not subroutines. However, subroutines within a program can utilize this feature. I'm looking to align my thought process with yours.
Moving forward, I have experience with various batching systems that involve repetitive logic. Each batch tank has a unique sequence, similar to your burner scenario. For instance, if I need to add a raw material to a tank, the sequences and local tags remain the same, with the only difference being how they connect to the physical IO. In my opinion, programs and AOIs share many similarities with some notable distinctions.
AOIs can be instantiated while programs cannot. Programs can have multiple subroutines, whereas AOIs cannot. Programs support online edits, unlike AOIs. However, I find programs to be equally modular. You can create one program, test it, export it to a .L5X file, import it back into the logic, and modify the references to create additional logic.
Although it may involve a few more steps compared to using AOIs, it offers a better option for maintaining online edits instead of importing new AOIs. Ultimately, it comes down to personal preference. If your equipment varies, making minor adjustments in the program is easier than creating a new type of AOI or configuring bits within an AOI to activate/deactivate logic based on the differences.
Consider the complexity of the logic. In batching, organized subroutines are necessary to keep the logic coherent, which is not an option within an AOI. However, if the logic is straightforward, the additional subroutines in a program may not be significant. I hope you don't mind me bringing up these additional discussion points.
Paully, I will outline my system briefly before posing a question related to your response. I encourage you to review the details provided, with the question clearly stated in the final paragraph for quick reference.
In my process, a unique slurry and sand mixture is applied to a wax impression to create molds. Each mold follows the same logical sequence, with variations in the dip tank, sanding method, and drying time. While most molds undergo about ten rounds of dipping, sanding, and drying, some may require up to 50 dips. The system can accommodate up to twenty molds simultaneously, sharing equipment such as robots and conveyors for mold storage during different stages.
The crucial aspect of my system is the dip sequence, which I have incorporated into a subroutine/AOI. This sequence consists of steps where one mold is actively undergoing a dip while others are in the drying phase. When a robot is available, a mold that has completed drying can initiate the next dip cycle, with the subroutine/AOI resetting to the first step. The only time the subroutine/AOI is inactive is when no molds are present.
The efficiency of the AOI is evident as it simplifies the process and allows for seamless execution. With only one routine to manage, I am exploring options for incorporating a subroutine that can be applied to all twenty or fifty molds without the need for extensive edits. If you can provide insights on achieving this, I am eager to experiment with it in a mockup scenario. However, if it necessitates maintaining multiple programs, it may not be feasible.
Thank you for your assistance.
While the advantages of utilizing AOIs over subroutines are valid, in the automotive industry, it is generally frowned upon to use AOIs instead of subroutines or programs due to the inability to edit them online. I have personally experienced this when using an AOI as a custom instruction for controlling air cylinders. The customer requested a discreet approach because the line support staff was uneasy about not being able to make changes easily. As a solution, I replaced each AOI with discreet logic in a subroutine for each air cylinder. This did increase memory usage, but the customer prioritized simplicity and accessibility to the logic. In many cases, customers prefer the Keep It Simple, Stupid (K.I.S.S.) method.
Thank you for sharing your insightful follow-up, it really got me thinking about some interesting ideas!
williamlove shared that they have implemented a dip sequence in a subroutine/AOI, consisting of a set of steps. While one mold is actively progressing through its dips, the rest are in the drying stage of their respective dips. This process involves all molds being active, with one mold undergoing more changes while the others are running a lengthy timer in their final step. When the robot is available, a mold that has completed drying can request the robot to initiate another dip by incrementing the dip number and restarting the subroutine/AOI from the beginning. The subroutine/AOI remains inactive only when there are no molds present.
In a similar scenario, the decision to use an AOI may seem straightforward, but factors like potential sequence adjustments could lead to hesitation. The challenges faced with batching applications parallel this dilemma, as modifying identical subroutine logic across multiple PLC programs can be time-consuming. However, with local program tags and strategic copy & paste methods, the process becomes more efficient. By updating logic in one program and propagating it across others, the use of aliased tags simplifies the task and ensures proper functionality. While this approach may require additional time for updating multiple programs, the flexibility it offers outweighs the inconvenience. Ultimately, the choice between using an AOI and manual editing depends on the project requirements and associated risks.
The content has been removed, please refer to the following response for further information. Thank you.
Upon initial review, I was initially confused by your response regarding the advantages of separate programs over separate routines. However, upon further reflection, I began to see the benefits of reusing logic with the same tag names within a localized program scope. Currently, my Add-On Instructions (AOIs) have been well-received. My standard practice involves labeling AOIs with a revision number, such as Mold001, and incrementing it whenever edits are necessary online. This process helps maintain clarity within the group, as the highest revision number indicates the latest version. When it comes time to download, we clean up the clutter by removing older revisions and reverting back to the original revision number before downloading. My next preferred approach would involve utilizing classic subroutines with indexed indirect addressing. If I were required to review the logic for each instance individually and prohibited from using AOIs, I would consider implementing your suggested method. Thank you for providing clarification on this matter.
Hey William, I really appreciate the innovative approach you've taken with online modifications to AOIs. The ability to monitor individual instances is a fantastic feature that I find very useful. However, up until now, I've only been able to implement them in "stop-start" scenarios with individual machines where controller interruptions are not a concern. This seems like a great solution for making real-time adjustments.
UPDATE: Following my experience with a startup, I cannot recommend using AOIs for logic that may need to be adjusted quickly. While AOIs are great for monitoring duplicate units and troubleshooting individual instances, the inability to edit them online can cause issues in time-sensitive situations. I learned this the hard way during the startup process. Even simple tasks like a motor start routine can become risky without the ability to make changes on the fly. Converting AOIs to an alternative proved to be too time-consuming for me at that point. However, as I plan to double the number of units in the future, the AOI's value will be showcased by the ease of making changes. Unfortunately, not everyone appreciates the benefits of using AOIs, and I have been labeled as an elitist programmer for my preference for them. Until the capability to edit AOIs online is available, I will avoid using them for complex logic that may require adjustments during production.
AOI's are highly effective for handling small, static sections of code. I find them useful for tasks like motor starter logic and MOPs. However, it's crucial to avoid using them as a replacement for editable control subroutines.
I found this conversation very insightful. One challenge I face regularly is the inability to edit online efficiently, as well as the uncertainty of who will need to decipher the information after I pass it on. However, certain topics are demanding to be summarized for better understanding and accessibility.
I rely on AOIs for consistent and static code, such as the company calendar and a separate logic clock. For all other tasks, I utilize subroutines for greater flexibility and efficiency. This approach helps me streamline my programming process and enhance overall system performance.
Utilizing indexed addressing can be more effective when dealing with structured data, such as ons and timers. However, it may not be suitable for control data types, as they do not function well as arrays. In my programming routine, I incorporate structured data as parameters within my subroutines. The inputs and outputs are placed into predefined spaces within the structured data, which serves as the subroutine's parameters. Upon completing the subroutine, I retrieve and return the parameters. This method allows for bi-directional parameter handling both within and outside the subroutine. For more complex processes, I often rely on sequence step or state logic. Some processes necessitate the retention of state information for each scan cycle, adjusting conditions for the subsequent state. I am curious if AOIs offer this capability.