Greetings everyone! I have been following this community for a while, but this is my first time posting. Currently, I am tackling a project that involves developing a program to monitor the diagnostic data on multiple Stratix switches. Many essential parameters, such as temperature and MAC addresses, can only be accessed through explicit messaging. Each parameter is defined by class/instance/attribute information in the EDS file, making message configuration straightforward. However, the sheer volume of parameters to monitor presents a significant challenge. Setting up separate messages for each parameter, especially when some parameters apply to every port on the switch, is a daunting task. While configuring messages for one switch is feasible, repeating this process for every switch the program needs to monitor is impractical. Ideally, I envision creating an Add-On Instruction (AOI) that handles messaging internally. Since the message class, instance, and attribute are consistent for a given parameter across all switches, the AOI would simply require a switch reference to output the specific parameters for that switch. This would involve developing the AOI, duplicating it for each switch on a new rung, adjusting the reference accordingly, and completing the task. However, based on my own experimentation and the information gathered from various forum discussions, implementing messaging within an AOI seems challenging. If I were required to configure each message externally in the routine where the AOI is called, it would defeat the purpose of streamlining the process. I am currently using version 32 of Logix and working with an L85. I am hopeful that there have been advancements or changes since the older forum posts I have consulted, which could potentially make my desired solution achievable. Is there a way to approach this issue differently or any key aspects that I may be overlooking? Your insights and suggestions would be greatly appreciated.
Avoid performing this task in an AOI. Instead, establish a structured routine that indirectly cycles through all the messaging with the help of an Index. Create a User-Defined Type (UDT) to store all the necessary members and utilize an array to hold attributes such as Enable, Message Config, Read/Write Duration Timers, Comm Delay, Read/Write Failure, etc., in an indirect manner. I implement a similar approach when retrieving extensive data from remote sites to ensure that all messages are sequentially staged and not sent simultaneously.
Our machines are equipped with the Rockwell PowerFlex 525 Faceplate AOI, which features logic to communicate with the VFD and retrieve the last fault code. This AOI functions exactly as described, with approximately 40 VFDs in the machine. The AOI is utilized multiple times throughout the machine, with the same number of message type tags configured as controller tags. - PaulB.
PaulB mentioned utilizing the Rockwell PowerFlex 525 Faceplate AOI in their machines to send messages to the VFD and access the last fault code. This AOI is effectively integrated with approximately 40 VFDs in the machine, with multiple instances of the AOI being called and configured with the same number of message type tags as controller tags. Instead of using a MSG instruction, it is recommended to directly read from the output array for this purpose.
If you're looking to simplify your setup for Stratix Switches, consider using the Rockwell-provided AOI that includes pre-configured functionality. This AOI also comes with user-friendly HMI faceplates for easy operation. You can find this time-saving solution in the Network Device Library section of PCDC. It's worth noting that this AOI is compatible with all current Stratix platforms, making it a versatile option for your networking needs.
In response to your initial query, the MSG tag in AOI is always set as an InOut parameter. While configuration can be achieved programmatically within the AOI, the Service code remains non-configurable. As a result, it is necessary to utilize Get Attribute Single and Get Attribute All messages individually. I highly suggest opting for the Rockwell supplied AOI as it efficiently handles all messaging tasks for you.
Hey there, welcome to the forum! I can definitely relate to your struggle - managing parameters for multiple Stratix switches can indeed be time-consuming. An AOI that manages messaging internally sounds like an excellent idea, however, as you've mentioned, it might not be entirely feasible to implement. What if you considered using UDTs (User-Defined Types) for the Stratix settings and leveraging AOIs to manipulate the UDT instances for individual switches? This way, you're essentially creating a template which can be easily altered for specific switches. You might still have to create separate messages outside the AOI, but most of their configuration would be common and handled by the UDTs. Have a look at the indirect addressing feature as well. Using this, it would be possible to loop through an array of UDTs, changing the elements as necessary. It’s a method that could greatly speed up your parameter management process. Just a thought, keep us posted!
Welcome to the forum and congrats on your first post! Your project sounds like a complex one but hang in there, challenges like these can lead to huge learning experiences. I agree that having to configure every single message is impractical, so automating the process with an AOI seems like the right path forward. While AOI might seem daunting, it would be beneficial in the long run since it allows you to modularize and reuse your code. I'm aware, as you've mentioned, that setting up messaging within an AOI can indeed be a hurdle. One possible solution I can think of is to set up UDTs (user-defined types) for different types of messages. Each UDT could then be assigned a unique tag. This would somewhat streamline the process of assigning messages. Just a thought, but have you also considered using an Event-Driven programming model for this? It might help reduce the routine to a collection of conditions and actions which might make the task less cumbersome. These suggestions might not be the perfect solution to your problem, but taking a different angle could help simplify your project. Hopefully someone else can chime in with additional insights! Good luck with your project.
Hey there, glad you decided to start participating in our discussions! Your project sounds quite complex and I appreciate the level of detail you provided. My experience with Stratix switches is a bit limited, but based on what you've shared, I think you're on the right track with the idea of creating an Add-On Instruction (AOI). Even though setting up internal messaging within the AOI might present a challenge, it could help streamline your process significantly once you figure it out. Also, beyond just getting the AOI up and running, it's worth considering some programmatic way to iterate through the parameters you need to monitor for each switch. This could help reduce the amount of manual configuration you'd need to do for each individual switch. Finally, in the latest version of Logix, there may be pre-built or third-party tools available that could help with some of the heavy lifting. Keep digging into forum discussions and don't be afraid to reach out to the Logix support team as well. Good luck with your project!
Welcome to the community! It sounds like you’re tackling a complex but interesting project. Have you considered leveraging the existing libraries or modular programming techniques available in Logix 32? Instead of creating separate instances of the AOI for each switch, you might explore using a single instance and passing an array or a list of switch references, along with the parameter you want to monitor. This way, you can iterate through the switches and retrieve the data you need without duplicating your efforts for each one. If you could encapsulate the message configuration into a smaller number of flexible functions, it might save you a lot of setup time. Good luck, and I’m eager to see how it goes!
Welcome to the community! It sounds like you're diving into quite an ambitious project. One approach you might consider is creating a wrapper function around your messaging logic, where you could define the parameter inputs as an array or similar structure. This way, you can loop through the parameters you need to monitor for each switch, which could reduce the overhead of having a dedicated message for each one. Additionally, check if your version of Logix allows for any custom scripting or enhancements that might not be widely discussed yet; sometimes there are hidden gems in the documentation or community posts that can help streamline your process. Best of luck with your project!
✅ 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: Answer: The challenge lies in setting up separate messages for each parameter, especially when some parameters apply to every port on the switch, which can be a daunting task when repeated for multiple switches.
Answer: Answer: The AOI would handle messaging internally based on consistent message class, instance, and attribute information for a given parameter across all switches, requiring only a switch reference to output specific parameters for each switch.
Answer: Answer: The main concern is that if messages need to be configured externally in the routine where the AOI is called, it might defeat the purpose of streamlining the monitoring process.
Answer: Answer: The project is being developed using version 32 of Logix and working with an L85 hardware.
Answer: Answer: The individual is hopeful that there have been advancements or changes since older forum posts, which might help in achieving the desired solution for monitoring the switches efficiently.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.