Hello everyone, I recently exported CSV files from an application developed in FactoryTalk View and discovered nearly 1,600 tags. However, I'm struggling to grasp their specific applications. My second query pertains to this application, which operates with a single PLC model, the SLC 5/05. In the CSV file’s address column, I found two different address formats: [program name]B3/88 and {::[PLC program]I:3.1/15}. I'm uncertain about which format to utilize. As I plan to use the same CSV file for a different PLC program, I need guidance on how to assign tags that aren’t currently linked to any screens. Any insights or advice would be greatly appreciated!
I'm uncertain about the specifics of the first point; however, I can confirm that the use of "::" is essential when communicating with a PLC5 or PLC500 model. While it's not a requirement when interfacing with ControlLogix systems, using it can still function effectively.
It seems that your project was likely migrated from PanelBuilder32, the earlier version of PanelView Standard. The addressing methods in both examples you provided are quite unconventional, and I would not recommend using them. It appears you have several questions, which can be summarized as follows: 1. What do these unconventional address syntaxes signify? 2. Is my program interfacing with multiple PLCs? 3. How can I effectively utilize cross-referencing in FactoryTalk View? Let’s address question #2 first. Both PanelView Standard and PanelView Plus (PV+) terminals are capable of communicating with multiple controllers over the same network. Although some PV+ models may have licensing limitations that restrict them to only one controller, this is a matter of licensing rather than underlying technology. In PanelBuilder32, each controller was referred to as a "node." With the transition to PV+, the application now uses RSLinx Enterprise, meaning that during the conversion process, each node is transformed into an RSLinx Enterprise "Shortcut." You mentioned two examples: [Program_Name] and [PLC_Program]. These suggest that the original program may have interacted with two controllers, or it may have been assembled from different programs, resulting in numerous tags that reference a controller that is not actively used. By refining your understanding of these concepts, you can enhance your project’s functionality and efficiency.
Let’s delve into the topic of syntax. The examples you provided are either unconventional or discouraged. In the context of the PLC-5/SLC-500 architecture, the notation [program name]B3/88 serves as shorthand for addressing bits within a data word. For instance: - **B3:0** corresponds to bits B3/0 through B3/15 - **B3:1** refers to bits B3/16 through B3/31 - **B3:2** represents bits B3/32 through B3/47 - Continuing this pattern, B3/88 is equivalent to B3:5/8 The use of a starting double colon indicates that the subsequent address includes a colon. Due to the nonstandard shorthand used in this addressing format, the SLC data table address does not contain a colon, making it unnecessary to include the initial double colon for RSLinx to recognize an SLC-style data table address. For instance, the notation **{::[PLC program]I:3.1/15}** directly references a word in the input module of the SLC-500 chassis. However, I advise against directly addressing I/O data tables because they can present challenges. The developers behind FactoryTalk View have emphasized this point; at one stage, they prohibited direct addressing of I/O data tables for PLC, SLC, and MicroLogix systems. In the example mentioned, the address targets the 15th bit of the second word. This could indicate that it's being used for a 32-bit discrete input module, or it may refer to the sign of an analog channel in an analog input module, such as the 1746-NI4. This revised explanation reflects improved clarity and is optimized for search engines by incorporating relevant keywords related to PLC programming, syntax, and data addressing techniques.
Ken Roach commented that the notation {::[PLC program]I:3.1/15} refers specifically to a word within an input module located in the SLC-500 chassis. He advises against the direct addressing of I/O data tables due to their complexity and potential pitfalls. This sentiment is echoed by the developers of FactoryTalk View, who, at one point, prohibited direct access to PLC, SLC, and MicroLogix I/O data tables altogether. Can you elaborate on your reservations regarding direct addressing of tags? I assume you are suggesting that the alternative involves using an HMI tag linked to the I/O. I find this method to be time-consuming during troubleshooting, as locating an address in the PLC program leads to the additional step of identifying the corresponding HMI tag. This process requires further searching rather than simply querying the address directly, complicating efficiency in the troubleshooting process.
Please note that the "::" acts as a placeholder for the format "nodename:application:[topic]address," which you should use when retrieving data from an IO server.
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.