Now that we finished the forward direction of our signals journey, time to follow our foot steps back from SCADA to the field, giving automatic and manual control commands to our process to alter it.

Previous:

“Journey to the Center of the Plant – from FIELD to SCADA and Back – Part I”

“Journey to the Center of the Plant – from FIELD to SCADA and Back – Part II – Network and OPC”

“Journey to the Center of the Plant – from FIELD to SCADA and Back – Part III – SCADA Software”

SCADA Systems Information Flow from Field Instruments to Control Room and Back – Part IV

Back to our process, we had one sensor and one actuator, sensor was a temperature transmitter that is measuring the tank’s temperature, and the actuator was a solenoid valve that when opened shall allow steam to pass through a heating coil embedded into the tank to heat up its contents.

In order to clearly understand the journey back, allow me to start it from the middle, at the PLC control logic that controls the solenoid valve, not from the SCADA.

Sounds strange I know, but don’t worry, later you will thank me for that.

PLC Control Logic

As per the process guys, they told you that they wish to control the temperature so it would be fixed at 75 ºC, and they allow for a variation of the process temperature between 70 and 80 ºC.

So you decided to have the following control philosophy:

  • When tank temperature drops below 72 ºC, turn ON the solenoid valve.
  • When tank temperature rises above 78 ºC, turn OFF the solenoid valve.

Once you drafted that down, you translated this into that simple, single Rung, ladder diagram below.

Ladder1

You run a simulation and it works just fine. Logic seems to be air-tight.

But then you think: How on earth my SCADA is going to get involved with, and to interrupt, this air-tight logic? I will tell you how.

Prepare the PLC Program to Receive SCADA Commands

First, you need to define what the operator needs to do with the valve. Write down a list:

  1. Operator needs to see the valve status.
  2. Operator needs to be able to change the control mode of the valve, Automatic with the logic, or Manual from the SCADA screen.
  3. Operator needs to be able to issue a manual command to open or close the valve from the SCADA screen.

Second, allocate a memory location in the PLC memory for each function, so when the SCADA wants to do these functions, it only has to write (or read) information to (or from) these locations. In our case we will allocate three memory bits (or internal relays, or markers), the name highly depends on the PLC vendor’s manual but they are all the same. We chose bits and not words as its all discrete information and commands.

  • For valve status, allocate M10
  • For AUTO selection, allocate M11
  • For Manual Command, allocate M12

Let’s modify our PLC program.

Ladder2Now our PLC program is ready to receive SCADA commands, time to add these new variables to our OPC server.

Note: In actual applications, we mostly rely on an external feedback signal to indicate the actual valve status on the field, it’s not correct to just use the PLC output, as we might have a failure on the actuator and never knew it. This is only done here to simplify the subject.

Modify the OPC Server

Just as we did in Part II, open your ABC OPC server and modify the configuration file by adding three more OPC items to the same OPC Group “TANK”, your configuration should look like the figure below.

OPC_Full

You can actually use the OPC server software with the PLC itself to test if writing 0s or 1s in these memory bits is doing the needed function or not, once you are sure it’s working, you need to modify your XYZ SCADA software.

For more information about how OPC works, review Part II – Network and OPC.

Update the SCADA

Back to our SCADA software, first thing to do is to create three new tags in the Tags Database for your three new variables (Valve_Status, Valve_Auto and Valve­_Manual_Command).

Next, go to your graphics editor, open your tank screen, and add a valve symbol, set the data source property to your Valve_Status Tag and click Save. Now you have a valve symbol that is changing it’s according to the actual solenoid valve status.

Add a couple of toggle switch symbols to your screen, one for the mode selection and one for the manual command, link them to your tags, and you have a fully functioning system.

SCADA_Screen_Full

Now run your SCADA, test everything life, works like a charm.

What? The valve is not operating? No? Why? Let me have a look…… oh, here you go, you forgot to connect your Solenoid valve to the PLC output, wait let me see …… oops!

Your solenoid valve nameplate says it operates @ 220 VAC, and your PLC output module is a transistor type that can only handle up to 24 VDC, you should have planned that from the beginning.

But don’t worry. If there is a will, there is a way. This time the way is called the Interface Relay!

The Interface Relay

Sometimes called the interposing relay, but I like the first name better.

Whichever the name, we have to install one of those in the PLC panel. It shall provide isolation between the PLC output and the solenoid valve, allowing the PLC to operate the relay coil with 24 VDC, and the relay contact will connect the 220 VAC supply to the solenoid valve.

Interface_Relay

Interface relays, like normal relays consists of two parts:

  • The relay base (or socket), greed part in the photo above, it provides an easy way to plug/unplug the relay, it provides also the connection of the coil and contacts of the relay.
  • The relay, the white part in the photo above, consists of the coil and the contacts, and it provides the switching function needed.

The interface relay socket provides additional protection to the PLC output point, a separate post will come about the wiring of PLC I/O points will cover that issue in details.

With that done, you can now control the solenoid using the PLC output Q1 safely. Our job here is finished, your SCADA application is fully functional.

Conclusion

Through the four parts of this topic, we went through all the various steps and transformations of signals, data and information from the field to SCADA and then back to field again. We tried to cover the subject in enough details, without sinking in the details.

Follow The Control Blog to receive more posts around similar subjects.