HI All,
pinged ok to PLC.
Siemens S7-1500 connection established in OPC in the gateway. No errors in the log. S7-1500 setup as symbolic, not absolute.
Browsed in designer and found the blocks and tags. Have "Bad_NotConnected" on the values of the tags. The timestamp is from when the PLC is first connected but then data isn't being repolled or refreshed.
The error on the data is:
[null, Bad_NotConnected("Communication with the data source is defined, but not established, and there is no last known value available."), Wed Jul 30 16:41:18 ACST 2025 (1753859478154)]
Is there something obvious I am missing here?
Regards,
Gareth
I had this problem as well when I dragged all the tags in from one of our S7-1500s...
if you set the "drivers.SiemensSymbolic" logger(s) to DEBUG do you start seeing a message like this in the logs?
DEBUG
SymbolicAddressSpace
30Jul2025 04:17:34
read: read call failed: AGL40_SYMBOLIC_NOT_APPLICABLE
de.deltalogic.accon.aglink4.AglIOException: Method: 'symbolic_CreateAccess', Error Code: 'AGL40_SYMBOLIC_NOT_APPLICABLE', Error Nr: '0xFFFA0000', Error Message: 'AGL40_SYMBOLIC_NOT_APPLICABLE',
for me there seems to be one or more "bad" tags somewhere that bring the whole read request down.
Anyway, the right developer should be taking a look at it today.
As Kevin said, I'm looking into a similar issue today. If you could check the debug logs, it can help confirm if this is the same issue or something different.
No problem, I will check the debug and report back in this stream
Hi Cody and Kevin,
I have uploaded two log files with debugging.
Our team helped with the diagnosis.
Gateway
We did some standard data connection testing with disabling the S7 OPC connection, then removing the cable etc. No joy. "Bad_notconnected" and the timestamps were not updating. This is the log A file and was downloaded with a timestamp of 0859.
Designer
We then removed the groups of tags we had previously dragged over and started with some specific tags and added them individually. This was good and provided good data transfer. Not particularly important but these were alarm tags that we were able to toggle the "test_alarm" tag and trigger the other alarm tags we added.
We added some global clocks, and they worked ok. We then dragged the folder of tags from yesterday and broke it (somewhat deliberately). Daniel (much more experience than I) sorted through this folder and with a couple of trial-and-error attempts found a tag that assigned as a "String" datatype that is not designed as a string datatype in the PLC. Daniel removed this tag and the whole folder of tags communicated correctly. We confirmed good timestamps that were updating.
This is LOG_B.
We are working out the original datatype of the tag that caused the break. Hopefully the logs are helpful.
[Logs redacted]
Regards,
Gareth
I've edited this post to redact the log files in case there is any sensitive information there. I have them downloaded and will review them tomorrow. -Cody
1 Like
Thanks Gareth! This is very useful. I'll take a look at the logs in the morning.
After looking through your logs, I've found that this is a similar but separate issue from the one Kevin referenced earlier.
Unfortunately, this issue seems to be the fault of the third party library we are using. An exception is being thrown during the read call, but the "error" message returned is AGL40_SUCCESS
.
With the issue that Kevin referenced, the failure is reported by the library in a tag-specific manner. I have already drafted a PR to handle this issue. However, for the issue you are seeing, the library does not make clear what the issue is, let alone which tag has an issue.
We are working out the original datatype of the tag that caused the break.
Any info about this tag on the PLC that you can get me will be very useful. I'm going to attempt to repro so that I can get some more information to the vendor about this issue. If you need a place to upload files related to this issue, feel free to use this dropbox file request: