Niteman9

Module works fine on node 24 or 40 but not when set to 26. Module from node 24 does not work when set to 26.

I have a PLC 5 system using ControlNet and Flex I/O.  We are updating the system and and changed one of the nodes from a 1788-cn2dn to a AnyBus  ControlNet to Ethernet. This works fine and is not the problem. The issue is one of the existing Flex I/0 node is not transmitting date. It is communicating we are just not seeing data in the PLC. The node of the Flex I/O is 26. We have an identical Flex I/O at node 24. When we swap them and readdress them still the node 26 does not show any data in PLC. Therefore we determined the hardware was OK. We deleted node 26 and added back in still not working. We then changed node 26 to node 40. Removed the node 26 from the ControlNet configurations and configured the new node 40. This is working and we are moving on with the project. We would like to understand what is going on here and change it back if we can determine the cause. If not we will have to update all the documentation to show this change.   Anyone ever see anything like this? We are stumped.

I am looking for opinions anyone has using the different flavors of Modbus TCP/IP remote I/O. I have as system that is currently using Momentum InterBus S I/O. This is on a Square D Sy/Max based system using an NR&D IBSM module in the Sy/Max rack. I am looking into the possibility of replacing the IBSM with a EPE5-T and using Modbus TCP/IP I/O. I have seen this type of I/O from several manufactures. (Beckhoff, Turck, Moxa, .....) I am just looking for an reviews for any of the Modbus TCP/IP I/O. I may make the most sense to use Schneider Electrics Momentum I/O with the Ethernet top hats. I issue I have with that is the managers will see it as the same thing they already have.(looks similar to the InterBus S I/O)

Here is the procedure I found to work. Changing Source protection 1. This has to be done offline and downloaded so upload and save before starting. 2. Changing Source Protection 3. Click tools 4. Click Security 5. Click Configure Source protection 6. Open each Program and select the routines you want to change 7. Click Protect and type a new name of you choice in the dialog box. 8. Check Allow Viewing of Components check box to allow someone with out the key to view the protected routines. You can do this for each routine or select them all and do it once. 9. Click OK Repeat for all program sections for all programs and routines if you did not do them all at once. 10. Click the close button 11. Download program to PLC. 12. Enjoy you new found security. I agree Locking processors or adding source protection can be problematic down the road. But until a customer buys off on a line and pays it is needed. Once final buy off occurs the protection should be removed. Unfortunately this does not always happen.

I have it figured out now just waiting to see if management want to do it or not. Thanks

Thanks for the information. But you did not address my question. I am the original programmer I have the SK.dat file. I want to change it to another SK.dat file because my management gave the old SK.dat to the customer but now are asking if I can again lock the customer out from making changes. We want them to be able to view the code to troubleshoot but not make changes. I think I have an idea of what to do but was looking for some advise. The line is running and really don't want to experiment. So here is what I am look to do. Create a new SK.dat file which will give our guys full rights and only allow viewing if one does not have the new SK.dat file. Anyone have a procedure to do this? Thanks

Hello, I have a question about RSLogix 5000 Source Protection. I have 9 processors all of which are using source protection. Management provided the customer with the SK.DAT file but now would like to lock them out. We also have the Logix Security Tool but would like to give them access to view the program just not change it. Does anyone know if the source protection can be used to allow us to have full access and give them view only access. If so how do you do this and what is the procedure to do this with them having the current SK.DAT file. Thanks

Paul, Thanks for all the information. It is more then I ever expected. I am still processing all of it. All of the PLC's RP!'s were set at 20 msec. I increased each to 150 msec. We are not sending much data from PLC to PLC. We are only sending one UDT to each processor up and down stream. So 2 UDT is the max we are sending over Ethernet. When I changed the RPI's my heartbeat watchdogs went from about 50 msec to 200 msec which was expected. As for the HMI we are using UDT's. I checked all of the EN2T/B cards and all are under 300 PPS with the limit being 20000 PPS so I do not think we are overloading the EN2T/B cards. The thing I am have the most trouble understanding is we will go 3 or 4 hours with watchdog timers never going above 500 to 700 msec then get one occurrence of 4, 5, 6 sec. Then no issues for the next few hours. Our IT department tested all of the cables which connect the PLC's panels with the Central Managed switch. All tested OK.I feel it is something in the central managed switch which is causing the problem but have no proof of this.

Thanks for the replies all good info. The network is set up as follows. Each PLC panel has a unmanaged switch which connects the PLC the HMI's and the Safety PLC. Each of these unmanaged switches are connected to the managed switch. There is no other connections on the network other than laptops used to access the PLC's. The idea in setting up the network as it is was to allow the HMI's to only communicate with the one PLC. No I haven't gone to deep into the managed switch. The leader of this project is the one who set it up and he is no longer with the company. Also the whole network doesn't go down when we have a problem. Its one link between two PLC's. Also yesterday it only happened twice between two PLC and once between two other PLC in a 12 hour production run. One recorded 9.8 sec with the heartbeat off and the other was 5.2 sec. So far today the max time on any link is 380 msec. The network engineer they brought out it the IT guy from the office. Not sure he has any industrial experience.

I have a system which has 8 Controllogix 1756-L62 processors. Each cell also has between 2 to 5 PanelView Plus 1250's and one Pilz safety processor on the network. I am checking a heartbeat signal from one PLC to the next. So the firs PLC interlocks to the second the second to the first and third and so on. My heartbeat watchdog timers usually reset in under 100 msec. Occasional they will not reset for several seconds. The highest I have recorded is 9.8 seconds. The PLC IP's are 192.168.2.100, 192.168.3.100 through 192.168.9.100. They have a subnet of 255.255.240.0. Each PanelView is addressed as 192.168.2.101, 102, 103. For each PLC with a subnet mask of 255.255.255.0. The eight PLC are linked with a MOXA EDS-516A managed switch. So based on what I know the Panelviews for each cell can not communicate with the other PLC's. My company had a "Network Engineer" come and check it out and his suggestion was to put every thing on the same subnet by changing all IP's so the third numbers were all the same. I think this will increase traffic on the network and cause more issues. Anyone have any suggestions.