Search the Community

Hello Everyone, Thanks for welcoming me to this forum, I am glad to be a part of the Mr. PLC community, finally. I have an issue with transferring licenses from the XTEL "Disquette de Autorizacion" to the XTEL software. The whole system from OS/2 to Telemecanique XTEL v6.1 seems to have installed successfully, all on a legacy system boasting a massive 500MHz Intel processor and 256 megabytes of RAM. I can create a project and follow the process all the way through to the final stage before connecting with the PLC. At this point it doesn't seem to matter what option I choose to try and connect with the PLC, all end with "NO SOFTWARE ACCESS RIGHTS" "PROGRAM COMPLETE". Having read an incredible amount of related posts across many forums; this forum offering the best solutions; I now humbly seek help from the good people of this wonderful PLC community. There are certain people on this forum with a tremendous knowledge of OS/2 and XTEL installations, and I hope to attract the attention of these fellow engineers. I already have a lot of respect for those who post here as you choose to give your time to help the wider community of engineers, fitters and programmers alike, saving the day in most cases, so thank you all in advance of your continued help and support. PS. I'm ready the manual "cover-to-cover" this evening.

Is it possible to add another AB Rockwell PLC to the network tree as a Generic Ethernet Module and use it as IO? Any idea where I would find information regarding assembly instance and size of I/O/C for AB Rockwell products? If possible, what are the pros and cons when compared to produce/consume and MSG instructions? Don't need to use it real world, just curious. Many thanks in advance.

Hi All, Networking guy here, looking for network experts on a AB PLC (1756-EN3TR/B v217021900) which seems to STOP ARPing for a device after 10 ARP's. The device is purposefully powered down, but when powered up, it can take minutes before the PLC sees it again. The PLC team says only changes in the PLC's logic are made. When an older backup is restored though, I do NOT see the issue somehow. 1) The devices that are powered down are back on the network and reachable within 10 seconds or so (ping). The initial thought was that they were not even on the network, but they are. Just that PLC shows a comms loss. 2) With the 'good code', the PLC, once the device is offine, keeps sending ARPs to find the device. The first one is a directed one, the subsequent ones are broadcasts. These broadcasts keep happening till the device is back online and is able to talk to the PLC again. 1st ARP after comms is lost: 474.423859 Rockwell_cf:a7:6c Hilscher_2e:ea:08 ARP 60 Who has 192.17.150.208? Tell 192.17.150.30 Next and subsequent ARPs after the first one: 475.423471 Rockwell_cf:a7:6c Broadcast ARP 60 Who has 192.17.150.208? Tell 192.17.150.30 These ARPs keep happening every 1 second, till the device is online again. 3) With the bad code, the PLC, once the device is offline, sends only 10 ARP messages total and then stops sending ARPs altogethe . Then it takes 10 minutes* before it sends another one. If the device is backup online by that time, the PLC finds it right away. SO with these 2 different code bases, how is that a low level L2 protocol like ARP is impacted so much. The PLC team tells me that they have no idea and not set anything related to it. My question is where is the ARP network behaviour governed and how to change it? How can older code which supposedly only has changes in logic have different ARP behavior? * The 10 minutes interval might lead people to think it's a ARP timer and most likely it is, but then people usually ask about gratuious ARPS (garp) and I've verified that they make it through from the device to the PLC OK. If the device is offline for say a minute, the PLC mirrored port does indeed see the garps, yet at that point the PLC is no longer ARPing and regardless of that garp, it has to sit out the time till it sends a next ARP till it connects. Thus, I suspect the coming back to life process is governed by the PLC ARPing for it, and not by the detection of a garps. Thanks everyone!