New ✨ Introducing Oxmaint Asset Hub for Machine Builders and OEMs. Explore Now
Greetings to all forum members! As a newcomer, I am seeking assistance with AB 1679-L31 tags in my controller. Specifically, I am dealing with a tags group (type INT[256]) that receives data via the DF1 protocol from a third-party device. How can I verify the connection between these tags and the DF1 input? Is there a way to identify the Tag-DF1 relationship within RSLogix5000, especially in the absence of relevant comments or program documentation? Any insights on this matter would be greatly appreciated. Thank you in advance for your help.
Welcome to the forum! It seems like you are utilizing a third-party device to communicate with the PLC through the DF1 protocol. You have PLC tag data that you suspect is originating from the DF1 device, but you are uncertain. To confirm this, you can physically disconnect the DF1 device while monitoring the data tags. The tags will cease to update once the device is disconnected, although this may not be feasible in a production environment. One alternative method, typically used with Ethernet devices, is to access the Controller Tags and examine the Data Type of the tags. For instance, in my current project involving a Powerflex drive communicating over Ethernet, I can view a tag with Data Type ABowerFlex525V_EENET_Drive:I:0 in the Controller Tags. By performing a Crossreference on the tag, I can identify where it is utilized in the logic. While this approach is specific to Ethernet devices, it may be worth exploring for DF1 devices as well.
Thanks for your response. I apologize for the confusing post. English is not my first language, so let me clarify my task. I have a situation where AB 1679-L31 is receiving data from UPS via DF1. In the controller tags, I have a group called "UPS" (Data Type INT[256]). However, we recently upgraded our UPS hardware, and the new UPS can only send Data Type INT[128]. The issue is that the old UPS was sending data in the 128-256 address range, which is currently being used in the logic. For example, logic includes references to UPS[239] and UPS[211]. I am aware that these tags are related to the data received from the UPS via DF1. My goal is to review all DF1-related tags and move tags with addresses in the 128-256 range to below 128 without impacting the already assigned addresses.
When replacing an old UPS with a new one, it may be necessary to reconfigure the UPS tags to ensure proper functioning. Start by referring to the user manuals for both the new and old UPS systems to locate data mapping tables provided by the UPS vendors. These tables explain the function of each data address, such as INT[xxx] = UPS Running, etc. It may be helpful to cross-reference the old UPS tags with the existing PLC logic to understand the function of each tag. However, for the new UPS, it is crucial to obtain information from the vendor regarding the use of each data address to avoid any guesswork. This will ensure that you correctly assign the appropriate meaning to each data address.
I appreciate the guidance received, as it led me to successfully map tags to DF1 messages. This mapping process was achieved through the use of Logic, specifically by navigating to map PLC/SLC messages and specifying the file number and tag name.
Answer: - To verify the connection between your tags group and the DF1 protocol in RSLogix5000, you can check the communication setup within the controller configuration. Ensure that the tags are configured to receive data via the DF1 protocol from the third-party device.
Answer: - In RSLogix5000, you can identify the Tag-DF1 relationship by reviewing the tag definitions and examining the communication settings associated with the tags group. Look for any references to the DF1 protocol or third-party device within the tag configurations.
Answer: - If you encounter issues with the connection between tags and the DF1 protocol, you can check the controller's communication settings, verify the tag configurations, and ensure that the correct data types are used for data exchange. Additionally, reviewing the controller's status and monitoring tools can help pinpoint any communication errors.