I have a customer running Ignition v7.9.10 that handshakes some data with a 1769-L33ERM v24.13 PLC. They are having a problem where they write some data to an Add-On-Defined (AOI) tag in the PLC but the PLC gets the wrong data. The customer then changes the PLC tag name from tag1 to tag2, updates the Ignition end of things, and the problem goes away for a few months. A few months later the same problem starts appearing again.
My theory is the Ignition Gateway is getting confused at some random point of time… is there any evidence to support this theory? I’d like to be able to tell the customer they need to upgrade to 7.9.18 and not get this problem anymore.
The PLC data type is 11 BOOLEANS followed by a DINT. Ignition reads/writes to 6 of the BOOLEANS.
Sidenote: One problem I noticed in 7.9.10 is if I have an array of 128 BOOLEANS in the PLC Ignition 7.9.10 reads those tags as 4 DINTS. This again makes me think the older version of Ignition had some conversion issues when reading/writing to PLC tags.
Instead of doing this, try an edit/save on the device connection, which will force a re-browse. This does not sound like a known issue with a release note you can point to, so maybe we can narrow it down a little.
The Logix v21+ driver has always exposed bool arrays as an array of DINTs because that's how the PLC represents them internally (and we screwed up and didn't fake out the representation in the address space before release).
I will see if changing the tag name back causes the issue again so I can test this idea. Otherwise, we will have to wait a few months for the problem to come back
The PLC turns on Req_Out telling Ignition to run a script. Ignition writes to pass or fail on the Ignition side. If Ignition writes fail then the PLC turns on the ER bit which I can read on the Ignition side…
I’ve confirmed with message logs that the script runs once but turns on the ER bit even if Ignition writes Pass. Hence, someone is writing Fail to the PLC… but I’ve confirmed it isn’t this script and it isn’t the PLC writing to ER outside of if the fail is turned on.
If this were some mixup in the driver where the instance ids in the PLC changed without the driver knowing then once it started occurring it would occur every time you tried to write to the Pass tag. You would be able to reproduce it by doing a system.opc.writeValue call to Pass and e.g. with Studio 5000 open see the Fail tag get written to instead and the ER tag go on.
Troubleshooting this is going to be a long, slow play where you wait for it to happen again to try these things. That alone might be enough reason to convince an upgrade and hope for the best
