• Not Answered

DeltaV remote IO parameter Paths

Hi Guys,

Does anyone know what would be the parameter paths for browsing the Comm parameter of the DeltaV Zone 2 remote IO nodes & Exist parameter for its cards.

If we look at the the below Snap shot, I was able to browse the Exist parameter of a card for the Remote IO node just like the card of controller. But it gave  ***(parameter not configured) error. See below left side. 

For the Comm parameter of the Remote IO node I manually entered the path(Not Browsed) just like the one which is available for the controller. But it does not resolve & gives error ***.

I would like to know what is the parameter paths to browse the Comm parameter for PRI & SEC links for a DeltaV Remote IO node & Exist parameter for the cards. I need this to show in graphics just like we have graphics for controllers & its cards.

PS:  The browsed overall integrity parameter path for cards of remote IO works just like cards of controllers.

Manzoor

9 Replies

  • Have you tried Right clicking the parameter in Diagnostics and selecting 'Properties'?  This opens a dialog with the appropriate path displayed.  Next, try that path in  Watchit.exe.  

    I don't have Remote I/O to test this with, but give it a shot if you haven't already.

  • In reply to Youssef.El-Bahtimy:

    Youssef

    I checked the path in watchit as well as in graphics. Attached is the snap for watchit. In graphics I got &&&&.

    Does DeltaV Support browsing to its Remote IO node parameters just as for the controllers & DeltaV cards.  I hope it does.

    Regards

    Manzoor

  • In reply to Manzoor:

    Can anyone give some input on this.
  • In reply to Manzoor:

    After some additional research, I've learned it is unfortunately not possible to reference these parameters, by design.  You may submit your request for an enhancement to this design at the User Driven Enhancement Program

    http://www.userideas-emerson.com/

    There are others requesting this feature, so the more voices the better.

  • In reply to Youssef.El-Bahtimy:

    I have submitted my request for referencing these parameters in DeltaV.

    Thanks for your time Youssef.

    Manzoor
  • I recently installed some Zone 2 Remote I/O and have the exact same issue described here where I can not show the communication parameters on graphic which monitors all the nodes. Was this resolved and were you able to figure a way to display the parameters on a graphic?
  • In reply to David Stevenson:

    As stated above, this is by design.

    Note that some of the information can be linked from the Assigned I/O (assignment of the card to the controller)
  • In reply to Lun.Raznik:

    Thanks for the reply, I was hoping that maybe after 7 years and/or version updates this might have been corrected. Seems silly to have the parameters viewable in diagnostics for the node but not accessible via Operate. Is it possible to access them in Control Studio? You mentioned linking to assigned I/O for each card. I suppose I could look at each card via control studio and do the logic to presume the comms are good or bad for the node. Then I could display that for my operators and technicians. Is the path what is shown above, where just have to figure out the meaning of the 10 digit number?
  • In reply to David Stevenson:

    Some parameters are available at the workstation but not in the controller (module assigned to App station shows CIOC Temperature, but if assigned to controller, value is undefined). Some parameters are browsable while others are no. Some are simply not accessible. Hard to know which are which.

    Some parameters use the node ID, which is what 3413180496 appears to be. In this case, that would correspond to device 50, or address 10.4.0.204? Something you can check. The node ID number shows up in remote IO references via the controller, as opposed to a direct path using the IO Node name, may not be available.

    As Manzoor indicated, the properties tab shows the path as seen from Diagnostic Explorer. This will typically work from the Workstation in Watchit and Operate, but may not work in a module assigned to the controller.

    The browsable diagnostic level parameters in control Studio should work as well, but additional parameters not shown in the browse list will flag a warning on download, but can be set in $REF of dynamic reference parameter via expression to avoid the generate error.

    It is unfortunate that there is this lack of consistency in how diagnostic parameters are exposed and that there has been no work done to harmonize this. I don't see the UDEP path bearing fruit as there are always more important projects this group will support. But it seems to be the only avenue available to the users of DeltaV.

    There is always a debate as to why you need to spend all this effort to contextualize this diagnostic data in an Operator Graphic when this data is already reported and presented out of the Box with DeltaV Hardware Alerts, the Condition Summary and Diagnostic Explorer. All the conditions are mapped to the Hardware Alerts that appear in a dedicated Hardware alert summary. From there, the node faceplate can take you to the Condition Summary where each active condition is shown, and can be suppressed to clear the Alert if the condition will persist for and cannot be readily resolved. the diagnostics are also available from the faceplate and opened in context of this node, showing all conditions and statuses. All this with zero configuration.

    But many customers want to have a custom network view of the health of their system, with data visible for all nodes and more detail one click away. They want to create what they consider a better visualization of the diagnostic state of the system. To that end, they need access to the data in the HMI.

    Personally, I've grown to like the Condition Summary and Hardware Alerts to allow the system to proactively tell me when abnormal conditions occur and I let the Alarm Banner drive the Hardware alerts summary with updates. But I also think these diagnostic parameters should all be browsable and report consistently to control modules no matter where they are assigned, and to Workstations for users to make use of.

    I would not say that the current disparate behavior is by design. It seems to be more like we arrived at this by a lack of design. Just my opinion.

    Andre Dicaire