• Not Answered

How to transfer string data from PK750 Controller

We have a new DeltaV system with version 14.3 PK750 controllers. I am also using Beijer iX developer software to intregrate some Beijer x2 pro 10 HMI's to the system.

We want to display string, floating point, integer, and binary data on the HMI from the PK750 controllers using OPC UA. Using the Beijer developer tool, I can see the all types of tags in the controller such as floating point, integer, and binary data. However, I can see string data in the controller.

Is the PK750 controller restricted from transmitting string data over OPC UA or Ethernet to other systems such as HMI's or PLC's?

I have attached screenshots of the Beijer navigation tool and the DeltaV screens.

In the screenshots, you will see these parameters:

NAME                    TYPE                              VALUE

BATCHID               STRING                         "itworked"

TESTBATCHID     STRING                          "testbatchid"

TESTNUMBER      FLOATING POINT         3.1414

The screenshot "OPC_DATA_DEVELOPER_28DEC20" shows the Developer navigation tool before I added the TESTBATCHID and TESTNUMBER parameters, but it did show the TESTNUMBER parameter. I could display the TESTNUMBER value on the Beijer HMI as 3.1414.

21 Replies

  • In reply to AdrianOffield:

    PK controller do not support OPC DA directly - to get OPC DA (DCOM) data it needs a workstation. PK supports OPC UA Data Access "Embedded UA Server Profile" directly.
  • In reply to Lun.Raznik:

    Thanks for the confirmation which is for a standalone PK, but I was under the impression these can be integrated with regular S and M series controllers. How does that work exactly?

    I've not had chance to integrate a PK yet, but I had thought it was seamless, but from your explanation it isn't as straight forward.
  • In reply to AdrianOffield:

    The OPC UA Server in the PK Controller functions the same whether the PK is deployed as Standalone or integrated into a full DeltaV system. As mentioned earlier in this thread, there are some differences between the OPC UA Server in the PK Controller and the OPC UA Server in an Application Station (or the ProPlus); the PK Controller supports DA only while the OPC UA Server in an Application Station or ProPlus supports DA, HDA, and AE.
  • In reply to Bruce Greenwald:

    This may be semantics, but the way I see it, the PK controller and every other DeltaV controller, do not support OPC DA. OPC DA is supported on the DeltaV workstations, and in a DeltaV system, it is licensed on the Application Stations. The controllers communicate on the DeltaV network via the DeltaV communication protocol. As such there is no OPC DA traffic to DeltaV controllers. When we use OPC Watchit, we connect to an OPC DA server and have access to its 'tag space' via the OPC Browser, which in DeltaV, exposes data by Module Tag or Device Name. This OPC Server connects to the communication layer on that server to request data from the host nodes. From here on in, it is all DeltaV traffic, no OPC DA.

    The PK is different in that it offers three additional native communication ports: P01- for Modbus TCP Client/ EthernetIP, ModbusTCP Server and OPC UA server. These are in addition to the native communication layer. In Standalone, the native communication is used by the Engineering Station and DeltaV HMI station. When fully integrated, these become the Pro Plus and all other nodes in the system.

    The Modbus TCP and OPC UA servers retain the same functionality in both settings, as does the P01 Ethernet IO port.

    To answer Adrian's question, OPC UA and Modbus TCP servers are not used for integrating to DeltaV. The PK integrates via the native communication protocol of DeltaV. You simply commission the PK as you would any other controller. When the PK is configured as standalone you have two choices: Leave it stand alone and use OPC UA or Modbus TCP to integrate as you would a PLC. Or, integrate the configuration into the DeltaV system configuration, and commission/Download the PK as a native controller. Tools are provided to do this.

    If you used the OPC UA server to integrate a local HMI to a stand alone PK, you can keep this HMI even if you integrate the PK as a native DeltaV node later. If you used the DeltaV HMI on the PK Standalone, it must also be integrated as a native Workstation if you still require it. This is because the HMI has to be part of the Pro Plus database in order to communicate with the PK once natively integrated.

    Hope this helps.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks Andre, excellent answers as usual.

    It's clear to me now for integrating PK into DeltaV proper, with the availability of native protocol in addition to the supported protocols on P01 it will appear as regular DV node.

    I just have a couple of additional clarifications regarding :

    1. External references to parameters in PK controller, once integrated to DV proper, can this be done online, do you only need a download setup data or would you need a full download for existing nodes to resolve references?
    2. Will future releases of OPCMirror support OPC UA?
  • In reply to AdrianOffield:

    Adrian,  External references will work the same way as if you added a new controller to the system.  All existing nodes will be flagged as a new node will exist in the system and the Node table will need to be downloaded, which would be a "Changed setup" download.  The Workstations will also get the changed Module table as part of that download, and any other system changes such as new Named Sets or Alarm definitions, etc. that might have been created in the standalone configuration.  If the PK configuration followed the site database library, there would be minimal changes to be downloaded.  The Merge tool evaluates any "conflicts" so that they can be resolved prior to integration.

    For remote references, the location of the remote module involves the Directory Services running in the Pro Plus (or the next Workstation as determined by an election when the Pro Plus is unavailable).  Upon download, or when the remote reference becomes active, as in the case of a dynamic reference that defines $REF at some later time, the referenced module is determined to be external to the controller the from which the reference is being initiated.  If the module is not already communicating to this controller, i.e. it has a Proxy Client defined, the controller sends a request to identify the location of the required  module.  Once this is known, a device connection is made, if it does not exist, and then the Proxy client and Server are created, to which the requested parameter path is added and communications start.  This requires the node table and Module tables to be downloaded to the Pro Plus and is propagated via Auto Update service to all the Workstations.  

    AS for the controllers, a download of Setup Data reveals the following items are sent to controlles:

    The Node Table will flag a required download of Changed Setup data to all nodes so they know of the new controller.  Alarm Anunciation Tale and Enumeration Sets (Named sets) may or may not be flagged as changed.  The balance of Items I don't think would change for any other nodes.  Without the Node Table, downloaded to a controller, it would not be able to "locate" the new PK controller if a remote reference were added to a module assigned to the PK.  

    The Changed Setup data download can be done on line.

    2:  As for support of OPC UA in OPC Mirror, I don't know that I can speak to any product changes or enhancements that my or may not be made.  The question that has to asked is whether the current OPC DA solution requires a move to OPC UA for cyber security reasons, such as better management of Firewalled connections or use of Encryption.  For integration purposes to DeltaV with OPC UA, the preferred method would be to use the OPC UA Client, which bypasses the OPC DA Server altogether.  The client connects directly to the 3rd party OPC UA server and OPC Mirror is no longer required.  If the 3rd party application moves to support an OPC UA Client it would access OPC UA server data directly from DeltaV.  

    So I'm not sure that OPC Mirror needs to become an OPC UA compliant product.  There are multiple companies out there that offer OPC UA wrappers for both OPC DA clients and servers, allowing users to move to OPC UA.  I believe Emerson lists Integration Objects as an Alliance partner with these solutions.  

    Here's what I like about the OPC UA Client vs OPC DA Mirror.  With OPC DA, DeltaV cannot guarantee a client connection will be successful in adding all items because it is a first come, first served scenario.  the OPC DA license is consumed as tags are added and when limit is reached, all subsequent connections are denied.  You have to manage these connections externally.  And there is the whole issue with Ports on firewalls.  OPC Mirror does not alleviate any of this.  With OPC UA Client, connections are managed by the Client configuration and no external behavior can come in and break valid connections.  Also, the communication can be set up with Authentication certificates as well as encryption.  And finally, the OPC UA protocol plays nicely with firewalls.  And it is the IIoT defacto protocol for Digital Transformation.  

    I would be looking to move away from OPC Mirror and OPC DA servers, but I would not do so without some clear benefits or requirements that cannot be met with the existing solution. Adding encryption and Cyber security features to OPC Mirror would have costs.  It also doesn't seem to be the right solution given the architecture of OPC UA.  I don't know if other companies like Kepware or Integration Objects etc have any such OPC UA multi ported clients that would do what OPC Mirror does, or if Emerson is planning to support such a solution with UA,  I'm not so sure that it is needed.

    Andre Dicaire