Emerson Exchange 365

• Not Answered

usage of Diagnostic status inside CND block

Hello,

I want to use inside expresion of a CND block, the diagnostic status of a controller / cioc for charms

If i read the status of controller to see if the OVINTEG is different then GOOD, it is working, but if i try the same thing for the cioc (the holder of charms) the expression is no longer calculated.

The cioc's are all stetted up as remote io  for the same controller, and the same were the CND block is assigned.

Only thing what works is to read the status of charms one by one from "remote IO"  of designated controller, but i want to use a general status (OVINTEG) and not like this.

What is wrong?

stamate_mircea

• 3 Apr 2017 1:22 PM
• Cancel

5 Replies

• kmarks

  

  • 3 Apr 2017 3:00 PM

  Hello statmate_mircea,
  
  These parameters are not reported from the CIOC to the controller, so the module assigned to the controller is not able to read OINTEG of the CIOC. Per Books Online:
  
  Note
  To ensure that CIOCs provide the highest possible I/O performance, external and dynamic references to diagnostic parameters of CIOCs are not reported in modules downloaded to controllers and do not resolve at run time. If you need to use these types of parameter references in your control strategy download the modules to a workstation's virtual controller.

  • Cancel
• stamate_mircea

  

  • 3 Apr 2017 4:18 PM

  In reply to kmarks:

  Thank you for your answer.
  Let's presume i do not have access or i do not have permission to use a virtual controller.
  What is the alternative?
  What can i do except to read the Ointeg of each charm from the remote IO configuration of the controller?

  • Cancel
• kmarks

  

  • 3 Apr 2017 5:39 PM

  In reply to stamate_mircea:

  The CIOC/OINTEG parameter could be externally referenced within a module that is assigned to a workstation. This external reference parameter could then be read by the controller containing the CND block.

  • Cancel
• Andre Dicaire

  

  • 3 Apr 2017 9:16 PM

  Could you explain why you want to monitor the overall integrity of the CIOC in a CND block in the controller? are you creating an alarm? Hardware integrity is reported via Hardware Alerts, which also provides the Condition Viewer that shows all active alerts from a device. This is tightly coupled with DeltaV Diagnostic Explorer, which automatically builds the view of the hardware and allows you to navigate to any fault quickly, without having to build and maintain a custom configuration. Understand that a module built alarm will be grouped with process alarms and are not available to Maintenance Stations.
  
  I would advise against building a home grown module based diagnostic solution. If you do feel the need to do this, build the module and assign it to the Pro Plus or App Station rather than bog down a controller for this purpose. Also, be aware that you should run such a module at a slower rate, no faster than 5 seconds.
  
  Note that you can also build a diagnostic Dynamo for your Operator stations and reference the desired information from the CIOC and Controllers directly. If you let the Hardware Alerts do their work, a Diagnostic display can be set as the Default display for easy navigation, with a link to the default Node Faceplate, that brings the Condition Summary link as well as contextual button to launch Diagnostics for the specified device.
  
  You indicated you can read the individual CHARM's via "RemoteIO". This Path would look like "CTRL_NAME/REMIO/1234567890/CHM1-01/OINTEG", where the integer is the NODE ID of the CIOC, as viewed from Diagnostics Parameter properties dialog. The CIOC OINTEG is also available with the same path structure "CTRL_NAME/REMIO/1234567890/OINTEG". From what I can tell, this will only report the aggregate integrity of the assigned CHARMS. That is, if all the assigned CHARMS are GOOD, this OINTEG will be GOOD, even if the CIOC itself has an integrity fault, such as a BAD IO card or IOP. So it appears the Controller/REMIO path only shows you CHARM level integrity for the assigned CHARMS, and does not show you diagnostics for the health of the CIOC itself, such as a BAD standby card, missing terminator or failed IOP.
  
  Every DeltaV System has at least one "virtual" controller, located on the Professional Plus station, and every Application station has one. There is no licensing required to use the virtual controller. Prior to v12, there are DST's associated with certain function blocks, such as CALC, ALM and PID blocks. If the module does not contain these, there is no DST license associated with the module. In v12, these DST licenses were eliminated, so there is no reason to not have a virtual controller for running a module to reference these nodes.

  Andre Dicaire

  • Cancel
• stamate_mircea

  

  • 4 Apr 2017 7:31 AM

  In reply to Andre Dicaire:

  I need the status of the cioc because i have a digital output connected to some lamps on the door of the cabinets.(one red and one green linked to the same DO)
  Linking this to the status of the cioc OINTEG it seems to be the best idea .
  Other thing could be linking the hard wire alarms (if any alarms are on, my red lamp from the door of the cabinet will glow).
  The problem is I have 4 cabinets, one is with the controllers and the other three are with the ciocs.
  
  Actualy it works CTRL_NAME/REMIO/name_of_cioc/CHM1-01/OINTEG, tried with the integer from the diagnostics but it doesn't work like this.
  And yes i could read only the present and used charms, the channels that are not used i couldn't read.
  
  Thank you.

  • Cancel