User jstolaruk expressed skepticism regarding the reliability of that router for Ethernet messaging among devices. If the router's purpose is for programming tasks or simply for accessing its built-in web server, that might be a different scenario. I’m curious to know if there’s additional information explaining the problems. This isn't my area of expertise, so I'm eager to learn more. We've encountered comparable issues with the Cradlepoint MBR1200b, which led me to believe the root cause might be related to the PLC rather than the router itself.
I have concerns about whether this wireless router has been adequately tested for compatibility with the Common Industrial Protocol (CIP). A thorough Google search yields no references to its CIP capabilities, and this omission is understandable. Priced at just $40, this router is classified as commercial-grade and is primarily designed for small office or home environments rather than industrial applications that require a steady data stream without packet loss.
User jstolaruk expressed skepticism regarding the wireless router's ability to effectively support the Common Industrial Protocol (CIP). A search on Google yielded no relevant information about this capability. This is understandable given that the device is a budget-friendly, $40 commercial-grade wireless router designed primarily for small offices or home environments rather than industrial applications. Could this limitation be contributing to the connectivity issues we're experiencing? Or is it a completely separate problem? As previously mentioned, we have encountered similar issues with other higher-end routers as well.
JordanSS inquired: "Could this be the root cause of the problem, or is it an entirely different issue? As I mentioned, we've encountered similar challenges with other more expensive models. Additionally, are these units being utilized to connect various devices to the ML1400, such as servo controllers or Variable Frequency Drives (VFDs)? If so, I would be concerned. It's important to note that price does not guarantee the proper selection of equipment for specific tasks. Were the pricier units compatible with CIP/Fieldbus standards or certified by organizations like ODVA or Rockwell? Many unusual scenarios can arise from poorly matched communication equipment."
User jstolaruk inquired: "Are these connections utilized for linking additional devices to the ML1400? For instance, servo controllers or variable frequency drives (VFDs)? If that’s the case, I would have some reservations."
To clarify, the setup is relatively straightforward. It primarily consists of a Red Lion Human-Machine Interface (HMI) in conjunction with the ML1400 Programmable Logic Controller (PLC). Occasionally, a computer may be connected to download data logs, but that's about it.
JordanSS noted that the ML1400 experiences communication issues with other network devices upon startup. When powering on your devices, is only the ML1400 being activated, or is the entire system—including the router—being turned on? If you’re starting up the entire setup, it’s possible that the ML1400 finishes its boot sequence before the router does. Consequently, the router might not recognize the ML1400’s connection, preventing data transmission. However, when you unplug and then reconnect the Ethernet cable, the ML1400 signals to the router that it is now connected, which allows it to start passing data successfully.
Firejo asked: When powering on the system, does this apply only to the ML1400 or does it include the entire setup? If you are turning on the entire system, including the router and the ML1400, it's possible that the ML1400 completes its boot sequence before the router does. Consequently, the router may not recognize that the ML1400 is connected, preventing data transmission. By disconnecting and then reconnecting the Ethernet cable, the ML1400 effectively informs the router of its connection, enabling data flow.
To clarify, the entire system is powered up simultaneously. The system operates on a generator and is typically powered down at night, although this isn't always the case. Is there a solution you’re aware of to address this issue? Apart from employing a time delay relay for the PLC startup?
Troubleshooting intermittent connectivity issues can be quite an engaging experience! One key observation to make is the link status indicators on your router; this will help you determine whether an Ethernet connection is being established. I came across a Knowledge Base article discussing a similar situation involving a managed switch that required approximately 90 seconds to fully power up. By that time, the MicroLogix 1400 was already attempting to auto-negotiate the link settings (including speed and duplex) as the switch was booting up. The recommended solution was to configure both the MicroLogix 1400 and the switch to 100 Mbps and full duplex, while disabling the auto-negotiation feature. It's crucial to disable auto-negotiation on both ends of the connection. If you only disable it on one side, you risk experiencing a fallback to half duplex on that side, which could lead to numerous collisions and errors in data transmission.
Ken Roach mentioned that troubleshooting intermittent issues can be quite enjoyable! To diagnose your network effectively, I recommend checking the link status lights on your router to determine whether an Ethernet connection is being established. I came across a Knowledge Base article discussing a similar scenario involving a managed switch that required about 90 seconds for a complete power-up. In that case, the MicroLogix 1400 was already attempting to negotiate the link (speed and duplex) when the switch was still booting. The recommended fix was to configure both the MicroLogix and the switch to 100 Mbps Full Duplex and to disable Auto-Negotiation.
It's crucial to remember that when you disable Auto-Negotiation, it must be applied on both ends of the connection. Neglecting to do so on one side may result in "fallback to half duplex," which can cause numerous collisions and errors in data transmission.
Hi Ken, your insight seems to identify the potential issue. I've located the settings for 100 Mbps Full Duplex and Auto-Negotiation on the PLC. When you refer to configuring both sides, do you mean the router and the Human-Machine Interface (HMI)? Thank you!
JordanSS commented: Hi Ken, I believe this could be the root of the problem. I've located the settings for 100/full duplex and auto-negotiation on the PLC. When you mention configuring both ends, do you refer to the router or the HMI? Thank you!
Let's consider this at the cable level. When you configure the MicroLogix to a fixed speed of 100/full duplex, that's the setting for one end of a CAT5 or CAT6 cable. The other end, which connects to the router, needs to match this configuration. Furthermore, if you're dealing with just the ML1400, a router, and the HMI, it's unclear which device might be causing a communication issue. It might be wise to set all devices to the same configuration to ensure seamless connectivity.