This resolution is designed to outline the reasons why a user may not see the error code from a communication block as well as the logic to 'capture' it.

Facts and Changes

• The code below applies to both Concept and Unity Pro.
• The principle of the code below will also apply to READ_REG, WRITE_REG, READREG, WRITEREG, CREADREG, and CWRITEREG blocks but may require some modification depending on the communication block being use.

Causes and Fixes

Communication block such as the READ_REG take several scans to solve. The error code the block generates is put into the status register for one scan and then replaced by a 0.
For this reason when the block fails to communicate to the slave device the error code is often not seen.

Logic to capture the error code must be added.

The READ_REG's STATUS output is configured as a located 4X WORD 400001. The code below is actually running in a controller communicating to a device that does not exist, so the block is currently in an error condition. The status register displays a 0 for say 9 out of 10 scans. Only during one of those say 10 scans, will register 400001 display an error code.
The code below is designed to 'capture' the error code. When the error output on the block goes high during that scan the error code will be moved to the STATUS output. The R_TRIG (rising edge trigger) will move the value in the status register into a table of register provided by the R2T (register to table)

Note: It is important to note the solve order of the blocks; the R_TRIG and R2T cannot be solved before the READ_REG.