A Step by Step Guide to Building a Control Parameter in OnPing

A customer has several flares that they are trying to gauge gas usage on. However, when the wells were first put in no meter was added for the flares. This means they would have to spend thousands of dollars to get this data directly. Instead they have asked us to produce virtual calculations for each meter.
The calculation looks like.

FlareGas = (𝐺𝑎𝑠𝑆𝑜𝑢𝑟𝑐𝑒𝑠 − 𝐺𝑎𝑠𝐶𝑜𝑛𝑠𝑢𝑚𝑒𝑟𝑠) + 𝐵𝑢𝑦𝑏𝑎𝑐𝑘𝑀𝑒𝑡𝑒𝑟𝑠

Selecting whether or not to use a control parameter or virtual parameter can be difficult.
I have made a flowchart to go over when you HAVE to use one over the other.

There are other reasons to prefer one or the other but that should be a good starting point.

For our problem we are going to pick control parameters. We are doing this because we want caching and do not want recalculation.

What is recalculation? Recalculation is a property that virtual parameters have, every time you look at the result of a virtual parameter it recalculates its outputs. This means you can look at it two times and get two results. Why don’t we want this? Because the number of devices at a flare meter can change over time, we want the cached/persisted value (see the flow chart) to be what is used.

The best way I know to find the lumberjack is to search for the location.
For instance, search for Best Bread Bakery is:location in onping.

That gives us an IP: 10.7.9.153 now you can go to the control parameter screen and plug that IP in.

If we don’t have a target for the parameter created already we use “Calculated Parameters” as the name of a single well manual target.

Single well manuals are a great way to create targets for control parameters.
Remember a CPID is not like a PID or a VPID, they can’t be directly graphed or displayed.
They are completely defined by their output PID.

We will make an output pid named “Virtual Flare Flowrate” and use it as a flowrate.

We will want this parameter to run on change. So we tie it to an “On Change” event, this allows it to run whenever its inputs update. We could also schedule an update, but this doesn’t make sense for a flowrate.

These flare meters are different for every site that runs them. This one has a Separator and Sales Meter.
The Separator is a Gas Producer and the Sales is a Gas Consumer. There is no Buyback or other meters.
So to calculate the Flare Gas Flow Rate: FlareGasRate = SeparatorGasRate - SalesGasRate is the formula.
Not too bad.

We will select each of the inputs individually. Note: they have to be on the same lumberjack or we need to use lumberjack remote to relay one to the other or use virtual parameters instead of control parameters.

The script could be written several ways. The control parameter interface will help us think about what we want to happen.

So the first question is, what approximation method should we use to gather inputs.

An approximation method determines what value to grab when there is no value to pick.

This is very important in networked data like ours. Lets spend a bit of time looking at the methods of approximation readily available in OnPing.

I like to start with the thing done and then break down. Here is the final product.

/*
Virtual Flare is the missing gas from the rest of the meters
*/


separator := input(1,now);
salesMeter := input(2,now);


if( isUnit(separator) ||
    isUnit(salesMeter) ) then

   output := ();
else

rslt := separator - salesMeter;

if (rslt < 0.0 ) then
   output := 0.0;
   else
    output := rslt;
end_if;

end_if;

That is it! This small script responds to events coming in from onping and resolves them correctly.
Lets break down each part.

We could have added a truncate code to the control parameter like …

output := rslt `2;

But because unlike virtual parameters, control parameters can be masked! I usually leave this stuff to be done with a mask that way it can be changed like everything else.

Writing programs is understanding the difference between what you expect to happen and what could happen. Then trying to defend against what could happen in a way that it doesn’t break everything you are trying to do.

You will read a program many more times than you write it so try and think about what makes this easier.
That usually means well named variables and descriptive comments. But often means much more than that.

I hope this post starts to show you all that can be done with control parameters.

Thank you!