I'm using TIA portal siemens v15.1 for my project when i tried to upload the code to the plc this error pops up. Appreciate anyone can help me in this issue
2 Answers
Nothing special, TIA is a master of troubles and issues. First, make a correct settings for your PC ethernet NIC, make the IPv4 to be in the same subnet, for example 192.168.0.150. Then plug the cable from your PC to PLC, choose PN/IE, select the NIC you want to use (those that you configured a static IPv4), direct slot x1, start search.
If it doesn't work restart the PC.
-
\$\begingroup\$ No this error appears when I tried to simulate via software, I already added IE general & wincc RT advanced. \$\endgroup\$– AishaCommented Jul 21, 2020 at 17:14
-
\$\begingroup\$ @Aisha But do you have the plcsim running? \$\endgroup\$ Commented Jul 21, 2020 at 17:29
-
-
\$\begingroup\$ +1 -- my additional step would be to turn off your Wi-Fi. I find that it interferes more often than not and it is just easier to remove it as a variable. \$\endgroup\$– user199402Commented Aug 10, 2020 at 15:27
What does your layer 2 (Ethernet) network connectivity look like? Just a direct cable? (Does straight / crossover matter?) Or are you running this through a switch? If so, what sort? Dumb, or managed? If managed, does the switch know anything about IP multicasting = does it support IGMP Snooping?
Not sure if this was the TIA portal or some other Siemens PLC config software (of the Simatic stable), but once upon a time I've witnessed a problem where some such management software could not find the Profinet devices it was supposed to configure/manage. Ping did work, Profinet IO payload sessions did work, but device detection in the "studio" did not.
Wireshark disclosed that the "studio" software on the PC was using multicast destination addresses (possibly L2 multicast, not necessarily L3 multicast, I don't remember anymore) and the packets to multicast destination did not pass through the switch (got dropped / filtered by the switch).
From there, it turned out that the switch had IGMP snooping enabled (user configurable option of the switch management firmware) and apparently the Siemens Profinet devices do not run IGMP, so the switch did not know about any multicast recipients (who would've subscribed via IGMP), and therefore did not open any port to multicast traffic.
If you have this kind of "simple multicast traffic pattern without IGMP", you need to disable IGMP snooping in your switch. As a result, the switch will effectively broadcast any traffic with a multicast destination address. This is also what dumb (unmanaged) switches apparently default to.
Not sure how TIA Portal works with the network stack on the PC where it runs. I mean - at the device detection stage. It possibly uses a raw socket to send L2 multicast, or it may have a filter driver installed to do this in the kernel space. No idea. I mean to say that you should try disabling the Windows firewall, just speculatively, to see if that makes a difference.
Even if you do not want to install and run Wireshark on the PC with TIA portal (Wireshark installs another filter driver for the packet capture, I believe - which might clash with TIA portal, not sure, I've never tried) , you can always plug in another computer running some sniffer (Wireshark et al) into the same switch, and if you can see the multicasts coming, you know that this is not your problem. Unfortunately, through a switch, you won't see any unicast responses from the devices responding to the multicast detection probe... for that you'd need a mirror port on the switch, or a hub (cough) or a device called the passive tap.
EDIT: so the slaves/devices are simulated? There's no physical network? I intend to leave my answer here, as it might help other people...