Writing Value to Third party PLC


I want to write value to Third party PLC only once. But when I configured the in serial module, it is continuously writing to the PLC address. How to make such logic. We have SCADA for third part PLC, which is only writing once when we key in from HMI.

  • Hi

    Check the data type ( INT , BOOL , WORD or BOOLEAN ) . Check online values on deltav , check for data links that u have configured.


  • Nilesh, The serial card uses Modbus RTU/ASCII protocol.  Are you using the actual Serial Card or a VIM, which emulates a Serial Card.  The VIM offers additional options, but both support "Complete Block" or "Single Value" writes.

    By configuring an Output Dataset with Single Value, the Serial card will only write the changed values.  You can select Output Read Back to update the controller with the current values in the PLC.  If a value is changed by the PLC, then DeltaV will read it.  During Dataset scanning, DeltaV will write changed values and read the entire dataset.  If there are no changes, then only read is performed. 

    This allows you to write a value to the PLC and have the PLC reset it.  Or you can mix and match Input and Output values in the same dataset.  If there are outputs, it will license using an Output DST, but you would not need a second AI DST for reads. 

    As of v13, DeltaV offers the EIOC for integration of 3rd party subsystems.  It supports both Modbus TCP and EthernetIP.  The VIM provides support for Modbus TCP, Ethernet IP and Profinet.  The VIM Emulates either a Serial Card (Modbus Datasets for Modbus TCP and EthernetIP), DeviceNet card (EthernetIP) and Profibus card (Profinet).  The EIOC is expected to support Profinet natively in v15.

    When integrating devices, such as Motor relays, VFD's, etc. the devices have local and remote operating modes, and a single master (generally).  As such, when the device is in remote control, the use of Complete Block Writes is appropriate.  When in local control, the device ignores data from the master.  Typically, the devices use and intermediate set of target parameters for the master to write to, and data is transferred to the working parameters when in Remote. 

    With a PLC, things are different.  As described by Nilesh, the integration is more of a SCADA application, where HMI commands are sent intermittently and the PLC hosts all the data.  The HMI may be writing to the SP of a PID loop that is in Auto.  There may be other interfaces that also allow the SP to be changed.  It is important that the SCADA host updates the data to the HMI and only writes to these parameters on change by the HMI/Operator. 

    In some cases, the PLC logic may offer dedicated Parameters for the SCADA system in order to allow supervisory control of certain control.  The PLC logic would in such cases have an operational mode that uses the Supervisory signal, which is dedicated to the host system.  This is similar to a VFD in Remote control.  The PLC reads the value from the host and moves it to the control signal.  This is very much akin to CAS mode or RCAS mode in DeltaV, where the higher control function writes to this dedicated parameter and the Function block uses the value only when in the appropriate mode.

    The EIOC, or VIM, or Serial Card act as an HMI server when connecting in a SCADA fashion, and to that end, must allow for HMI writes to occur, and to update.   The simplest way to accomplish this is to build a DeltaV Module that references the Dataset registers, or the Logical Device Signals (EIOC Syntax) directly with external reference parameters.  Since control and logic functions are being executed in the PLC, these modules do not require any control logic.  You could stop here, and uses these values in HMI displays, or build Dynamos the present data to operators and provide access to certain parameters.  However, since we typically want a consistent look and feel to the HMI for a PID or a Motor, we typically construct control modules based on Module Classes designed for native DeltaV IO and control.  These modules have control function blocks like PID or EDC blocks, which provide consistent parameter references in the displays and makes the display creation easier by using the same Dynamos, Faceplate and Details displays.

    This approach makes the DeltaV Displays for the Integrated PLC look and feel like native DeltaV controls by adding a layer of abstraction between the IO references and the HMI.  It is no longer a SCADA approach.  If we connect these DetlaV function blocks directly to the PLC references, we create new problems. (it does not work).  So we add more code to the control modules to conditionally write to outputs and handle a myriad of initialization problems so that when the DeltaV interface is downloaded, restarts or regains communications, the DeltaV modules do not overwrite/disrupt the PLC settings.

    For motors, PLC logic is often written to provide DCS Start/Stop bits.  These can be mapped directly to the DCS.  The challenge is how to handle a loss of communications.  A single Run/Stop bit is easy, but on a loss of communication, if the DeltaV Logic is writing a Run, but the PLC stops the motor, we don't want the motor to restart on its own.  Again, we add logic to evaluate the communication link and align the motor with the field.  Except, we can't do that until communication is restored.  If we reset the bit to Stop, but the motor is still running, we stop needlessly.  If we wait too long, and the motor is stopped, we risk restarting it.  However, if we use a momentary start and a latched Stop bit, the DCS start is always passive, except when explicitly activated, allowing a loss of communication to not disrupt the PLC state when comms are restored.  The DCS bits can remain unchanged and not additional synchronization logic is needed.  Alternatively, the PLC can disable DCS commands on a loss of comms and a confirmed reset bit restores DCS control when communication is restored.  Both of these require that the PLC have explicit code to handle DCS signals.

    In the current offerings, the integration of PLC's via Serial Cards, VIMS and EIOC's assumes data is mapped to intermediate arrays or contiguous registers that are read/written to as Datasets or Logical devices. The PLC must then have logic to move data back and forth between these mapped arrays and the PLC logic parameters.  This mapping logic can be designed to appropriate condition data or to ignore DCS commands when appropriate.

    For SCADA applications, the DeltaV Modules should consider simply providing access to PLC registers by using appropriately designed objects that read and write directly to external references.  Data is then transferred to the PLC by single value writes, and the PLC updates these signals so that the HMI always shows what is in the PLC.  You also build composite blocks to emulate the structure of the native DeltaV control blocks, creating consistent parameter paths to reuse existing dynamos and such, but still provide direct external references to the PLC signals. 

    In v14, the EIOC introduces Control Tag Integration for Rockwell Logix PLC's.  This allows us to build custom Control Tags that match the UDT tag parameters and to read and write without creating intermediate Mappings and the associated logic to move data.  You would still want to use "SCADA" modules to pass HMI writes by exception. 

    From a DeltaV  perspective, you will want to use a Single Value write so that PLC parameters are only updated when DeltaV HMI issues a parameter change.  Block Writes can be used for dedicated DCS registers, such as DCS START/STOP or Supervisory Registers.

    Andre Dicaire