New Siemens Drive Setup

Has anyone had any luck getting the new Siemens driver to work with an S7-1500 yet? Everything looks right, but the status just says “Disconnected” with no more info than that

Any warnings or errors in your gateway logs?

1 Like

You'll need to turn the Siemens related loggers to debug level in order to troubleshoot the connection issue.

1 Like

No issue here.

Connecting to S7-1512 (Compact and ET200S formats) with symbolic access. Works flawlessly, accessing either datablocs or plc tags.

Security is low on the PLCs though. That might help.

2 Likes

Hi Ryan, Now i’ve turned on the debuger i’m getting this error
S(LOADING) x E(LoadSymbolsFailure[cause=UaException: status=Bad_NoCommunication, message=Next reconnect attempt in 254334 ms]) = S'(LOADING_WAIT)

And also
Failed to load symbols

at com.inductiveautomation.ignition.drivers.siemens.SiemensS7Client.withConnection(SiemensS7Client.java:182)
at com.inductiveautomation.ignition.drivers.siemens.SiemensS7Client.loadSymbolsFromPlc(SiemensS7Client.java:141)
at com.inductiveautomation.ignition.drivers.siemens.SymbolFsm$SymbolFsmFactory$ClientActions$1.loadSymbolInfo(SymbolFsm.java:446)
at com.inductiveautomation.ignition.drivers.siemens.SymbolFsm$SymbolFsmFactory.lambda$configureLoading$3(SymbolFsm.java:284)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)

That looks like a pure communication error. Check your firewalls and routers along the path to that device.

Collect a wireshark packet capture of each connection attempt and share it here.

You may get a little more information about why it was unable to connect if you can grab the logs while it is attempting to reconnect. Unfortunately, in this beta there is an issue with the reconnect delay having an extremely high cap (32,000 seconds, instead of 32 seconds). This will be fixed in an upcoming version. The log message you shared doesn’t include a reconnect attempt, it is only telling you that it won’t attempt to reconnect for another 254 seconds.

Try to grab the logs after disabling and re-enabling the device connection, while the debug loggers are enabled. Then, share all of the logs, and I will be happy to look for the relevant message.

If you’d prefer, you can upload the logs to this dropbox:

I’ve managed to capture what looks like a reconnection request

DEBUG
SiemensS7Client
14Aug2025 17:56:48
Error connecting
de.deltalogic.accon.aglink4.AglIOException: Method: 'Connect', Error Code: 'AGL40_PLC_NOT_FOUND', Error Nr: '0xFFF5001C', Error Message: 'AGL40_PLC_NOT_FOUND',
at de.deltalogic.accon.aglink4.FunctionsConnect.connect(FunctionsConnect.java:150)
at de.deltalogic.accon.aglink4.AglConnection.autoConnect(AglConnection.java:458)
at de.deltalogic.accon.aglink4.AglConnection.connect(AglConnection.java:261)
at de.deltalogic.accon.aglink4.AglPlcConnection.connect(AglPlcConnection.java:346)
at com.inductiveautomation.ignition.drivers.siemens.SiemensS7Client.fallbackToUnsecureConnection(SiemensS7Client.java:326)
at com.inductiveautomation.ignition.drivers.siemens.SiemensS7Client.symbolicConnect(SiemensS7Client.java:314)
at com.inductiveautomation.ignition.drivers.siemens.SiemensS7Client.connect(SiemensS7Client.java:86)
at com.inductiveautomation.ignition.drivers.siemens.SiemensS7Client.withConnection(SiemensS7Client.java:177)
at com.inductiveautomation.ignition.drivers.siemens.SiemensS7Client.loadSymbolsFromPlc(SiemensS7Client.java:141)
at com.inductiveautomation.ignition.drivers.siemens.SymbolFsm$SymbolFsmFactory$ClientActions$1.loadSymbolInfo(SymbolFsm.java:446)
at com.inductiveautomation.ignition.drivers.siemens.SymbolFsm$SymbolFsmFactory.lambda$configureLoading$3(SymbolFsm.java:284)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)


