Knowledge Base

# 4D_NackEvent(Handler) hash function

This is stuff you can safely ignore if it is hard to understand. It is really only needed if you need to trouble-shoot erratic communications with the 4D display

If something goes wrong in the communications between the SPLat and the 4D display (caused, for example, by a loose connection or some electrical noise), the 4D may send a NACK (Negative ACKnowledge) message to the SPLat. Two things happen if this occurs:

  1. The SPLat (courtesy of the under-the-hood code generated by the hash functions) will attempt to repair the communication link by generating a special sequence of messages to the 4D display.
  2. If you have a 4D_NackEvent(Handler) hash function in your program, a GoSub Handler will be executed. You can then have a subroutine with the label Handler (or whatever you want to call it) that does something useful, like for example count the number of NACKs for debugging purposes.

Example:

Say that somewhere in your program you have the following line:

# 4D_ViSi  4D_NackEvent(evGotNack)	;Declare the event handler for 4D NACK events

You could then have an event handler subroutine that looks like this:

;Event handler for 4D NACK events
evGotNack:     IncM        bNACKcount    ;Count NACKs
               Return
bNACKcount:    defBYTE
The protocol handler in SPLat does not have a retry-on-NACK mechanism. Our experience is that if a NACK occurs there has most likely been a loss of message sync, and the most important thing is to re-synchronise the communications.