Hello everyone, I'm a new member here and excited to share my first post! My background includes working with Siemens Logo PLCs and using ladder logic. I also have training in Beckhoff, as well as experience in Python, C, C++, and Arduino programming. Currently, I am working on a project to upgrade a control system by integrating Modbus devices. The original PLC used was a Rievtech micro PLC, but I decided to go with the Micro820 due to its cost, size, and performance advantages. However, I have encountered two main issues: 1) I accidentally changed my IP address settings and now cannot communicate with the PLC. Despite trying various solutions found on forums and YouTube, such as updating firmware and using RS232 connections, I have not been successful. I am determined to resolve this communication problem. 2) Although I have successfully polled the device (set to address 2) using the built-in RS485 connection, the Micro820 does not seem to receive any responses or recognize a time-out. I suspect the issue may be related to the "message turnaround delay" of the slave device, as mentioned in the manual. I have tried adjusting the Micro820 protocol control settings to address this, but so far, it has not solved the problem. Could someone offer guidance or advice on these issues? Any help would be greatly appreciated. Thank you!
1) Can you provide the current IP address and netmask of both the PC and the Micro820 PLC? 2) For more information, refer to the manual at this link:https://literature.rockwellautomati.../documents/um/2080-um005_-en-e.pdf#G4.1045129 If you suspect that the Modbus (slave) device is Modbus RTU using RS-485, consider swapping the wires on the Micro820 serial port pins 1 and 2. Make sure to trigger the MSG_MODBUS instruction with a rising edge on its enable pin. Share the Micro820/CCW code (screenshot or PDF) that implements the Modbus RTU Master instruction, along with details from the LocalCfg/MODBUSLOCPARA and TargetCfg/MODBUSTARPARA input parameter blocks. Feel free to introduce yourself on the forum!
Hello Brian, I appreciate your assistance. Firstly, the PC's Ethernet adapter settings are as follows: the subnet mask is likely 255.255.255.0, with a link speed of 100/100 (Mbps). The IPv4 address is 169.254.0.1, and it is a Realtek USB GbE Family Controller #3. The PLC is configured with an IP address of 169.254.120.50 and a subnet mask of 255.255.0.0, although there may have been a typo while setting a static IP, causing a loss of communication. I have attempted to switch the wires several times. Initially, the device displayed that it was receiving requests and acknowledging them. I am not currently pulsing the Modbus enable pin; it remains consistently high. I believe setting the Trigger.Type to 1 is the most effective way to continuously poll the device. My program is currently focused solely on Modbus communication, with plans to expand once the communication is established.
If you configure the PC netmask as 255.255.0.0, you should be able to establish communication with the PLC. Alternatively, you can try setting the PC IP Address to 169.254.120.1. While the Modbus settings appear to be correct, there may be concerns about using TriggerType=1 via serial connection. The documentation for Micro8xx is limited, mentioning values 0 and 1 as valid options, with values 2-255 labeled as "Reserved". However, there is an example with TriggerType=100 provided. For reliable communication, it is suggested to use TriggerType=0 and implement a repeating TON with PT=T#1024ms triggering the IN pin of the MSG_MODBUS instruction. If faster data transfer is required, adjusting the TON .PT value incrementally to determine the optimal setting for successful communication with the Modbus Slave device.
According to drbitboy, the Modbus settings appear to be in order. However, there are a few key points to consider. It is assumed that the Modbus node address for the device you are trying to retrieve data from is 2. Additionally, it is assumed that you are looking to retrieve data from two holding registers. Specifically, the first holding register you are interested in is the 1004th register of the target device, which is located at an offset of 1003 from the first register of the device.
Welcome to the forum! It's great to see someone with your background here. For your first issue, it seems like you've already tried a few tricks. One thing you might want to double-check is making sure your PC and PLC are in the same subnet while troubleshooting the IP issue - this can often be overlooked. For the second issue, it's possible that your Micro820 and slave device timings are out of sync. Have you looked into the response delay setting of the slave device? You should adjust this along with the Micro820's timeout settings to ensure they match. It may not be solely a "message turnaround delay" issue. You also might want to try bench-testing with a few different devices to confirm it's a PLC issue and not a specific device-message compatibility issue. Let us know how it goes.
Welcome to the forum and we're glad to have someone with your background and expertise joining us! For your first issue, if you've accidentally changed your IP settings, you might try resetting the PLC to factory settings. This should revert it back to its default IP address, allowing you to regain communication. As to your second problem, it could be an issue with the RS485's termination or biasing causing the Micro820 not to receive responses. Check to make sure the network is properly terminated with a correct resistor at both ends, and that the biasing resistors correctly provide the necessary voltage difference. This might sound a bit basic, but sometimes these simple things slip through the cracks as we look for more complex solutions. Hope this helps and looking forward to your progress updates!
Welcome to the forum and thanks for sharing about your project! It seems like you've got a lot on your plate, but don't worry, we're all here to help each other out. Regarding your first issue, one solution might be resetting the PLC to its default factory settings which should include the original IP address. Look into your Micro820 manual on how to perform a factory reset, but remember to back up any data if you can. For your second issue, I had a similar problem and it happened to be a problem with the termination resistor. Have you checked yours? Also, consider adjusting the RS485 bias if that's applicable in your case. A faulty connection might not always reside where the data is supposed to come in. Good luck and keep us updated!
Hey there! Welcome to the forum! It sounds like you’re diving into some interesting projects with Modbus and the Micro820. For your IP issues, have you tried resetting the PLC to factory settings? This can sometimes help you regain access if the IP was changed accidentally. As for the message turnaround delay, it’s definitely worth double-checking that the protocol settings on both devices match. Sometimes, slowing down the polling rate can help if you suspect timing is off. Good luck, and don’t hesitate to ask if you have more questions—I’m sure the community will be happy to help!
✅ 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: Answer: To troubleshoot communication issues after changing the IP address settings on a Micro820 PLC, you can try solutions like updating firmware, checking RS232 connections, and ensuring the correct IP settings are configured on both the PLC and the device you are trying to communicate with.
Answer: Answer: The issue of not receiving responses or recognizing a time-out when polling a Modbus device with a Micro820 PLC could be related to factors such as the message turnaround delay of the slave device. You can try adjusting the Micro820 protocol control settings to address this issue and ensure proper communication setup between the devices.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.