We recently had an issue of a sequence action appearing to "skip". We soon discovered that it was not skipping, but that there was an issue with how we confirm written values. I would like to see if anyone can validate this theory.
To provide an example: If a sequence action writes "@MODULE@/CAS_IN := 30" we will typically configure the Confirm within that action to "@MODULE@/CAS_IN = 30". I suspect that this confirmation will ALWAYS be true and instantaneous. I think this is the case because this confirmation does not require a module scan. If the confirmation were instead: "@MODULE@/PID1/CAS_IN = 30" then the module would have to scan successfully and the PID1 block would have to be written to by the CAS_IN parameter. My theory is that when you write and confirm the same exact parameter path, the statement will always be true and always be instantaneous. I think this may be because there is some "register" or "unloaded online value place-holder" of sorts for online values. The confirmation verifies the register but not the actual online module parameter, and thus does not require a module scan, and therefore is always instantaneous.
Can anyone comment on this?
In reply to JDWheelis:
In reply to Eric Gratz:
No the value will always initially be 0 for AWST but you can look in Books Online for some more information under:
One note about the last suggested section is there is a bullet item talking about when using AWST and it describes a time delay of 1 second required when writing and checking, this isn't required and I thought this was getting updated but apparently it hasn't been updated yet. Checks for AWST can be done immediately without a time delay in your configuration.
In reply to Matt Stoner:
In reply to Brian Hrankowsky:
I've never seen it necessary as we have been using this confirm style (no delay) for a very long time (version 4/5 or earlier). I actually had conversations with Product Engineering in Austin on this topic who initially thought it was still needed but they had tested nearly 1/2 billion writes, exceeded some recommended limits and had no failures. As a result the KBA AP-0900-0113 was modified in Aug 2018 to remove the below comment (which you won't find in the document other than in the revision history and the same documentation as Books Online).
When using an AWST (Asynchronous Write Status) in a Pulse Action confirm expression or a transition expression, the PARAMETER.AWST status value will initially be “0” (Success) before the pulse write becomes active. A time delay of 1 second is required between writing to the PARAMETER.CV and checking the PARAMETER.AWST; the .AWST status should cycle from “0” (Success) to “2” (Write Pending) and back to “0” (Success) in approximately 0.5 second for a successful write.
Not sure if that is the documentation you would need or not but I think if you had the earlier version of the KBA with that verbage in it and the latest shows it has been removed would be good enough.
In reply to Michael Krispin: