Below I describe how the controller can interrupt a non-interlocked data transfer to send commands and allow it to resume again without any loss of data or sending of redundant data. Three separate cases exists that will be analyzed:
1) The controller is a listener accepting data in the non-interlocked mode.
As a listener, the controller’s Acceptor Handshake function will be transitioning between ANDS and ANES on the assertion and unassertion of DAV respectively. When the controller wants to take control it will set it’s local message "tcs" to true, causing a transition from ANAS to ALNS and then to ANCS after T17. If DAV is not true the Acceptor Handshake function transitions from ANES to ACRS. If DAV is true it transitions from ANDS to ANTS where it accepts the byte that is currently being sourced then transitions to AWNS. Both AWNS and ACRS are part of the original IEEE 488.1 Acceptor Handshake function and from either of these states the controller can take control and source commands in the same manner as the original specifications.
2) The controller is a talker sending data in the non-interlocked mode.
The new Extended Source Handshake function is very similar to the original SH function and likewise the controller can take control in the same manner. When the SHE is waiting for the next byte ("nba" to become true) while in SGNS the controller can issue a "tca" local message instead of an "nba". This is safe since while in SGNS no transfer is in progress. This causes the controller function to assert ATN forcing the SHE into SIDS. When the controller function goes into CACS the SHE moves back to SGNS but this time with ATN asserted so it is ready to send commends. This is exactly the way the original SH function operates.
3) The controller is neither talker or listener during a non-interlocked transfer
It is not possible for the controller to take control synchronously if it is neither a talker or listener. This is true for both the original IEEE 488.1 specification and the new draft. To solve this the controller must assert the "lon" local message to force it to listen before it unasserts ATN. This situation is exactly the same as the first case described above since the controller is also an active listener.
The other issue I was suppose to look into was the default state of the interface functions, specifically, it was preferred that an explicit command be required to enable the non-interlocked handshake mode of operation. Upon further investigation it turns out that no non-interlocked transfers can take place without the controller explicitly issuing a CFGx command. I will walk through the sequence of events that will illustrate why this is true.
The Controller function enters CNCS upon power-on ("pon") and the controller stays in this state until a CFGx command is sent. If a CFGx command is never sent then the controller stays in CNCS indefinitely.
While the controller is in CNCS, the SHE function will not enter SNGS which is the state that asserts NIC to indicate the beginning of a non-interlocked handshake transfer. (Note: the transfer from SIDS to SWRS includes the term not CNCS, from SWRS the SHE function transfers from SRDS then SNGS).
If the SHE never asserts the NIC message then the AHE will not transition into ANAS (Note: the transfer from AWAS to ANCS includes the term NIC, from ANCS the AHE function transfers to ANAS). If the AHE function never enters ANAS then it never enters ANDS thus staying in the original interlock handshake mode.
In conclusion, unless the application explicitly sends a CFGx command then the controller, source and acceptor handshake functions all remain within the original interlocked handshake states and behave as the original mode of operation. No non-interlocked transfers will take place and the new message NIC will not be sent until a CFGx message is issued. Therefore the application program has complete control over the types of transfers that are conducted.