Can the same Ethernet card (ETN21) be utilized for both HMI connections and a Modbus TCP/IP server? The connections are established through a standard network switch. The customer aims to retrieve specific data from the PLC. I am attempting to use the OMRON ETN standard server for this purpose, which can be found at this link: http://www.myomron.com/index.php?action=kb&article=1245 "MTCP_ETN_Server.zip". Has anyone had experience with this setup? Will it function correctly? My primary task is to integrate the function block (FB) into my PLC program, and I am feeling a bit anxious about it. Any insights or advice would be greatly appreciated. Thank you!
I’m utilizing a modified version of the same ETN server function block that you are using because the initial code was quite basic. Additionally, I plan to establish a connection to a Human-Machine Interface (HMI) alongside the existing Modbus TCP connection, similar to your setup. Unfortunately, I can’t provide a definitive answer to your inquiry at this moment, as I have yet to test this configuration. I’m still awaiting the arrival of a test HMI unit from my client. However, I see no reasons why this shouldn’t work successfully. Currently, my laptop communicates with the Omron PLC through an Ethernet connection that employs the FINS protocol. While connected to the PLC online, I can effectively monitor the ETN function block in action, which leads me to believe that if the FINS connection were redirected to the HMI instead of my laptop, it should operate without any issues. This configuration involves a standard network switch as well.
Are you certain that no errors were made? I was utilizing a TCP socket for the 'send' function block.
I've made some significant modifications to the same ETN server function block that you're using, as the original code was quite basic. I'm also planning to establish an extra connection to a Human-Machine Interface (HMI) in addition to the Modbus TCP, similar to your scenario. Unfortunately, I'm unable to provide a definitive answer to your question at this moment because I haven't had the opportunity to test it yet. I'm still waiting for a test HMI unit from the client. That said, I don't foresee any reasons why this setup wouldn't work. Currently, my laptop connects to the Omron PLC using an Ethernet connection that operates on the FINS protocol. While connected to the PLC, I can monitor the functionality of the ETN function block without any issues, so I believe that if the FINS connection were to go to the HMI instead of the laptop, it should function properly as well. This configuration uses a standard network switch. Thank you for your response! I must admit, I'm feeling a bit anxious because in the documentation for the function block, it mentions that if the connection is not muted or properly established, it may restart the ETN unit. I'm uncertain whether this refers to the complete ETN unit rebooting or just the TCP socket—it's something I'm still trying to clarify.
PeterCs expressed gratitude for the response but mentioned feeling uneasy due to the information in the Facebook (FB) documentation. They pointed out that if the ETN unit does not reconnect or establish a connection, it restarts—uncertain if this applies solely to the TCP socket. To clarify, the restart pertains only to the TCP socket connection. If the ETN module loses its TCP link and cannot re-establish it within 10 seconds, it will reset itself. This process is triggered by monitoring the ETN TCP status and initiating a 10-second timer upon detecting a connection drop. It’s crucial to note that the Omron FB primarily focuses on basic error-checking at the TCP level, lacking any error-checking measures for the Modbus layer. If these limitations do not meet your requirements, you will need to implement additional code to address these gaps. As previously mentioned, the functionality of the FB, in its current state, is quite rudimentary. For instance, it is designed to support the ETN configured solely as Unit 0, as all the ETN status variable addresses are hard-coded. The good news is that you can easily modify these addresses to accommodate a different Unit Number. Furthermore, the FB only supports single coil write functions for coil operation codes, since digital values are bit-packed into input registers. If you intend to perform tasks like coil reads, you'll need to develop that functionality yourself, which is certainly feasible but may require some effort. I recommend thoroughly reviewing the documentation to understand what the FB code supports and what limitations exist. Depending on your specific requirements, it may not be as straightforward as simply integrating the FB and expecting it to function flawlessly. You might need to tweak the FB slightly or write additional code to ensure it fits seamlessly into your project. Nevertheless, I can affirm that the fundamental Modbus TCP features within the FB operate effectively.
**Rephrased Text:** The restart process is designed specifically for the TCP socket connection. If the ETN module loses its TCP link and fails to reconnect within a 10-second timeframe, it will automatically reset itself. This functionality is achieved by continuously monitoring the ETN TCP status and starting a countdown timer whenever the connection drops. It’s important to note that the Omron Function Block (FB) performs only basic error-checking at the TCP level. Unfortunately, it does not provide error-checking at the Modbus layer. If this limitation does not meet your project requirements, you will need to develop additional code to bridge those gaps. As previously mentioned, the supplied FB is quite minimal. For instance, it currently only works with the ETN configured as Unit 0, since the addresses of all ETN status variables are hard-coded. Fortunately, it’s relatively straightforward to manually adjust these addresses to accommodate a different Unit Number. Additionally, this FB supports only a single coil write function and does not facilitate any coil function codes, as digital values are packed into input registers. If you need functionalities such as reading coils, you will have to implement that logic on your own. While this is certainly feasible, it may take some effort. I recommend thoroughly reviewing the documentation to understand the capabilities and limitations of the FB code. Based on your specific requirements, integration may not be as effortless as simply placing the FB into your project. You might need to tweak the FB or write supplementary code to ensure compatibility with your application. That said, I can confirm that the fundamental Modbus TCP functionalities within the FB operate effectively. For my project, ensuring that the Building Management System (BMS) is accessible for data retrieval will suffice. Accessing data from the CIO memory meets my needs. I’ll share my onsite experiences in two days.
✅ 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.