DEBUG
SiemensS7Client
14Aug2025 17:56:48
Falling back to unsecure connection
DEBUG
SiemensS7Client
14Aug2025 17:56:48
Error creating secure connection.
de.deltalogic.accon.aglink4.AglIOException: Method: 'Connect', Error Code: 'AGL40_PLC_NOT_FOUND', Error Nr: '0xFFF5001C', Error Message: 'AGL40_PLC_NOT_FOUND',
at de.deltalogic.accon.aglink4.FunctionsConnect.connect(FunctionsConnect.java:150)
at de.deltalogic.accon.aglink4.AglConnection.autoConnect(AglConnection.java:458)
at de.deltalogic.accon.aglink4.AglConnection.connect(AglConnection.java:261)
at de.deltalogic.accon.aglink4.AglPlcConnection.connect(AglPlcConnection.java:346)
at com.inductiveautomation.ignition.drivers.siemens.SiemensS7Client.symbolicConnect(SiemensS7Client.java:299)
at com.inductiveautomation.ignition.drivers.siemens.SiemensS7Client.connect(SiemensS7Client.java:86)
at com.inductiveautomation.ignition.drivers.siemens.SiemensS7Client.withConnection(SiemensS7Client.java:177)
at com.inductiveautomation.ignition.drivers.siemens.SiemensS7Client.loadSymbolsFromPlc(SiemensS7Client.java:141)
at com.inductiveautomation.ignition.drivers.siemens.SymbolFsm$SymbolFsmFactory$ClientActions$1.loadSymbolInfo(SymbolFsm.java:446)
at com.inductiveautomation.ignition.drivers.siemens.SymbolFsm$SymbolFsmFactory.lambda$configureLoading$3(SymbolFsm.java:284)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)

Not sure if this helps if not i’ll get the logs downloaded

The SCADA machine and the PLC are on a flat network there are no routers, there are some managed switches it goes through as it’s in our test lab. I’ll have a go at bypassing the switches see if they are causing issues with profinet (wouldn’t be the first time)

S7 protocol and Profinet are two very different things:

Profinet is a near real-time remote IO protocol that runs on Layer 2 of the network stack. Profinet is not able to pass through a router (read this as - all profinet stations must be on the same subnet, but this subnet could be passed through VLANs as they are a Layer 2 function)
Because profinet is a near hardware level protocol, you also will have issues with switches (managed and unmanaged) that are not listed as "Profinet Conformance Class A/B/C"
We regularly see issues on machines that buy switches such as the Weidmuller IE-SW-EL08-8TX, where profinet will repeatedly drop connection.

S7 protocol (Can't remember the exact proper name for it) is the protocol that Ignition or other systems (also WinCC I belive) use to read tags from the S7-xxxx PLC. It is not a remote IO protocol, and is not close to real time.
What makes it useful is that it is routable at layer 3, supports queueing of requests and is a more IT friendly protocol that works on TCP/IP hardware universally.

I believe your troubleshooting will benefit from the definitions, S7 Protocol is the one you are looking at, and it is much easier to look at due to being IT friendly.
What I do see in your logs is that the driver is trying to connect to the "Secure Connection" but is falling back to "Unsecure".
Have you set up security on the S7 PLC?

When using the Symbolic address space, the driver always attempts to make a secure connection first. If that fails, it will try an unsecure connection. This is normal.

The useful bit of information in the logs here is “AGL40_PLC_NOT_FOUND”

As Phil suggested before, this is a general communication error. Double check IP address, port, rack number, and CPU slot number.

1 Like

I had the rack and slot number both set to zero; these are now set to 0 & 1 and plugging the laptop straight into the PLC, it still doesn’t work in Symbolic mode. It does work in absolute mode now and connects straight away. Any idea why it wouldn’t work in symbolic mode?

That has me stumped. There is probably some configuration in tia portal for the PLC that allows/disallows this type of connection. I'll try to poke around to see if I can reproduce.

Are there any other error messages in the logs, other than “AGL40_PLC_NOT_FOUND”?

Not that I haven’t listed already, I’ll have another poke around on Wednesday when I can get back on it.

1 Like

Thanks. It’ll probably be tomorrow or Wednesday before I can start really poking at it, also.

Are you using UMAC, by chance? Do you know what firmware version you have on the PLC?

Apologies, I’ve just had another engineer check over my setup with me, turns out the IP address I was using was for the RIO rack in the panel, not the CPU. :sweat_smile: No idea how I got that wrong. On the bright side the absolute driver can establish a connection with an IO rack for some reason

4 Likes

Cool. TIL. Glad you got it figured out, and thanks for updating this thread!

1 Like