This is a perfect example of why we advise our integrator partners that they need to have Metasys experience available before starting an integration project. The bottom line here is that the logic in the N2 device itself has the final say about what actions will be allowed.

One of our integration partners were seeing unexpected results when trying to write to a the Occupied Command point on a N2 device.

They sent S4 the application they have loaded in their customer's N2 device and I was able to load it into an identical device here in our lab. I can write to the Occupied Command point and see Occupied Status point value follow. This is what I would normally expect to happen. In the field installation we saw the N2 write transaction, and its acknowledgement as expected. But, immediately after that we observed that the Occupied Status did not change as it does here in our test environment. Why?

Here's what we found. In this case, there are interlock points defined in the N2 device's program Single Side Loops.  When these are present, and specific values are applied to the physial inputs, the Side Loop logic drives the Occupied status back to its original state when a N2 write transaction is performed.

To resolve this issue the Source String in the Device Type Template definition needs to specify a N2 Override transation is necessary instead of a N2 Write transaction.

Here is an example showing the override attribute added to a point and the corresponding release point.

“Investigate before you integrate....”