How often does FC80 (station) write to GPI 4.0
Without knowing how your Controller (where the FC80 is sitting) is Segmented nor which controller type your are using (MFC/MFP/BRC?) it is hard to judge what is going on directly.
However the GPI program sits (typcially) in it's Segment. Each Segment (up to 8 are allows) have their own Segment time, normally set to 250mS. Unlike XR's, the GPI program is a 'C' compiled program, which reads and writes it's blocks out every Segment Cycle. Check your segment settings in the controller for what has been set.
Eitherway, given GPI normally links to the 3rd party PLC via Serial RS232 signals and most people do not wire these connections properly (see atached file for more details), the most common fault in this type of setup is earth problems. This can also be the case if the setup is old and/or has long cable runs. It is suggested to check this first. This is also likely if this problems started recently after a longer period of no problems.
i had a similiar issue with comms dropping out, although in my case its a brc410 using GPI v4 to a PLC5 on a dh+ network. So the setup is slightly different in GPI altho the physical network is still rs485. Regarding your question, the fc80 is still scanned as per its exception report setting based on where it is in your memory blocks, as i think you indicated.
As for gpi, AFAIK "The communication command/reply transaction rate may vary from 3 to 15 transactions per second. Rate transfer times depend on the amount of data that must be transmitted for the read group transactions"
In my case it was helpful to monitor the statistics and look for any errors or monitor execution time. You can also pull the error log to see if anything is being lost. See pg.67 4.7.7 Monitor (RTU, AB) in attached manual.
see attached screenshots, or the manual
In response to your other questions AFAIK the GPI does not perform any significant change processing on AIPs so any change of the FC value will be written, or queued to be written. Writing continuously changing data can be problematic. Operator entered SPs should not present a problem normally as the update rate is infrequent. Continuously changing supervisory SPs might need some additional pre-processing to add a significant change filter which has to be exceeded before writing across the interface. It depends largely on the individual interface and the number of AIP/DIP being written.
S4 of the invoke C block limits the AIP update rate. I think its entered in cycles not seconds. This applies unconditionally so it doesn't matter if the successive AIP value change is 10% or 0.01% it will be subject to the timing set in S4 so may not be what you are looking for. An alternative is to add your own significant change filter logic. S7 of the invoke C block can set a maximum update time for writes to the slave device. Normally, left at 0 (off) but could be set to at least (#AIP + #DIP) seconds to force periodic writes. This will affect interface performance to some degree as this adds transactions to the interface. Another option might be to read back the CCC SP values and take an action on a discrepancy. Good luck, Alan