|
Written on: 14. 12. 2016 [15:10]
|
|
cvillegas
Claudio Villegas
Topic creator
registered since: 26.10.2016
Posts: 14
|
Dear Roman:
First of all, I congratulate you for the great work you have done in the development of OpenScada.
I recently implemented the "Work" version to meet and implement some data acquisitions via modbus, which has worked perfectly.
I only have a doubt as to why at the time of archiving in DB (Mysql) the error values (EVAL) are stored according to the definition of specific values and not with a null value.
I think it is more manageable, that the error values are stored as "NULL" in the database and not with the specific error value that is defined in the c ++ code
Additionally, for the particular case of the values defined as EVAL_RFlt, which have error value definition -3.29E38 when sending the stored value to db (-3.28999992625173e38) and not exactly the defined value.
Is this a bug?
Thank you for commenting on your appreciation.
|
|
Written on: 14. 12. 2016 [18:48]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3742
|
"cvillegas" wrote:
I only have a doubt as to why at the time of archiving in DB (Mysql) the error values (EVAL) are stored according to the definition of specific values and not with a null value.
But null impossible to discern into mysql_fetch_row() mostly.
No, that is possible, but EVAL it's only Archive.DBArch specific and it can be different for all types:
//Error values, generic
#define EVAL_BOOL<----->2
#define EVAL_INT<------>-9223372036854775807ll
#define EVAL_REAL<----->-1.79E308
#define EVAL_STR<------>"<EVAL>"
//Error values, extended
#define EVAL_INT16<---->-32767
#define EVAL_INT32<---->-2147483647
#define EVAL_INT64<---->-9223372036854775807ll
#define EVAL_RFlt<----->-3.29E38
#define EVAL_RDbl<----->-1.79E308
Anyway for me that is OK!
"cvillegas" wrote:
Additionally, for the particular case of the values defined as EVAL_RFlt, which have error value definition -3.29E38 when sending the stored value to db (-3.28999992625173e38) and not exactly the defined value.
Is this a bug?
That is MySQL limit, OpenSCADA sends it just as "-3.29e38".
Learn, learn and learn better than work, work and work.
|
|
Written on: 14. 12. 2016 [21:50]
|
|
cvillegas
Claudio Villegas
Topic creator
registered since: 26.10.2016
Posts: 14
|
Thanks for your reply.
With respect to the second point, my first conclusion was just that mysql modified the value, but after verifying the queries (enable log logging on the server), I verified that the data was wrong. I registered the queries that the openSCADA sends to the mysql db and I verified that it is the openSCADA that sends the erroneous data (-3.28999992625173e + 38).
I think it may be due to an error converting float to string to generate the sql string.
If I put the value "by hand" it registers without problems in the db mysql.
helpful to your comments.
Attachment
mysql_log.png (File type: image/png, Size: 123.84 kilobytes) — 2318 downloads
|
|
Written on: 15. 12. 2016 [21:54]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3742
|
I have updated Archive.DBArch for simplification of the EVAL processing and adapted DB.SQLite and DB.MySQL to use "null" on the DB side for EVAL.
Tomorrow I will adapt also DB.PostgreSQL and DB.FireBird for "null" using and then will commit the changes.
Learn, learn and learn better than work, work and work.
|
|
Written on: 15. 12. 2016 [22:55]
|
|
cvillegas
Claudio Villegas
Topic creator
registered since: 26.10.2016
Posts: 14
|
Thank you very much!
I'll wait for the commit.
|
|
Written on: 16. 12. 2016 [17:54]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3742
|
"cvillegas" wrote:
I'll wait for the commit.
r2451
Learn, learn and learn better than work, work and work.
|
|
Written on: 19. 12. 2016 [23:38]
|
|
cvillegas
Claudio Villegas
Topic creator
registered since: 26.10.2016
Posts: 14
|
r2451 tester, working perfectly.
Thank you.
Saludos desde Chile...!!!
|
