View Full Version : AC500 Diagnosis Function Blocks

April 6th, 2015, 04:16 PM
I'm trying to use the DIAG_GET (or something similar) function block to detect an error on an AI563 (Analog TC module). The error is class 4, a TC wire being disconnected or something like that. I can read the error using the DIAG_INFO function block, but can't seem to read it using a function block that looks to the actual module. The DIAG_INFO acts like a latch and if the error goes away, the tag is still set to TRUE until something unlatches it. Just wondering if any of you have used the DIAG_GET or IO_MODULE_DIAG function blocks.

Also, is there a way to open these standard function blocks up to look at the logic behind them? If I could see what tags/values they are looking at, I'm sure I could create my own function block.

Any help would be appreciated!

Highland Controls
April 7th, 2015, 12:28 PM
Most of the PLC errors are retained until you acknowledge(DIAG_ACK_ALL, DIAG_ACK), or reset (DIAG_RESET). There is typically no way to see the code on these types of function blocks. FYI, the broken wire detection did not work properly on the AI563 until version "Index A5". Previous versions did not detect a single open T/C.

April 7th, 2015, 12:42 PM
We were looking for a way to automatically clear the PLC error when the module error is fixed. The IO_INFO and IO diagnostic function blocks looked promising, but they seem to only detect errors (class 1 and 2) and not warnings (class 3 and 4). I'd like to write our own function block that clears the CPU error when the module warning is fixed, but I'm not sure what tag or where the CPU is looking to determine if it has a class 4 warning.

Highland Controls
April 7th, 2015, 12:47 PM
Use DIAG_INFO to see if there is an error in each class. Wire the E1, E2, E3, and E4 output to the EN input of DIAG_GET(CLASS inputs required) to get details. You can then clear only a certain class if you want.

April 7th, 2015, 01:14 PM
I've played with the DIAG_GET function block, but it doesn't seem to pick up on the class 4 warnings. I attached an image of the code I have.

Highland Controls
April 7th, 2015, 01:43 PM
I don't have something setup to go online with, but I am pretty sure I was getting Class 4 errors. I see that that FB isn't getting "Done". Expand the tree for "TestDiagGet" in the declarations section while online and see what is happening. I know that I look at both the CODE and ERROR outputs in my program.

April 7th, 2015, 02:05 PM
I did some playing around and got the DIAG_GET to give the error. Adding DIAG_INFO.E4 as an input on DIAG_GET.EN triggered the DIAG_GET to give some feedback. However, DIAG_GET.DONE never goes to true, and the error values don't reset on the DIAG_GET function block when there is no error to display. I'm going to keep playing with it, but this is a good start. Let me know if you have any suggestions as to why the DIAG_GET.DONE bit never goes to true, or how to reset the values.

Highland Controls
April 7th, 2015, 02:10 PM
I can tell you that ABB doesn't follow the PLCopen standards for function block operation. Many of their EN inputs should really be labeled Execute. It needs to see a rising edge to trigger. Toggle the EN input, and the outputs should update.

April 7th, 2015, 02:12 PM
I started the program and went online without the error. Then I disconnected a TC wire to induce the error and this is how things are. The module and CPU are currently faulted, but now the xTestError1 isn't being set to true. Thoughts?

April 7th, 2015, 02:20 PM
Playing around with the rising edge like you suggested and it worked. It reset the values after the error was cleared. Probably going to trigger the DIAG_GET.EN when the DIAG_INFO.E4 bit goes true or when the DIAG_RESET is executed. I appreciate your help!

Highland Controls
April 7th, 2015, 02:24 PM
For those function blocks, I typically put a NC contact on the EN input. Tie the NC contact to the DONE output of the same function block. That way the input automatically toggles.

April 7th, 2015, 02:29 PM
I'll test that out. It's odd that the done bit never goes to true for the DIAG_GET function block.

EDIT: The done bit evidently does go true, I guess it just doesn't latch like I'm used to in Rockwell land.

Highland Controls
April 7th, 2015, 02:34 PM
Yes, it would be great if the inputs and outputs behaved like they should.