Handshake not writing, on success or failure

I have a transaction group which is triggered by a combination of two Boolean tags. When MAC_TO_SQL_DATA_READY is true and SQL_TO_MAC_DATA_RECEIVED is false, an expression item becomes true and the transaction runs. It writes a record to the database based on several other OPC tags. Then it has two triggered expressions, one of which is a SQL query and the other a SQL insert.

I have selected the option to write a handshake on success, which would set the SQL_TO_MAC_DATA_RECEIVED tag to true. This never works. I thought that maybe the problem was that the SQL query item was returning NULL, which in turn causes the SQL insert to insert no records, even though the status does not show a failed execution… This is still something that would be considered success from an operational standpoint, but I can see how it might mean that the transaction as a whole is considered a failure. So I checked the option to write the same handshake on failure as well, and it still never writes.

I’m sure there’s just something wrong with how I’ve set up the transaction, but I’m stumped. I’m attaching the transaction as an xml export.

Thanks,
Dan

Hi,

I can’t see anything wrong with that group. The only thing I could say is that if the write went through, you wouldn’t see it in the group for 30 seconds. When is it reset by the plc?

If you want to get confirmation that the write is being executed, you could try going to Console>Levels in the gateway config area, and turn the logger “XOPCServer.services.WriteService” to “TRACE”. This will write quite a bit of info for each write, so don’t leave it on long. However, turn it on, let the group execute, and then perhaps open “{InstallDir}\logs\wrapper.log” and search for “SQL_TO_MAC_DATA_RECEIVED”. There should be two messages, one for WriteRequest, and one for WriteResponse.

Let me know what you find,

Colby,

Thanks for the response. But I was out on Friday, and by the time I read it, the vendor had come to site to deal with other issues and had changed things so drastically that this problem was no longer occurring, new problems were introduced and resolved… Anyway, this problem has at least gone away for now, and I can’t get that trace info, and I don’t see anything behaving unexpectedly on the Ignition side.

Thanks,
Dan