Enabling/Disabling Historic logging using ST

[Anonymous user]

Hi 

I am trying to control the Historic Logging on tags in CS. For most points I can simply use the OPC point

..Point.HistoricLogging

However for points like a Trend point I can't do this as its an 'Aggregate' . I have managed to do it to using a script on a mimic but want to call this from an ST program.

'Enable Trend tags Historic logging
Sub EnableTrendTagHistoricLogging()

Set ObjPoint = Server.FindObject(Server.ThisObject.Parent.FullName + ".RV_FT01_RawPulses")
ObjPoint.Interface.Historic=True

End Sub

'Disable Trend tags Historic logging
Sub DisableTrendTagHistoricLogging()

Set ObjPoint = Server.FindObject(Server.ThisObject.Parent.FullName + ".RV_FT01_RawPulses")
ObjPoint.Interface.Historic=False

End Sub

How can I do this?

[AdamWoodland]

You should be able to use Point.Historic.$Enable or Enable$ (I can't remember off the top of my head) as type bool.

The problem you'll come across is referencing the properties on the aggregate as they don't existing until the aggregate is enabled. So you can't reference them in the logic if the aggregate is currently disabled and you want to enable it as the logic will bomb out with an error. The other way around the logic will run once to allow you to disable the aggregate but subsequent runs the logic will fail.

If you do want to edit the settings on the aggregate beyond enabling it, you'll have to do something tricky and split the function to different logic programs and only call the second logic program once you enable the aggregate. Still becomes a little tricky when the default state is disabled historic as the logic can't be compiled.

Have a play and see what works best for your setup.

[BevanWeiss]

One way to do the Aggregate property update in ST Logic is to use an SQL execution with an UPDATE clause.

It's definitely not the nicest... but it's "robust" against the Aggregate not existing, since then the UPDATE still executes, but there's no WHERE match, so it just doesn't do the UPDATE.

Obviously the performance of this is not as good as having a specific reference to the Aggregate property precisely, but it should only ever be a very occasional thing anyway.

[Anonymous user]

We use a PLC pump control systems and RTUs which can be configured remotely via an HMI, CS gets the updated config of what is used onsite so Its not something that I'll be doing often, pretty much initial setup and odd change.. There's quite a few of them in the field though!

I'll have a look at the SQL, but I assume I will need to find the tables from the schema and join them etc?

[Anonymous user]

Hi Adam

I tried the $enable, which compiled but nothing seemed to happen the enable$ didn't compile... I am wondering if the SQL method would be better as they won't change often?

[BevanWeiss]

It's a little tricky still...

So with your Logic you can use something like

PROGRAM HistoricEnableProgram

  VAR_INPUT

    Enable : BOOL;

  END_VAR

  VAR

    HistoricEnabled AT %M(PointPath.Historic.$Enabled) : BOOL;

  VAR_END

  HIstoricEnabled := Enable;

END_PROGRAM

That will let you Enable / Disable the Historic Aggregate.

This is then where the ST SQL comes in... if you want to change things on the Historic Aggregate, you can't just reference the OPC property, since when the Aggregate is disabled, the OPC properties simply do not exist, and hence the logic won't compile.

So the options are:

1. Use another ST Logic Routine which takes the FullName as an indirect to allow you to manipulate values...

2. Use ST SQL queries

The first is probably the better option.  It's more understandable, and less costly in performance.  And... even better.  The help has some help on this.

Core Reference > Coding > Logic > Checking that Aggregates are Enabled in Logic Programs

You'll need to combine what I've put above with your learnings from the help document, and then you should have the whole solution.