Visit corsairhmi.com for specific PLC class outline with code examples on how to achieve this task.
In the realm of PLC communication, I have always favored the method of having the sending PLC increment a number with each scan. The receiving PLC then reads this number during data transfer to verify that it is continuously changing. If the number ceases to change, it indicates a potential communication failure or that the sending PLC is no longer operational. In such cases, it is advisable to clear all stale data. This approach also allows for dual heartbeat checks, where the receiving system can monitor the least significant bit (LSB) of the counter for a pulsing signal.
While some processors may have limitations in terms of communication instructions (such as Siemens GET and PUT) depending on the PLC's operational state, this method ensures consistent functionality. The utilization of a rolling counter effectively addresses this limitation, providing a reliable communication protocol.
An effective method for monitoring communication between PLCs is by setting up a "heart-beat" monitor using two bits that automatically toggle at a set rate. These bits, transmitted as integers between the two PLCs, provide a simple yet reliable system. In PLC1, the XIC PLC2_Heartbeat_In function is used to monitor incoming signals, while the OTE PLC1_Heartbeat_Out function is used to transmit outgoing signals. In PLC2, the XIO PLC1_Heartbeat_In function is used for monitoring incoming signals, and the OTE PLC2_Heartbeat_Out function is used for transmitting outgoing signals. By including a single inversion in PLC2, the monitor will continue toggling as long as communication is successful. Additionally, setting up an alarm timer in each PLC, reset on the rising edge of the XXX_Heartbeat_In (or Out) signal, will quickly alert users to any communication issues that may arise.
It is frustrating to realize that PLC manufacturers do not provide an integrated health status feature for networked PLCs in the configuration options. Simply adding a tab where users can input the IP/ID of another PLC and check a box to receive its health status, along with tagging a variable, would be a straightforward default feature. It seems outdated that in today's technology-driven world, one must create their own code to verify network connectivity.
- 09-12-2024
- tragically1969
In each programmable logic controller (PLC), we assigned bits to monitor communication. PLC A attempted to set the bits to 1, while PLC B tried setting them to 0. If the bit failed to change within a specified timeframe, a communication fault was detected. We utilized the produced and consumed functionality, including a message sent bit to confirm successful delivery. This process has been ongoing.
cardosocea mentioned that in the Rockwell PLC systems, certain processor communication instructions such as Siemens GET and PUT operate regardless of the PLC's run mode. However, this limitation can be addressed with the use of a rolling counter. It is important to note that for messaging purposes, the PLCs must be in either RUN or Remote RUN mode.
In Logix5000 controllers, data exchange can be achieved through Produced/Consumed tags, which will still function even if the processor is in a PROG mode. The use of produced/consumed tags effectively facilitates the exchange of I/O data.
OysterMan explained that in their setup, they had different programmable logic controllers (PLCs) performing alternating tasks to check for communication faults. By utilizing produced and consumed data, which can be organized into User Defined Types (UDTs), the "Connection_Status" member can be particularly useful. This member, consisting of 2 bits named "RunMode" and "ConnectionFaulted," provides crucial information about the producer's health. Keeping a close eye on these bits can help in monitoring the status of the connection and determining if there are any faults present. For more detailed information, be sure to consult the Help section.
I programmed each slave Programmable Logic Controller (PLC) to transfer the clock time value for seconds into a designated register within the read data. The master PLC would trigger an alarm if it detected the same value in that register after three consecutive data reads.
According to daba, PLCs should be in either RUN or Remote RUN mode, not for messaging purposes. In Logix5000 controllers, data exchange is possible through Produced/Consumed tags, which remain active even in PROG mode. These tags facilitate I/O exchange smoothly. This revelation about Produced/Consumed functionality is enlightening, especially considering the usual method of programming instructions to read from another PLC's memory. It's reassuring to know that no specific function needs to be activated in the user program for this exchange. Thank you for the clarification.
Tom Jenkins mentioned that he directed every PLC slave to transfer the current clock time for seconds to a specific register in the read data. Should the master PLC detect a matching value in the register after three consecutive data reads, an alarm would be triggered. This procedure is also part of my standard practice in PLC programming.
According to daba, PLCs must be in RUN or Remote RUN mode and should not be used for messaging purposes. However, I have a vague memory of being able to send MSG read and MSG write instructions to Rockwell PLCs even when they are not in run mode. Can you confirm if my recollection is correct?
In my experience, I remember being able to send read and write MSG instructions to non-operational Rockwell PLCs successfully. Am I mistaken in recalling this? The executing PLC may not be able to perform any actions if it's in programming mode, but the target PLC will still respond regardless of its mode. Communication occurs regardless of the operational mode, although no logic is executed.
dmroeder mentioned that a PLC sending an MSG may not be able to execute any actions if it is in PGM mode, but the receiving PLC will still respond regardless of its mode. Communication occurs regardless of mode, however no logic is executed. Thank you for clarifying this distinction for others reading the thread.
dmroeder pointed out that communication between two PLCs can occur regardless of their operating modes. While the sending PLC may not execute any logic if it is in program mode, the receiving PLC will still respond. This means that you can always exchange data between PLCs, whether they are in run or program mode. The heart-beat monitoring concept mentioned earlier is applicable to any PLC model and is easy to set up for seamless communication.
In a PLC system, communication between controllers is crucial for seamless operation. Even if one PLC is in PGM mode and unable to execute logic, the target PLC will still respond effectively. This insight prompted me to investigate the functionality of a controller’s Wallclock object across different modes. By analyzing the Logix platform, I aim to determine if controllers can access and compare elapsed time counters, such as milli/micro-seconds, regardless of their operational mode.
JeremyM suggested testing if a controller's Wallclock object remains active in different modes to allow controllers to read each other's elapsed milli/micro-second counters. I will explore this further on a Logix platform to find the answer. It seems that when a PLC's clock is read in PGM mode, the value keeps changing. However, retrieving the result of a GSV reading the clock will not change until the GSV is executed to fetch the data from the controller.
After being inspired by JeremyM's comment, I decided to investigate whether a controller's Wallclock object continues to function across different modes. If it does, controllers could potentially share and sync their elapsed time counters. I plan to explore this further using a Logix platform. The Wallclock is a fundamental OS task that constantly runs, but unfortunately its data is inaccessible to others. At present, there is no external method to access this information, but hopefully a solution will emerge in the future.
According to daba, the Wallclock task in the operating system is continuously running, but its data is inaccessible to third parties. While there is currently no method for outsiders to access this data, there may be a solution in the future. To directly communicate with the Wallclock object of the unit, simply message it. Remember, the Wallclock object is just a CIP object and can potentially be accessed through this method.
Contrary to popular belief, PLC manufacturers do offer built-in health status options for networked PLCs in their configuration settings. For example, Rockwell provides connection status in their ControlLogix platform through Prod/Cons. Additionally, older SLC models utilize Message.ER bits for this purpose. However, it is always advisable to include additional check logic as necessary to ensure optimal performance and reliability.
JeremyM suggested directly messaging the unit's Wallclock object, which is essentially a CIP object. This class number is not documented as far as I know. Do you happen to have this information and could you share the attribute numbers as well, please?
The PTP Time Sync object has been well-documented, providing valuable information that sets it apart from the wall clock object. While they are not identical, the PTP Time Sync object contains a wealth of information that users may find useful.
When using a clock for the heartbeat function, it is crucial to include a command in the logic to transfer it to a different register. This ensures that the register being read will only be updated when the logic is active and running.
When utilizing Rockwell Produce/Consume tags, a heartbeat is not required. To facilitate data transfer, it is recommended to create a User-Defined Tag (UDT) for the desired data. Include the element CONNECTION_STATUS at the beginning of the UDT with a data type of CONNECTION_STATUS, followed by the remaining data such as DINT arrays and REAL arrays. The PLCs will manage the .RunMode and .ConnectionFailure bits automatically, allowing the Consuming PLC to respond accordingly.
pturmel inquired about a class number that is not documented. If you have any information to share, including attribute numbers, please do so. The class is labeled as 0x8B (139) and belongs to instance 1 with attributes ranging from 1 to 12. Familiarize yourself with this class by comparing local results with GSVs.
The security system in my setup involves two Allen Bradley Compactlogix PLCs connected to a specialized security relay from Allen Bradley. This relay is designed to receive signals (pulses) from both PLCs, and in the event that one or both pulses are lost, the relay will activate and trigger an alarm or any other desired response.
JeremyM remarked, "You will grasp it rapidly." It brought a smile to my face. Clearly, you are not familiar with Phil. He can code effortlessly even in his dreams.
Phrog30 joked, "That gave me a chuckle. Looks like you're not familiar with Phil's coding skills - he can program in his sleep." It seems like I may be in the same boat. I'm willing to share additional classes, instances, and attributes in return for some help.
JeremyM mentioned the possibility of providing additional classes, instances, and attributes in return for help. However, revealing confidential CIA information that has not been disclosed yet could violate RA policies. Be cautious to avoid attracting the attention of RA authorities.
Daba expressed concerns about the publication of undisclosed CIA data, which may violate RA policies. It is important to be cautious, as this could attract the attention of RA authorities. The data being published by RA may not be straightforward, as seen with examples like classes 0x01, 0x6B, 0x8B, 0xF5, 0xF6, and 0x33A in the manual which correspond to information on 5x80 processors. By delving into available literature, one can uncover valuable insights. Sharing information at this level in exchange for project guidance seems reasonable if the effort has been made. While there are other objects that have been explored, they may not be relevant to the project or may be highly specialized in terms of hardware (such as Backplane Interfaces/Counters, CPU Core Stats, etc.).
daba warns to be cautious to avoid the possibility of attracting the attention of the RA police. However, I am eager to have an encounter with them as I have some thoughts and behaviors to share.
Phrog30 expressed a desire to confront law enforcement officials, eager to address them with words and actions. Specifically, suggesting disarming an individual and resorting to fisticuffs.
I want to express my gratitude to everyone for their understanding. I recently transitioned to working the second shift, which has been a big adjustment for my family. This change has caused a delay in my responses, but I am doing my best to catch up. Thank you for your patience. - James
In a forum post, JeremyM shared details about Class 0x8B (139) Instance 1 Attributes 1-12 and how to quickly understand them by comparing local results with GSVs. Click to expand for more information. Your feedback is much appreciated.
JeremyM revealed that the symbols are published by RA in unconventional ways. This is the first comprehensive description of a symbol object's attributes, making it an official resource for understanding symbols in a more detailed manner.
pturmel expressed gratitude for the information provided. He mentioned that it was the first detailed overview of a symbol object's attributes. Reading these attributes with GET_ATTRIBUTES_ALL can be challenging as the order of returned attributes is 2, 3, 1, 5. Additionally, there is a derived attribute for structured symbols called Template Instance, which is calculated by performing a bitwise AND of the Symbol Type attribute with 0x0FFF. This value represents an instance number of the Template class (0x6C).
In a discussion with JeremyM, it was noted that reading attributes with GET_ATTRIBUTES_ALL can be more challenging due to the returned attribute order being 2, 3, 1, 5. Interestingly, some Rockwell products may not be compatible with Get_Attribute_Single, but they may work with Get_Attributes_List. JeremyM further explained about a derived attribute called Template Instance in structured symbols, which is calculated by performing a bitwise AND of the Symbol Type attribute with 0x0FFF. This value represents an instance number of the Template class (0x6C). Having a solid understanding of Symbol and Template classes, I have successfully created a Java emulation (Visit Module Sales on my website for more information).
I am currently exploring methods to extract Class 1 connection objects/lists from their designated ports. As I navigate through various classes, I often find myself thinking in terms akin to those of CIA operatives.
Hello, have you successfully completed this task before? I frequently complete this task, as it is straightforward. Please note that I have provided an example on the SLC side. I have omitted some destination tag names to avoid any confusion. Feel free to name them as you wish. The Destination should be the element that is being transmitted to the SLC. It is important to replicate this on the SLC side as well. JTC.
The KISS1 Programmable Logic Controller (PLC) features a 10-second timer that can be reset by a single PLC. Failure to reset the timer results in a loss of communication if the .dn condition is met.
User janner_10 shared that KISS1 PLC includes a 10-second timer that can be reset by PLC 1. In case of a .dn event, communication failure is indicated. The previous explanation, although functional, may be a bit excessive. Click for more information.
In a scenario where KISS1 PLC features a 10-second timer that requires another PLC to reset it, losing communication can result in an issue. If the connection is lost while the "reset" signal is activated, the timer could potentially get stuck in a loop of resets. This situation calls for a more sophisticated approach to prevent this problem from occurring.
Inadequate communication can hinder the successful operation of a system when the "reset" bit is high, causing it to remain stuck in a continuous reset loop. This issue requires a more nuanced solution to avoid disruptions. It is essential to clarify whether a one-shot or immediate reset is required, as complexity may still arise even with the one-shot approach.
User Phrog30 mentioned the possibility of achieving clarity in just one shot. He did not provide specific details in his example, making a good point about the simplicity of the process. Can you provide a sample of this method being implemented?
I typically use a single rung of three instructions to set up message heartbeats, which involves monitoring an SINT data type. For more information, check out this thread on the Inductive Automation forum: PLC to PC server.
When asked, "Can you provide an example of a built and pasted scenario?" JTCat responded by suggesting two different options, with a preference for using the unlatch. They explained that if the timer times out, communication is lost but will automatically recover without the need for a reset. Additionally, they noted that most programs feature flashers, which are commonly used to blink lights. JTCat uses a flasher as the heartbeat signal to other systems in this context.
Phrog30 suggested using the "unlatch" option as a solution when faced with two different choices. In the event of a timeout, communication may be lost but will recover automatically without the need for a reset. Most programs include flashers that can be used to blink lights, which can serve as a heartbeat signal to other systems. However, a potential downside may occur if the local PLC is reading the heartbeat bit instead of the remote PLC writing to it, potentially showing a high heartbeat bit when the remote PLC is not in run mode.
rupej mentioned that there may be a missing piece of information. It is important to always do reads as they make troubleshooting much easier. If the remote PLC is not operational, the heartbeat will not change, as that is its intended function. Without a change within the set time period, the timer will expire, resulting in a timeout and loss of communication. So, make sure to regularly check for reads and monitor the status of the remote PLC to prevent any communication issues.
Phrog30 suggested that performing reads is essential for troubleshooting. If the remote PLC is not running, the heartbeat will not transition as expected. Failure to transition within the set timer period will result in a timeout, which indicates a loss of communication. In the scenario where the local PLC is monitoring the "heartbeat bit" of the remote PLC that has faulted, it is crucial to prevent the local PLC from continuously reading a high bit and resetting the timer. Consistently monitoring reads is highly recommended for efficient operation and maintenance of the PLC system.
In situations where a local PLC encounters a high bit from a faulty PLC, a common concern is the possibility of the local PLC constantly reading this high bit and resetting the timer. However, a more effective approach is to use a one-shot method rather than an unlatch. The choice between the two depends on data management - using a message may require a one-shot. Regardless, utilizing a one-shot mechanism ensures that the status of the high bit is not a concern as it must undergo a transition for the system to react accordingly.
In response to L33er's statement, it is incorrect to say that PLC manufacturers do not include a health status feature in networked PLCs' configuration options. Rockwell, for example, offers a connection status feature in their ControlLogix platform through Prod/Cons. Additionally, older SLC models use Message ER bit for messaging purposes, which I find to be adequate. It is possible to add more check logic as necessary. I am in agreement with this method, as it eliminates the need for extra logic. When the message instruction fails to connect, the error bit will indicate a communication halt for various reasons. It is crucial to have a timer to initiate the message.