EnglishУкраїнськаmRussian
Login/New
Topic with no new replies

[BugFixed] (DAQ Templates) Oscada writes values at Exiting.


Author Message
Written on: 18. 08. 2009 [20:28]
Unaie
Unai Ezta
Topic creator
registered since: 30.06.2009
Posts: 42
Severity: High
Affects: DAQ Templates
Versions: SVN

Description:

If in DAQ template you define registers type: OUTPUT LINK,
and LINK is set to PLC ModBus, when Oscada application is exiting (splash image before exit) it writes unknown values to PLC.

For example:

In DAQ Templates
----------------
Id Name Type Mode Attribute Access Value
R R Integer Output Full Access Link

Program: EMPTY
------------------------
In DAQ Logic Level

Parameter: ANY
Template: Previous
Parameters: R:MODBUS.ANY.ANY.T
-----------------

Then, When Oscada exits it writes to PLC, integer T is set to 1, erasing previous value in PLC.

It is tested also with REALs, it writes unknow values.
Test is done with ModBus, but perhaps this occurs with any other DAQ.

If necessary I could prepare a DB sample, but to test this it is needed a external PLC or Application, because it occurs when Oscada is exiting with a splash screen.

[This article was edited 1 times, at last 18.08.2009 at 20:28.]
Written on: 18. 08. 2009 [22:49]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
Unaie wrote:

If in DAQ template you define registers type: OUTPUT LINK,
and LINK is set to PLC ModBus, when Oscada application is exiting (splash image before exit) it writes unknown values to PLC

If this variable undefined then this correct. And by help OUTPUT LINK value allways will writed to ModBus.
Unaie wrote:

If necessary I could prepare a DB sample, but to test this it is needed a external PLC or Application, because it occurs when Oscada is exiting with a splash screen.

Send DB sample. External PLC do not need. For it can use self OpenSCADA.

Learn, learn and learn better than work, work and work.
Written on: 19. 08. 2009 [11:44]
Unaie
Unai Ezta
Topic creator
registered since: 30.06.2009
Posts: 42
roman wrote:

If this variable undefined then this correct. And by help OUTPUT LINK value allways will writed to ModBus.


is an OUTPUT LINK continuously written to PLC?
At frecuency 1000Hz same value again and again?

I attach a DB sample (pass 0000), see ModBus, LogicLevel and Templates.
There are two problems with this code.

1. Values are continuosly writen to PLC, and you cannot externally change it.

2. When Exiting, Oscada finally writes 1 to R1 and to R2 registers.



[This article was edited 1 times, at last 19.08.2009 at 11:45.]
Attachment

dbsample.zip (File type: application/zip, Size: 642.68 kilobytes) — 4536 downloads
Written on: 20. 08. 2009 [13:16]
Unaie
Unai Ezta
Topic creator
registered since: 30.06.2009
Posts: 42
More tests..

I have tried to use BLOCK BASED CALC instead of LOGIC LEVEL and TEMPLATES. I use the same JavaScript Code and I set links to ModBus in a Block.

Now OSCADA does not write values at exiting, it writes values at starting, curiously it reestablishes in PLC the old values from Oscada before last execution.

And, in any way, it is impossible to change externally values in PLC because OSCADA always reestablish the old values.

Then, at summary, if you use OUTPUT LINKS values not explicitly set are written to PLC:


---------------LOGIC LEVEL------------ BLOCK BASED CALC

STARTING---- NOTHING ----------------- Writes old values
AT EXIT------ Writes 1 to Integers ----- NOTHING
PROCESS ----( you cannot externaly change values in PLC. They are reestablished )



Written on: 20. 08. 2009 [13:43]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
Unaie wrote:

PS: After a new Test... Really you can comment all javascript code.
Necessary and sufficient condition is R1,R2 declared as OUTPUT LINK and Logic Level Parameter Link to ModBus Enabled. Then old values are always reestablished.

With script all work fine:
JAVASCRIPT
if( R_old != R && R != EVAL_REAL ) Special.FLibSYS.floatSplitWord(R,R1,R2); 
R_old = R = (R1==EVAL_INT || R2==EVAL_INT) ? EVAL_REAL : Special.FLibSYS.floatMergeWord(R1,R2);


P.S. I add writing to PLC only if value is new and not equal EVAL.

Learn, learn and learn better than work, work and work.
Written on: 20. 08. 2009 [19:00]
Unaie
Unai Ezta
Topic creator
registered since: 30.06.2009
Posts: 42
roman wrote:

P.S. I add writing to PLC only if value is new and not equal EVAL.


Great. Tested with last SVN and it is OK for me. Thank you.

Now I can externally change values and there are not writes on exit.

PS: Curiously, when I started my project with this new SVN I had lost all my recent javascript sources in VCA, they are old versions. I opened again with the old SVN and all my code is OK. (??). Then, manually I copied my javascript code to the opened project in new SVN. But I don't understand what happened. A locales problem again?

[This article was edited 1 times, at last 20.08.2009 at 19:02.]
Written on: 21. 08. 2009 [09:32]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
Unaie wrote:

PS: Curiously, when I started my project with this new SVN I had lost all my recent javascript sources in VCA, they are old versions. I opened again with the old SVN and all my code is OK. (??). Then, manually I copied my javascript code to the opened project in new SVN. But I don't understand what happened. A locales problem again?

You do not change new script perhaps. I have not this problem on multilingual DB.

Learn, learn and learn better than work, work and work.
Written on: 21. 08. 2009 [23:36]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
Unaie wrote:

PS: Curiously, when I started my project with this new SVN I had lost all my recent javascript sources in VCA, they are old versions. I opened again with the old SVN and all my code is OK. (??). Then, manually I copied my javascript code to the opened project in new SVN. But I don't understand what happened. A locales problem again?

It is real problem and it fixed now!

Learn, learn and learn better than work, work and work.



9368