Overview
M580 CPUs use both types of communication functions:
EF and procedure type functions
EFB type functions
For general description of the management of the communication functions according to their type, refer to Communication Functions Management.
Communicating with Remote Ethernet Drops
When a ***_MX communication function is used to perform communication exchanges with Ethernet drops, it is highly advisable to test the communication health status of the Ethernet drop before launching the communication function.
A communication function addressed to a faulty drop may take up to 2 minutes to complete, ending with an error status due to the transaction timeout delay (the remote participant has not answered within the timeout delay).
Example of Parameters Use in FBD
Following diagram in FBD illustrates how to get the channel 1 status information of a BMX NOM 0200 module located in rack 0, slot 3 of the drop instance number 3 (associated DDT could be for instance: MOD_COM_3 or if we keep the default naming EIO2_d3_r0_s3_NOM0200_3) at IP address 192.168.10.84.

read_sts_en_3 should be set to 1.
When the READ_STS_MX_3 block is not active, it is started if the variable read_sts_enable_3 is set to 1 by the user and the drop communication health status is OK. Every following scan until operation ends up with success (DONE set to 1) or with detected failure (ERROR set to 1).
In case of success, status words of the module may be exploited in the variable linked to the STS parameter of the block. If the communication link with the drop is broken, MOD_COM_3.DROP_COM_HEALTH falls to 0 and current active operation is aborted with error code 1001 hex. If ABORT pin is not connected, the block executes until the transaction timeout elapses (15 s for ***_MX functions) and ends up in error with status code 3401 hex.