Let's animate the already created (but empty) Trends panel with a graph of the variable's changes over time. However, before looking at the trends, they need to be configured and somehow set the values so that they accumulate in the database. It is necessary that the system has a variable that changes its value. It is necessary to hang the corresponding config on this variable so that the values are added to the archive. For the Flap data point type, we have a DPE called Flow and type int. This DPE will be used to get acquainted with trends. To simulate the behavior of the system, we already have a created control script Model. I suggest using it to simulate the flow rate. Let's open the Model script:
, « » ( C) main(). main() , DPE - (callback-), main , callback-.
main :
main()
{
dpConnect("OnOpen_CB1", "System1:Flap1.Commands.Open");
dpConnect("OnOpen_CB2", "System1:Flap2.Commands.Open");
dpConnect("OnOpen_CB3", "System1:Flap3.Commands.Open");
for (;;) {
dpSet("System1:Flap1.Inputs.Flow", rand());
dpSet("System1:Flap2.Inputs.Flow", rand());
delay(1);
}
}
DPE callback ( for(;;)), 1 2, 1 delay. main , CTRL-.
(, — dpSet, . , ).
CTRL- ( ) , , para.
. Trends. Trend gedi.
— . — Value over value «» . — , X — , Y — . , — , . , .
Append — . Curve ()
… #1_1, :
… ( , ) #1_2. Close. Trends
Trends Main, TRENDS. , - , , … .
, , ( ), . , «». , X , , . , , . , . «- , », «1:1» , .
«» ruler:
Shift , .. « ».
, . . . .. . , .
, , . , , .. . para. Flap1.Input.Flow _archive.
Archive Settings. _archive, .
:
, :
, (, ) . WinCC OA Oracle. 3.17 InfluxDB, , NextGen . . ( ) . , . « » -, . , , «». ( , «» ) , - . , , — . , . NextGen InfluxDB, , , , «».
, , . ValueArchive_0000.
Active, Apply.
. Main, , , :
, — . , . , , . «Active» «Apply».
, ( , ) - . - SQL-. WinCC OA SQL Query. ( gedi Module) System Management.
Reports:
SQL-Query. ALL Value type ( , ).
SELECT DPE, . , , « — », . — originalvalue originalstime. Configuration Elements of the SELECT Statements «Append» «Insert», . . , .
From , .
, Flap* Elements of the FROM statement.
Data:
Create query, Start query, .
. - SQL-. Main EXPORT.
Click . SQL-, SQL-query :
dpQuery. dpQuery dpGet , , SQL-, , dpGet . — SQL. , WinCC OA — dyndynanytype. . , , — . , .
main(mapping event)
{
dyn_dyn_anytype Tab;
dpQuery("SELECT ALL '_original.._value', '_original.._stime' FROM 'Flap*'", Tab);
}
Tab, - . Log Viewer DebugN. , . . — DebugN , «» . , , . — , . , — , , , . , DebugN , , , . , .
Ultimately, the EXPORT button handler looks like this:
main(mapping event)
{
dyn_dyn_anytype Tab;
dpQuery("SELECT ALL '_original.._value', '_original.._stime' FROM 'Flap*'", Tab);
DebugN("SQL", Tab);
}
Having saved the script, start the Main window again for execution. Let's find the Log Viewer window (it always opens automatically when the system starts), clear the log output with the "cross" button for our convenience:
Press the EXPORT button at runtime and look at the output in the log:
The unloading turned out to be very large, and far from everything is shown, which LogViewer honestly reports:
It's a shame, but logical. Outputting a few megabytes of text to a journal is not a good choice. In practice, the Tab variable can be parsed and played with your math. You can display information in a table and so on.