Environment
- Ignition 8.3.6
- Siemens Enhanced driver — Symbolic addressing
- PLC: Siemens S7-1500 — firmware 4.0
- Affected tag: an INT written by the PLC, inside a UDT instance, read symbolically from an optimized DB (it's a "card number" used in a PLC↔Ignition handshake)
What happens
Whenever that INT tag holds a value below 64, the entire device connection stops communicating. Every tag on the device goes Bad and the connection reports as defined-but-not-established. There is no Gateway log entry, the tags just go Bad with the error "Communication with the datasource is defined but not established".
The behavior is:
- Value-dependent — only values
< 64trigger it.>= 64is always fine. - Total — it's the whole device that drops, not just that one tag.
- Self-clearing — I don't restart anything. The moment the PLC writes a value
>= 64again, communication comes back on its own. - It's clearly below the script/DB layer: tag event scripts never fire during the fault (nothing in the gateway logs), because no value updates come through at all.
Steps to reproduce
- Symbolic-addressing connection to an S7-1500, INT tag in an optimized DB.
- Have the PLC write a value
< 64into that tag. - The whole device goes Bad / loses communication.
- Write a value
>= 64→ communication is restored automatically.
Expected vs actual
- Expected: the value held by a tag should never influence device communication.
- Actual: values
< 64reliably take down the entire device connection until the value goes back up.
I'm only using symbolic addressing, so I can't compare against absolute/legacy addressing — I'd be curious whether anyone sees this only with symbolic. Optimized writes is ON.
Workaround (currently stable)
On the PLC I add 100 to the number before writing it to the tag, and I subtract 100 in Ignition after reading. The on-wire value is therefore always >= 100, and the problem hasn't recurred since.
Questions
- Has anyone hit this with Symbolic addressing on 8.3.x?
- Is there something about INT values
< 64in symbolic reads/writes I'm missing, or is this a known driver issue? - What logs / device diagnostics should I capture to turn this into a proper ticket? Happy to provide gateway logs and a packet capture.