Emerson Exchange 365

Jeroen;

Andre has done an excellent job of describing the Intelligent Diagnostic Data that became available in DeltaV 11.3, however I'd like to add a few items that may be helpful.

The information that is available on the General Properties Context Menu is part of the Standard Diagnostics which per Andre's response is the first 6 bytes of information returned for the device as Extended Diagnostic Data. Extended Diagnostic Data can have as much as another 238 bytes of optional diagnostic data for a total maximum of 244 bytes. This mandatory data or Standard Diagnostic Data should be available for all devices and maps as:

Byte 1:

Bit 0: Station not existent

Bit 1: Station not Ready

Bit 2: Configuration Fault

Bit 3: Slave has Extended Diagnostic Data

Bit 4: Slave does not Support the last requested Parameter Function

Bit 5: Invalid Response

Bit 6: Slave did not Accept the last Parameter Data sent

Bit 7: The Slave is controlled by another Master

Byte 2:

Bit 0: Slave Requires Parameterization

Bit 1: Master is Requesting Diagnostics

Bit 2: Bit is always "1"

Bit 3: Watchdog is On

Bit 4: Slave Freeze Mode is On

Bit 5: Slave Sync Mode is On

Bit 6: Reserved

Bit 7: Slave is not enabled

Byte 3:

Bit 7: Diagnostic Overflow

The rest of the bits for Byte 3 are reserved.

Byte 4:

Master Station Address with address 255 reserved for a slave device with no Master

Byte 5:

The Most signification byte of the Profibus ID of the slave

Byte 6:

The least signification byte of the Profibus ID of the slave

These Bytes are always available from the device using the method described by Andre making sure that you expose these directly from a reference parameter or a Calc block. A possible Calc Block Expression to read these might be:

I F ( ' ^ / D E V D I A G D A T A . C S T '   =   0   A N D   ' ^ / D E V D I A G D A T A . S T '   =   1 2 8 )   T H E N

( *   G E T   T H E   V A L U E S   O F   E A C H   B Y T E   I F   T H E   C O M M U N I C A T I O N   S T A T U S   I S   N O R M A L

A N D   S T A T U S   I S   G O O D   * )

  ' O U T 1 . C V '     : =     ' ^ / D E V D I A G D A T A [ 0 ] . C V ' ;

  ' O U T 2 . C V '     : =     ' ^ / D E V D I A G D A T A [ 1 ] . C V ' ;

  ' O U T 3 . C V '     : =     ' ^ / D E V D I A G D A T A [ 2 ] . C V ' ;

  ' O U T 4 . C V '     : =     ' ^ / D E V D I A G D A T A [ 3 ] . C V ' ;

  ' O U T 5 . C V '     : =     ' ^ / D E V D I A G D A T A [ 4 ] . C V ' ;

' O U T 6 . C V '     : =     ' ^ / D E V D I A G D A T A [ 5 ] . C V ' ;

' O U T 7 . C V '     : =     ' ^ / D E V D I A G D A T A [ 6 ] . C V ' ;

  ' O U T 8 . C V '     : =     ' ^ / D E V D I A G D A T A [ 7 ] . C V ' ;

One must use a parameter, say in this case, "DEVDIAGDATA", which is an external reference to /&MY_DP_DEVICE/DIAGMSG. This is necessary since diagnostic data is not directly allowed to be accessed. Also as a reminder, this data is being returned as a new data type for DeltaV, BYTE ARRAY. It functions somewhat like a FLOATING POINT ARRAY, but as the name states the values are handled as bytes. Another difference is this data is being returned by the controller as a dynamic byte array since the return of the data is dependant on the diagnostic returned and the way that the device was designed. This can differ somewhat between devices even if they are the same type of device, I/O, VFD, Flow, Motor Control, etc, although there is some structure to it. If you're interested in a further understanding of this optional data and the structure, I'd suggest checking out the Profibus Specifications.

One point on your question was the pulling of this data through OPC Mirror. Since this is diagnostic data, it will not be directly available to you, however you can pull this through using a module. The positive side of that is that you can then organize the actual bits that you wish to use for each type of slave device on the Profibus segments.

I hope this can assist with getting you started on the mapping and organizing of the bytes/bits once you get upgraded.