Has anyone ever encounter problem when connecting to Siemens S7-300 PLC by Ignition?
I tried to use Ignition to connect to a Siemens S7-300 PLC device. At first, it was working fine, that was when Ignition server was in the same subnet as the Siemens S7-300 PLC. (say, if the server’s IP is aaa.bbb.ccc.100, then the Siemens’ IP is also in the aaa.bbb.ccc).
But when the Siemens PLC is no longer in the same subnet (say, the server’s IP is aaa.bbb.ccc.100, but the Siemens’ IP is in aaa.bbb.ddd), the Ignition cannot connect to the device. In the gateway, we can see that it keeps trying to connect (showing Connecting status) but always fail (showing Disconnected status).
Default port (102) is used for both cases.
Interestingly, when the server and the PLC are on different subnet, I can ping the server’s PC from the PLC, but not the other way round (which probably cause the error). This may not be Ignition’s issue but the PLC’s though I cannot be sure of that.
Can anybody clarify? Has anybody ever encounter such problem? Thank you!
If you want to communicate between 2 different subnets you will have to either change the subnet masks on each device (basically expanding the subnet to include both devices) or use a router. Depending on your OS you can set up multiple IP addresses on your PC and route between them so you don’t need a separate router.
I’m not sure how you can ping from the PLC to the PC - maybe the PC’s IP address is set as the PLC’s Gateway address?
We have done that in our test and our PC does not have multiple IP addresses as well. Unfortunately, it still didn't turn up well. =(
Currently our "suspect" lies with the device's driver itself. Still trying to figure out if we can find something from our further investigation. Thanks for the reply.
My next step would be to have a look at the communications using something like Wireshark to see what is actually going on and where it is failing. You might want to post a diagram of how things are set up along with the IP configuration of all the devices, just in case somebody can spot a configuration error.
I guess, that you want to connect remotely (VPN,…??) to the PLC?
In my experience, in 99% of cases, this is problem on the route between subnets. The IT people didn’t configure route properly between Ignition Gateway PC/Server and PLC.
On my last project we spend an hour together in the same office: I connected to the Ignition, my colleague on the PLC on the object, IT guy on his router/gateway/server/… network before they configured the route properly.
And I didn’t need to do nothing on the Ignition or on PLC.
I do not have any access on the exact network diagram (if this is what you meant) since the large network behind is managed by our client and is not accessible to us.
But it look like:
Ignition Gateway (subnet: aaa.bbb.ccc) <–> Local router (Ignition side) (subnet: aaa.bbb.ccc) <–> greater network (we don’t have access to scrutinize this) <–> Local router (PLC side) (subnet: aaa.bbb.ddd) <–> PLC (subnet: aaa.bbb.ddd)
to me.
Not sure if the diagram above can be of any help. But we also do not rule out the possibility that some of the network settings might have been the cause of it. So, we have contacted the network department of our client to see if there is any setting (such as security) which could possible block the message on one direction but not the other way round. But we haven’t gotten their reply yet and so we just look at other possible causes (within our own power to correct) first in order to either rule them out as possible causes (after investigation) or, if we were lucky, find out the actual problem.
But suppose the PLC driver (firmware) is a non-commercial, we thought that it would not be impossible that the non-standard way of coding it may cause this issue. We are still looking into the problem in this direction now.
I hope this case is also belong to the 99%.