I have a Modbus TCP-only inverter that needs to communicate with a Controllogix PLC via Ethernet/IP network. I am currently using a Prosoft PLX32-EIP-MBTCP gateway for this purpose. However, I am facing a problem where the gateway loses communication with the inverter after multiple connection attempts, requiring a cold reboot of the inverter to restore communication. I am seeking insights into why this behavior occurs and if there are any automatic solutions available to prevent it without setting a long timeout period. Any advice would be appreciated. Thank you!
To receive accurate responses, it is important to provide specific details about the Variable Frequency Drive (VFD). Different drives have communication parameters that affect their response to communication loss when configured to operate through a communication port. These parameters include a timeout setting that determines how frequently the VFD needs to be polled to prevent a timeout. Another parameter dictates the VFD's reaction to a loss of communication. It is unlikely that these settings would cause the VFD to stop responding to polls, as you mentioned. I have encountered a few devices in the past that would stop responding if I polled them too quickly or tried to access an illegal address. For instance, one device only allowed me to read 8 consecutive holding registers per message using Modbus RTU on RS485, not Modbus TCP. Recently, I came across a Toshiba VFD on Modbus RTU that restricted me to reading or writing a single holding register per message. Fortunately, for my specific application, I only needed to read 3 and write 2 registers, so I had to create five staggered PLC messages to accomplish this task.
If your VFD is experiencing a communication loss, it may not reestablish communication automatically. To troubleshoot this, consider disabling the fault in the VFD or checking if the VFD has a parameter for automatically resetting faults. This issue could be a possible cause for the VFDfaulting out.
Thank you for providing answers. I apologize for the error in my previous information – the device in question is not an inverter, but rather a pump control module (Xylem Flygt Pareo 711). Unfortunately, the available Modbus/TCP registers and settings on the module's HMI do not allow for controlling the timeout and fault reset functions. The module's HMI does not display a specific fault related to communication loss, nor does it offer an auto-reset feature. Prior to using the gateway from Prosoft, communication was established directly with the module via MSG. When communication was lost a few times, manual restarts were required. The Prosoft gateway communicates with the PLC using IO connection class 1, enabling it to trigger a reset of the module after experiencing a timeout. It is unclear whether the issue lies with the module itself or the Modbus TCP network. I am hopeful that the problem may be related to the network, as the module lacks extensive configuration options. This suggests that a potential solution may exist within the Modbus TCP network.
Why use this pump module when your PLC doesn't natively support its protocol? It seems like a superficial decision made by a non-technical manager, pushing for IIOT without considering functionality. The optional modbus feature lacks proper documentation and is unreliable, often requiring hard reboots. It's better to rely on the PLC for control, rather than this unreliable add-on. Consider discarding the module and sticking to the PLC for optimal performance.
Strantor raised a valid question - why utilize the pump module when the PLC in place lacks native support for its protocol? This scenario reeks of a decision made by a non-technical manager enamored with a new gadget, rather than a practical solution. This situation hints at the Industrial Internet of Things (IIOT), designed for remote control via smartphone apps, with a haphazardly implemented modbus feature. Surprisingly, the modbus functionality is listed as "optional," with no clear documentation on its parameters. The unreliable modbus implementation necessitates frequent reboots, leading to the suggestion of discarding the module in favor of the PLC's capabilities. The company operates multiple pumps with just one PLC, requiring continuous motor control even in the event of a communication failure. While some pumps utilize the E300 with Ethernet IP, bypassing the communication issue, there's a lingering confusion about why the E300 option was initially requested. With over 10 of these questionable modules in use, a cost-effective replacement with the E300 is not feasible, leaving limited options for pump management.
Hi, it seems like your problem could be related to a resource overload on your inverter after multiple connection attempts. Most Modbus TCP devices have a limited number of simultaneous connections they can handle. When this limit is hit, the device might refuse new connections till old ones are closed, causing a communication loss. You could look into optimizing your connection handling by ensuring that open connections are properly closed when not in use, and new connections are not attempted until necessary. Additionally, you might want to ensure there aren't network bottlenecks such as IP address conflict, causing the communication drop. Lastly, check whether the gateway has the latest firmware installed - outdated firmware could potentially cause unstable connections.
I'd recommend looking into the settings on both your inverter and the gateway. It sounds like the inverter might be overloading with connection attempts and shutting itself down as a safety measure. There might be an adjustable limit on simultaneous connection attempts you can set to a smaller figure. For the gateway, it could be that the refresh or update rate is set too high, causing excessive connection attempts. Try reducing this rate to see if the problem persists. Regarding automatic solutions, you might want to consider a script that monitors the connection and triggers a reset when it detects a drop off. This, however, would be a band-aid to the problem and not a real solution. Don't overlook the possibility of a firmware update for either device, sometimes glitches like these are known issues addressed by manufacturers.
I'm not sure what the precise root cause might be, but you may want to check to make sure your inverter is properly configured for continuous operation. Sometimes, devices like these can have auto-sleep or power saving modes that could interfere with a sustained connection. That aside, it’s possible the gateway may be creating too many simultaneous connections causing the inverter's port to block further connections until it's restarted. In terms of an automated solution, you could consider implementing a script to monitor and reset the connection as needed, or perhaps an OPC server with built-in redundancy and failover capabilities might help. It’s a good idea to reach out to Prosoft support staff as well; they are generally very responsive and could have further insights into your specific model.
It sounds like you're facing an issue that might be caused by a few different factors. Firstly, your problem might lie with the TCP connection limit on your inverter. You may want to ensure that you are fully disconnecting after each communication attempt to prevent hitting this limit. Secondly, it could be down to a firmware issue on either the gateway or the inverter. An update could potentially resolve this issue. Also, check if there is any possible error in your IP configuration, as this could cause communication issues. Lastly, if there are still issues persisting, you may want to consider an alternative communication gateway that has automatic connection recovery features built-in. This might save you from needing to set a long timeout period. Good luck!
✅ 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: 1. Why does the Prosoft PLX32-EIP-MBTCP gateway lose communication with the Modbus TCP inverter after multiple connection attempts? - The issue could be related to network congestion, timing mismatches, or configuration settings causing communication disruptions. 2. Is there an automatic solution available to prevent the communication issue without setting a long timeout period? - One potential solution could be to adjust the gateway's configuration settings, such as retry intervals or connection parameters, to stabilize communication without relying on long timeout periods.
Answer: - You can start by checking network configurations, gateway settings, and communication protocols to identify any potential sources of the issue. Additionally, consulting the gateway's user manual or reaching out to technical support for assistance may provide further insights.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.