I have a Micrologix 1500 system set up with a 1769-SDN module for communication with a 1769-OB32 24VDC output module, all controlled by a 1769-ADN module. The Micrologix is able to successfully read data from the adjacent 1769-IQ32 module at memory address I:1.66. In RSNetWorx, it is evident that the 1769-OB32 outputs are mapped to O:1.2 and O:1.3. However, despite activating bits in the ladder logic program, the outputs do not respond as expected. Upon further inspection in RSNetWorx, it appears that the 1769-ADN module is not detecting any signals being sent to the mapped outputs. Do you have any insights on this issue?
Before proceeding, it is crucial to review the basics: Are there any identified errors on the 1769-SDN display? Additionally, ensure that the "Run" bit in the 1769-SDN Command Word (O:1.0/0) is set to true while the MicroLogix 1500 is in RUN mode. While inputs may function properly in controller Program mode or scanner Idle mode, outputs may not be transmitted as expected.
Thank you, Ken, for the information. I have successfully configured the 'Run' feature and am now able to communicate bidirectionally.
Ken Roach inquired about potential issues with the 1769-SDN display and the "Run" bit in the 1769-SDN Command Word (O:1.0/0) while using the MicroLogix 1500 in RUN mode. Inputs function correctly in controller Program mode or scanner Idle mode, but outputs are not being transmitted. Another user is experiencing a similar issue with a remote backplane featuring 2x iq32 and 2 oq32 slots. While the equipment initially operated smoothly, 2 iq32 modules have lost communication while 2 oq32 modules continue to function. The user is seeking clarification on the run command for the slots. Can anyone assist with an explanation, please?
kindbu asked for help with a remote backplane issue involving 4 slots - 2 iq32 and 2 oq32. The equipment was functioning correctly but suddenly stopped working, with 2 iq32 modules losing communication. how can you explain the sSlots command? Can you clarify what the PLC is connecting to in the remote rack?
JeremyM inquired about the PLC connected to the remote rack. The PLC in question is a L61 model. Check out the image for further details.
Your issue sounds like it might be stemming from a communication problem between the 1769-SDN and 1769-OB32 modules. I had a similar issue and it turned out to be a simple addressing mistake. Make sure your addressing in both your ladder logic program and RSNetworX is consistent. Also, maybe try using explicit messaging in the ladder logic program as it provides better control over read/write commands. Checking your control status file, specifically "O:1/0.DN" bit, may also give you more details on why your output module isn't responding as expected.
That's quite a complex setup you have there. One possibility for the issue could be something as basic as a loose connection, so I would firstly recommend you to double-check all the physical wiring to ensure that there are no loose ends or damaged wires. Another area of inquiry could be to check if the cards might have a mismatch in communication protocols as it's crucial for successful data exchange. In addition to the above, take a good look at your ladder logic program. Make sure that you're correctly addressing the output bits in your program. The ADN module should detect signals sent to the mapped outputs if everything else is set up correctly. The 1769-OB32 module acting up can also be due to incorrect configuration in RSNetWorx, so do reassure that your configurations are as per the requirements. Lastly, module firmware issues could cause such scenarios, it might be worth looking into that as well.
✅ 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: This could be due to communication issues between the modules or incorrect mapping of the outputs. Further troubleshooting and inspection of the communication setup may be required.
Answer: Answer: You can start by checking the configuration settings in RSNetWorx, verifying the mapping of outputs, ensuring proper addressing, and inspecting the signal detection by the 1769-ADN module.
Answer: Answer: The issue could stem from incorrect configuration settings, addressing mismatch, faulty cabling, or network communication errors. Further investigation and testing are needed to pinpoint the exact cause.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.