Останні повідомлення форума http://oscada.org/ua/forum/ ua Wed, 07 Oct 2026 00:22:44 +0300 mm_forum powered by TYPO3 60 Possible DAQ.ModBus template parsing offset issue (+9 registers) when using type suffixes (RIu2/RIu4) http://oscada.org/ua/forum/posts///10438/ Tue, 06 Oct 2026 05:29:22 +0300 When the first variable in a template uses a size suffix (e.g., RIu2, RIu4, RI_b), The syntax is wrong, read documentation closely! To whom need it in the future. The actual root cause After re-reading the DAQ.ModBus wiki §3.2.1 carefully, I noticed two things I had missed: "flg — flags: read/write mode (r-read, w-write), strict requesting mode (not combining) 's', registers order inversion '~', register 'e'ndian toggle (to LE in generic and BE for strings);" "Merging of the data fragments. Standard functions 1 - 4 let to request at once multiple adjacent registers or bits. This strategy often allows to optimize the traffic and time. However, the required registers are not always located adjacent to each other, this option allows you to gather them in blocks of up to 100 registers, or 1600 bits." My template had 6 gaps between attribute blocks. When the parser sees one gap right after seconda gap, the default behavior is to try to combine both into a single read spanning the gap, which doesn't work cleanly. With phantoms, the parser seemed to behave differently — but I now believe the phantoms were silently skipping the first block of attributes entirely, leaving the request starting from 0x1B60 (the address of di_status). The correct fix (verified) Replace the phantom lines with the s flag on the attribute that immediately follows each gap. Looking at the wiki again with this understanding: The default behavior is "request merging" — the parser tries to coalesce adjacent registers into one read. When there's a gap, the merge attempt is ambiguous: should the parser skip the gap and continue, or should it emit a separate request? The 's' flag says explicitly: "this attribute is in a separate request; don't merge with the previous block." It's a clean, documented, declarative way to handle gaps. My phantom-line "fix" was implicit and accidental — it changed the parser's behavior in a way that happened to start reading from 0x1B60 instead of 0x1B57, but at the cost of silently losing the first 9 attributes' worth of data. If anyone is reading this because they're debugging ModBus template offset issues, before declaring a parser bug: 1.Check if your template has gaps — count the address jumps between non-contiguous blocks. 2.Apply the 's' flag on the first attribute after each gap. 3.Verify with wire capture (e.g., strace -e trace=read,write -p $(pidof openscada) or by capturing the serial port). 4.Don't insert phantom lines — they don't work as expected and will silently lose data. Acknowledgments Thanks to the OpenSCADA maintainer Roman for the prompt and accurate feedback. The original "E.O.R.E. bug" report was based on an incorrect workaround on my side. The actual settinngs is one well-documented flag away. — User report, post-mortem "roman" wrote:

"Enrique" wrote:

When the first variable in a template uses a size suffix (e.g., RIu2, RIu4, RI_b),

The syntax is wrong, read documentation closely!

To whom need it in the future.
The actual root cause
After re-reading the DAQ.ModBus wiki §3.2.1 carefully, I noticed two things I had missed:
"flg — flags: read/write mode (r-read, w-write), strict requesting mode (not combining) 's', registers order inversion '~', register 'e'ndian toggle (to LE in generic and BE for strings);"
"Merging of the data fragments. Standard functions 1 - 4 let to request at once multiple adjacent registers or bits. This strategy often allows to optimize the traffic and time. However, the required registers are not always located adjacent to each other, this option allows you to gather them in blocks of up to 100 registers, or 1600 bits."

My template had 6 gaps between attribute blocks.
When the parser sees one gap right after seconda gap, the default behavior is to try to combine both into a single read spanning the gap, which doesn't work cleanly.
With phantoms, the parser seemed to behave differently — but I now believe the phantoms were silently skipping the first block of attributes entirely, leaving the request starting from 0x1B60 (the address of di_status).
The correct fix (verified)
Replace the phantom lines with the s flag on the attribute that immediately follows each gap.
Looking at the wiki again with this understanding:

The default behavior is "request merging" — the parser tries to coalesce adjacent registers into one read.
When there's a gap, the merge attempt is ambiguous: should the parser skip the gap and continue, or should it emit a separate request?
The 's' flag says explicitly: "this attribute is in a separate request; don't merge with the previous block." It's a clean, documented, declarative way to handle gaps.

My phantom-line "fix" was implicit and accidental — it changed the parser's behavior in a way that happened to start reading from 0x1B60 instead of 0x1B57, but at the cost of silently losing the first 9 attributes' worth of data.

If anyone is reading this because they're debugging ModBus template offset issues, before declaring a parser bug:
1.Check if your template has gaps — count the address jumps between non-contiguous blocks.
2.Apply the 's' flag on the first attribute after each gap.
3.Verify with wire capture (e.g., strace -e trace=read,write -p $(pidof openscada) or by capturing the serial port).
4.Don't insert phantom lines — they don't work as expected and will silently lose data.

Acknowledgments
Thanks to the OpenSCADA maintainer Roman for the prompt and accurate feedback.
The original "E.O.R.E. bug" report was based on an incorrect workaround on my side.
The actual settinngs is one well-documented flag away.
— User report, post-mortem ]]> Bug tracker Enrique Possible DAQ.ModBus template parsing offset issue (+9 registers) when using type suffixes (RIu2/RIu4) http://oscada.org/ua/forum/posts///10437/ Mon, 05 Oct 2026 19:03:47 +0300 When the first variable in a template uses a size suffix (e.g., RIu2, RIu4, RI_b), The syntax is wrong, read documentation closely! "Enrique" wrote:

When the first variable in a template uses a size suffix (e.g., RIu2, RIu4, RI_b),

The syntax is wrong, read documentation closely! ]]> Bug tracker roman Possible DAQ.ModBus template parsing offset issue (+9 registers) when using type suffixes (RIu2/RIu4) http://oscada.org/ua/forum/posts///10436/ Mon, 05 Oct 2026 18:02:00 +0300 Hello OpenSCADA Development Team, During a recent production integration of some solar devices over RS-485, we identified a parsing bug in the DAQ.ModBus module related to the "Standard Prm" configuration templates. When the first variable in a template uses a size suffix (e.g., RIu2, RIu4, RI_b), the module generates a ModBus request with a starting address shifted +9 registers forward. This causes the initial attributes to be skipped entirely, resulting in <EVAL> states on the UI. 1. Bug Description & Evidence Our target starting address for the first attribute (device_type) was 0x1B57 (6999). However, capturing the serial traffic directly from the OpenSCADA logs revealed that the frame was starting at 0x1B60 (7008). Captured Request (from Devuan server): 2026-06-10T12:05:52 0 REQ -> 01 04 1B 60 00 21 36 E8 Frame Breakdown: Slave: 01 FC: 04 (Read Input Registers) Address Start: 0x1B60 (7008) ❌ Should be 0x1B57 (6999) Length: 0x0021 (33) CRC: 36 E8 (Valid) The frame is syntactically valid and the slave responds successfully, confirming this is not a transport issue but an error in how DAQ.ModBus constructs the request payload. The +9 register difference corresponds exactly to our first 8 template variables (which consume 9 registers due to one RIu4) plus 1 padding register. 2. Root Cause Hypothesis Empirical testing shows that the DAQ.ModBus internal parser fails to initialize or reset its starting offset correctly if the first variable it parses contains a type suffix. The offset state becomes "dirty" and carries forward. The parser only resets its internal state when it encounters a raw, unsuffixed variable (e.g., RI: instead of RIu2:). 3. Production Workaround We successfully bypassed the bug by injecting "phantom" (unsuffixed) variables into the template at the exact address of the first real variable, using an underscore prefix to hide them. # ========================================================================= # PHANTOM VARIABLE: Resets the DAQ.ModBus parser state. # Without this, the request shifts +9 registers. # ========================================================================= RI:0x1B57:r:_device_type:_Device Type # REAL VARIABLE: Actually used by the widgets RIu2:0x1B57:r:device_type:Device Type To make the template work completely, we had to apply this phantom variable trick not just at the beginning, but every time the data type changed within the template (e.g., transitioning from u2 to u4). In total, our 62-attribute template required 25 phantom lines to ensure standard Modbus polling. Once the workaround was applied, the request formatted perfectly: REQ -> 01 04 1B 57 00 4B 07 09 (Start address: 0x1B57 (6999), Length: 75 registers. All 62 attributes read successfully). Minor Documentation Note As a minor secondary note, the OpenSCADA Wiki documentation regarding address conversion (template = manual - 1 for zero-based addressing) was accurate, though our initial supplied offset list had 0x1B58 instead of 0x1B57. We regenerated our lists to strictly follow the zero-based rule, which works perfectly. Our system is currently still in development using the phantom variable workaround (and works), but we are reporting this so the parser initialization logic can be reviewed and patched upstream in a future release. Or maybe we miss something... Minor Documentation Note As a minor secondary note, the OpenSCADA Wiki documentation regarding address conversion (template = manual - 1 for zero-based addressing) was accurate, though our initial supplied offset list had 0x1B58 instead of 0x1B57. We regenerated our lists to strictly follow the zero-based rule, which works perfectly. Best regards, During a recent production integration of some solar devices over RS-485, we identified a parsing bug in the DAQ.ModBus module related to the "Standard Prm" configuration templates.

When the first variable in a template uses a size suffix (e.g., RIu2, RIu4, RI_b), the module generates a ModBus request with a starting address shifted +9 registers forward. This causes the initial attributes to be skipped entirely, resulting in <EVAL> states on the UI.

1. Bug Description & Evidence
Our target starting address for the first attribute (device_type) was 0x1B57 (6999). However, capturing the serial traffic directly from the OpenSCADA logs revealed that the frame was starting at 0x1B60 (7008).

Captured Request (from Devuan server):
2026-06-10T12:05:52 0[/sub_DAQ/mod_ModBus/cntr_CB_1/]
REQ -> 01 04 1B 60 00 21 36 E8

Frame Breakdown:

Slave: 01

FC: 04 (Read Input Registers)

Address Start: 0x1B60 (7008) ❌ Should be 0x1B57 (6999)

Length: 0x0021 (33)

CRC: 36 E8 (Valid)

The frame is syntactically valid and the slave responds successfully, confirming this is not a transport issue but an error in how DAQ.ModBus constructs the request payload. The +9 register difference corresponds exactly to our first 8 template variables (which consume 9 registers due to one RIu4) plus 1 padding register.

2. Root Cause Hypothesis
Empirical testing shows that the DAQ.ModBus internal parser fails to initialize or reset its starting offset correctly if the first variable it parses contains a type suffix. The offset state becomes "dirty" and carries forward.

The parser only resets its internal state when it encounters a raw, unsuffixed variable (e.g., RI: instead of RIu2:).

3. Production Workaround
We successfully bypassed the bug by injecting "phantom" (unsuffixed) variables into the template at the exact address of the first real variable, using an underscore prefix to hide them.
# =========================================================================
# PHANTOM VARIABLE: Resets the DAQ.ModBus parser state.
# Without this, the request shifts +9 registers.
# =========================================================================
RI:0x1B57:r:_device_type:_Device Type

# REAL VARIABLE: Actually used by the widgets
RIu2:0x1B57:r:device_type:Device Type
To make the template work completely, we had to apply this phantom variable trick not just at the beginning, but every time the data type changed within the template (e.g., transitioning from u2 to u4). In total, our 62-attribute template required 25 phantom lines to ensure standard Modbus polling.

Once the workaround was applied, the request formatted perfectly:
REQ -> 01 04 1B 57 00 4B 07 09
(Start address: 0x1B57 (6999), Length: 75 registers. All 62 attributes read successfully).

Minor Documentation Note
As a minor secondary note, the OpenSCADA Wiki documentation regarding address conversion (template = manual - 1 for zero-based addressing) was accurate, though our initial supplied offset list had 0x1B58 instead of 0x1B57. We regenerated our lists to strictly follow the zero-based rule, which works perfectly.

Our system is currently still in development using the phantom variable workaround (and works), but we are reporting this so the parser initialization logic can be reviewed and patched upstream in a future release.
Or maybe we miss something...
Minor Documentation Note
As a minor secondary note, the OpenSCADA Wiki documentation regarding address conversion (template = manual - 1 for zero-based addressing) was accurate, though our initial supplied offset list had 0x1B58 instead of 0x1B57. We regenerated our lists to strictly follow the zero-based rule, which works perfectly.

Best regards, ]]> Bug tracker Enrique Website issues: August–September http://oscada.org/ua/forum/posts///10435/ Tue, 29 Sep 2026 19:24:49 +0300 Hello! I wanted to find out what happened to the site over the past two months. The server remained partially operational (SVN, FTP). I tried sending an email but received no reply; however, Me became very limited in access to the OpenSCADA server, so it was down in HTTP resources under huge DDOS. "walhi" wrote:

Hello! I wanted to find out what happened to the site over the past two months. The server remained partially operational (SVN, FTP). I tried sending an email but received no reply; however,

Me became very limited in access to the OpenSCADA server, so it was down in HTTP resources under huge DDOS. ]]> News roman Website issues: August–September http://oscada.org/ua/forum/posts///10434/ Sun, 27 Sep 2026 23:17:05 +0300 Hello! I wanted to find out what happened to the site over the past two months. The server remained partially operational (SVN, FTP). I tried sending an email but received no reply; however, I didn't get any delivery failure notifications from the mail server either. I am very glad that the project's official website and forum have been restored. News walhi json library http://oscada.org/ua/forum/posts///10433/ Fri, 27 Mar 2026 17:35:18 +0200 ok, I'll read the requirements and write documentation for the functions like in other OpenSCADA libraries. By comments I meant feedback from people who will use the library. OK, I have included the library to the standard OpenSCADA libraries without your documenting as is, due to your mention "License: GPLv2"! And I have tested only deserialize(), which works, but you must not to include temporary internal variables "str" and "i" to the function arguments! "arccis" wrote:

ok, I'll read the requirements and write documentation for the functions like in other OpenSCADA libraries. By comments I meant feedback from people who will use the library.

OK, I have included the library to the standard OpenSCADA libraries without your documenting as is, due to your mention "License: GPLv2"!

And I have tested only deserialize(), which works, but you must not to include temporary internal variables "str" and "i" to the function arguments! ]]> OpenSCADA development roman There is no session and project of the VCA engine... http://oscada.org/ua/forum/posts///10432/ Wed, 25 Mar 2026 07:09:00 +0200 I couldn't find the quick start in the manual, number 1003. 10003 doesn't do anything either. It doesn't matter. And me can ... "Fudodo" wrote:

I couldn't find the quick start in the manual, number 1003. 10003 doesn't do anything either. It doesn't matter.

And me can ... ]]> Miscellaneous roman There is no session and project of the VCA engine... http://oscada.org/ua/forum/posts///10431/ Wed, 25 Mar 2026 00:25:17 +0200 I couldn't find the quick start in the manual, number 1003. 10003 doesn't do anything either. It doesn't matter. I reinstalled the system on debian 13. I added the repositories as instructed and a new restriction on SSL signature rejection appeared. I override it via edit /usr/share/apt/default-sequoia.config and set sha1.second_preimage_resistance to a later date. Then apt install openscada works. Now the system works on port 10002 thank You
I reinstalled the system on debian 13.
I added the repositories as instructed and a new restriction on SSL signature rejection appeared.
I override it via edit /usr/share/apt/default-sequoia.config and set sha1.second_preimage_resistance to a later date.
Then apt install openscada works.

Now the system works on port 10002

thank You

]]> Miscellaneous Fudodo There is no session and project of the VCA engine... http://oscada.org/ua/forum/posts///10430/ Tue, 24 Mar 2026 07:51:53 +0200 It is you only are connected to a background Server service where is no VCA-Session, obviously! :) If you want to connect just started model in UI, you may use next WEB-port — 10003. And read Quick Start for understanding!
If you want to connect just started model in UI, you may use next WEB-port — 10003.

And read Quick Start for understanding! ]]> Miscellaneous roman There is no session and project of the VCA engine... http://oscada.org/ua/forum/posts///10429/ Tue, 24 Mar 2026 00:59:23 +0200 Hi, i found version where web VCA working, Debian_8-OpenSCADA_1+r2991-TDE_R14-amd64-LiveCD_USB.iso, bud old debian regards Jozef
i found version where web VCA working, Debian_8-OpenSCADA_1+r2991-TDE_R14-amd64-LiveCD_USB.iso, bud old debian

regards Jozef ]]> Miscellaneous Fudodo There is no session and project of the VCA engine... http://oscada.org/ua/forum/posts///10428/ Mon, 23 Mar 2026 23:19:34 +0200 Hi, I'm migrate to new virtual machine, installed Debian_13-OpenSCADA_1+r3056-TDE_R14-amd64-LiveCD_USB.iso On the web interface standard login to user. And on try to open Operation user interface show "There is no session and project of the VCA engine for the user!" same message on AGLKS and Boiler Migrating from old system thru backup and restore, and next try direct copy project folder. Same effect. On old machine web VCA working, system oscada have OpenScada 1+r3056. screenshot from not work web VCA attached. I tried a live installation Debian_12-OpenSCADA_1+r2961-TDE_R14-amd64-LiveCD_USB.iso What am I doing wrong? regards Jozef
I'm migrate to new virtual machine, installed Debian_13-OpenSCADA_1+r3056-TDE_R14-amd64-LiveCD_USB.iso
On the web interface standard login to user. And on try to open Operation user interface show "There is no session and project of the VCA engine for the user!"
same message on AGLKS and Boiler

Migrating from old system thru backup and restore, and next try direct copy project folder. Same effect.

On old machine web VCA working, system oscada have OpenScada 1+r3056.



screenshot from not work web VCA attached.

I tried a live installation Debian_12-OpenSCADA_1+r2961-TDE_R14-amd64-LiveCD_USB.iso

What am I doing wrong?

regards Jozef ]]> Miscellaneous Fudodo Autobuilder for debian 13 http://oscada.org/ua/forum/posts///10427/ Wed, 18 Feb 2026 13:46:17 +0200 Thanks, I have used this tip in the Debian 13 Live Disk due to I have no problem with SHA-1 on my repositories for throw to breaking compatibility previous ones! Adaption and development in OpenSCADA roman Autobuilder for debian 13 http://oscada.org/ua/forum/posts///10425/ Tue, 17 Feb 2026 00:41:59 +0200 release of Debian 13! There were problems installing a package from the repository. Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z Users can find a quick solution to the problem by following this link: https://github.com/openresty/openresty/issues/1097 mkdir -p /etc/crypto-policies/back-ends echo ' sha1 = "always"' > /etc/crypto-policies/back-ends/apt-sequoia.config "roman" wrote:

release of Debian 13!


There were problems installing a package from the repository.

Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z

Users can find a quick solution to the problem by following this link: https://github.com/openresty/openresty/issues/1097
JAVASCRIPT
mkdir -p /etc/crypto-policies/back-ends
echo '[hash_algorithms]
sha1 = "always"' > /etc/crypto-policies/back-ends/apt-sequoia.config
]]> Adaption and development in OpenSCADA walhi [Qt+Wayland] Loss combobox items after empty one http://oscada.org/ua/forum/posts///10424/ Sat, 14 Feb 2026 10:20:12 +0200 OpenSCADA: > UI.{QTCfg,Vision} Linux: Debian 12 64 Qt: 5.15.8 Resume: An environmental bug of the Qt in working on Wayland with representing empty items in the combobox list, which was reproduced on two devices. Workaround: Only use XOrg now. OpenSCADA: [Work 1.0-r3xxx, LTS 0.9.8] > UI.{QTCfg,Vision}
Linux: Debian 12 64
Qt: 5.15.8
Resume: An environmental bug of the Qt in working on Wayland with representing empty items in the combobox list, which was reproduced on two devices.
Workaround: Only use XOrg now. ]]> Bug tracker roman [Qt] Crashing at insertion empty buffer to Text Areas http://oscada.org/ua/forum/posts///10423/ Sat, 14 Feb 2026 10:01:55 +0200 OpenSCADA: > UI.{QTCfg,Vision} Linux: Debian 12 64 Qt: 6.4.2 Resume: An environmental bug of the Qt in working with the copy-past buffer in Text Areas Workaround: The bug fixed in Qt 6.4 of bigger minors, but the broken version is frozen already in Debian 12, so there we build OpenSCADA there with Qt5 still. OpenSCADA: [Work 1.0-r3xxx, LTS 0.9.7] > UI.{QTCfg,Vision}
Linux: Debian 12 64
Qt: 6.4.2
Resume: An environmental bug of the Qt in working with the copy-past buffer in Text Areas
Workaround: The bug fixed in Qt 6.4 of bigger minors, but the broken version is frozen already in Debian 12, so there we build OpenSCADA there with Qt5 still. ]]> Bug tracker roman [Sockets] Wrong holding the socket handler http://oscada.org/ua/forum/posts///10422/ Sat, 14 Feb 2026 09:37:48 +0200 The problem has not reproduced more up to 14.02.2026. Bug tracker roman Quick Start HMI не працює + як використати alarms? http://oscada.org/ua/forum/posts///10421/ Fri, 28 Nov 2025 08:08:19 +0200 Підскажіть будь ласка в чому може бути помилка та чому проект не запускається? Він запускається, то у вас встановлення зламане, бо відсутні бібліотеки! Також інше питання, які є можливості сигналів (alarms) в OpenScada та як їх можна застосувати наприклад у використанні Modbus tcp з Arduino PLC. Читайте документацію: http://oscada.org/wiki/Special:MyLanguage/Documents/Program_manual#ArchMess http://oscada.org/wiki/Special:MyLanguage/Modules/VCAEngine#Alarms http://oscada.org/wiki/Special:MyLanguage/Libs/Main_graphical_elements#alarmsSt ... І що почати із ЧаП — http://oscada.org/ua/golovna/chasti-pitannja/ "scada_2025_" wrote:

Підскажіть будь ласка в чому може бути помилка та чому проект не запускається?

Він запускається, то у вас встановлення зламане, бо відсутні бібліотеки!

"scada_2025_" wrote:

Також інше питання, які є можливості сигналів (alarms) в OpenScada та як їх можна застосувати наприклад у використанні Modbus tcp з Arduino PLC.

Читайте документацію:
http://oscada.org/wiki/Special:MyLanguage/Documents/Program_manual#ArchMess
http://oscada.org/wiki/Special:MyLanguage/Modules/VCAEngine#Alarms
http://oscada.org/wiki/Special:MyLanguage/Libs/Main_graphical_elements#alarmsSt
...

І що почати із ЧаП — http://oscada.org/ua/golovna/chasti-pitannja/ ]]> Впровадження та розробка у OpenSCADA roman Quick Start HMI не працює + як використати alarms? http://oscada.org/ua/forum/posts///10420/ Thu, 27 Nov 2025 18:14:31 +0200 Добрий день , намагаюсь розібратись в OpenSCADA . Хотіла запустити на Ubuntu 24.04.3 "Quick Start", саме АГЛКС, але HMI не відтворюється , також є ця помилка "Picute is not set". Підскажіть будь ласка в чому може бути помилка та чому проект не запускається? Також інше питання, які є можливості сигналів (alarms) в OpenScada та як їх можна застосувати наприклад у використанні Modbus tcp з Arduino PLC. Також інше питання, які є можливості сигналів (alarms) в OpenScada та як їх можна застосувати наприклад у використанні Modbus tcp з Arduino PLC. ]]> Впровадження та розробка у OpenSCADA scada_2025_ Problem with binding to data source using relative path. http://oscada.org/ua/forum/posts///10419/ Sun, 16 Nov 2025 20:53:43 +0200 ... I'm encountering a problem where the connection to the source is broken when restarting the SCADA system. The configuration field specifies prm:../../word (+), but the connection is broken. What am I doing wrong? You linked to a parameter "prm:../../word" where is no data attribute, and the relative links correctly work with wide using and testing! "walhi" wrote:

... I'm encountering a problem where the connection to the source is broken when restarting the SCADA system. The configuration field specifies prm:../../word (+), but the connection is broken. What am I doing wrong?

You linked to a parameter "prm:../../word" where is no data attribute, and the relative links correctly work with wide using and testing! ]]> Adaption and development in OpenSCADA roman Problem with binding to data source using relative path. http://oscada.org/ua/forum/posts///10418/ Sun, 16 Nov 2025 19:40:26 +0200 Hello. I have a multi-level structure in my data acquisition system where a standard parameter reads a register from the controller, and child logical parameters pull individual bits from this register. This is designed specifically to make it easy to copy similar blocks by changing the register address in just one place, rather than in each logical parameter. I'm encountering a problem where the connection to the source is broken when restarting the SCADA system. The configuration field specifies prm:../../word (+), but the connection is broken. What am I doing wrong? Adaption and development in OpenSCADA walhi FormEl table ceil color http://oscada.org/ua/forum/posts///10417/ Sat, 11 Oct 2025 21:54:56 +0300 src/moduls/ui/Vision/vis_shapes.cpp -- tit->setData(Qt::BackgroundRole, QColor(wVl.c_str())); ++ tit->setData(Qt::BackgroundRole, getColor(wVl.c_str())); -- tit->setData(Qt::ForegroundRole, QColor(wVl.c_str())); ++ tit->setData(Qt::ForegroundRole, getColor(wVl.c_str())); Yes, I have added of using the standard OpenSCADA function getColor() for transparency here. This doesn't solve the problem of identical display both on the web and locally, but it's better than before. Bonus: experience building from source. And for that I have adapted UI.WebVision for parsing alfa value from OpenSCADA format and placing it to "rgba(red, green, blue, alpha)" in case of hex colors, due to named colors are needed of conversion to hex. "walhi" wrote:

JAVASCRIPT
src/moduls/ui/Vision/vis_shapes.cpp
-- tit->setData(Qt::BackgroundRole, QColor(wVl.c_str()));
++ tit->setData(Qt::BackgroundRole, getColor(wVl.c_str()));
 
-- tit->setData(Qt::ForegroundRole, QColor(wVl.c_str()));
++ tit->setData(Qt::ForegroundRole, getColor(wVl.c_str()));


Yes, I have added of using the standard OpenSCADA function getColor() for transparency here.

"walhi" wrote:

This doesn't solve the problem of identical display both on the web and locally, but it's better than before. Bonus: experience building from source.

And for that I have adapted UI.WebVision for parsing alfa value from OpenSCADA format and placing it to "rgba(red, green, blue, alpha)" in case of hex colors, due to named colors are needed of conversion to hex. ]]> Bug tracker roman FormEl table ceil color http://oscada.org/ua/forum/posts///10416/ Thu, 09 Oct 2025 23:34:00 +0300 And that is obvious for different visualizers, which smoothing is not a bug fixing also but it is a feature appending. As it turns out, the source code contains a function that solves the problem with displaying on the Qt, but it was not used in the code that populates the table cells. QColor OSCADA_QT::getColor( const string &val ) src/moduls/ui/Vision/vis_shapes.cpp -- tit->setData(Qt::BackgroundRole, QColor(wVl.c_str())); ++ tit->setData(Qt::BackgroundRole, getColor(wVl.c_str())); -- tit->setData(Qt::ForegroundRole, QColor(wVl.c_str())); ++ tit->setData(Qt::ForegroundRole, getColor(wVl.c_str())); This doesn't solve the problem of identical display both on the web and locally, but it's better than before. Bonus: experience building from source. "roman" wrote:

And that is obvious for different visualizers, which smoothing is not a bug fixing also but it is a feature appending.

As it turns out, the source code contains a function that solves the problem with displaying on the Qt, but it was not used in the code that populates the table cells.
JAVASCRIPT
QColor OSCADA_QT::getColor( const string &val )


JAVASCRIPT
src/moduls/ui/Vision/vis_shapes.cpp
-- tit->setData(Qt::BackgroundRole, QColor(wVl.c_str()));
++ tit->setData(Qt::BackgroundRole, getColor(wVl.c_str()));
 
-- tit->setData(Qt::ForegroundRole, QColor(wVl.c_str()));
++ tit->setData(Qt::ForegroundRole, getColor(wVl.c_str()));


This doesn't solve the problem of identical display both on the web and locally, but it's better than before. Bonus: experience building from source. ]]> Bug tracker walhi FormEl table ceil color http://oscada.org/ua/forum/posts///10415/ Thu, 09 Oct 2025 19:05:24 +0300 Just see the source code of the related visualizer before open bugs The forum section description states that this section should be used to report errors and inaccuracies in the documentation. Since I couldn't find a description of this specific feature in the documentation, the original purpose of this post was to supplement the documentation. But as it turns out, this is more like a problem. Firstly, OpenSCADA documentation cannot trace all specific of the visualization frameworks and changes in their structures! Secondary, that is not about errors in the documentation and for such its improvements created independent forum! OK, and where there about bugs? However, as it later turned out, the interfaces in WebVision and QtVision look different, something I only discovered now. I am attaching another screenshot showing the difference in display. The first example showed the working user interface on Qt. And that is obvious for different visualizers, which smoothing is not a bug fixing also but it is a feature appending. Your example just show the difference in the extending hex color on Qt and Web, that is the format is not standard in whole and even in Web appeared newly. "walhi" wrote:

"roman" wrote:

Just see the source code of the related visualizer before open bugs

The forum section description states that this section should be used to report errors and inaccuracies in the documentation. Since I couldn't find a description of this specific feature in the documentation, the original purpose of this post was to supplement the documentation. But as it turns out, this is more like a problem.

Firstly, OpenSCADA documentation cannot trace all specific of the visualization frameworks and changes in their structures!
Secondary, that is not about errors in the documentation and for such its improvements created independent forum!

"walhi" wrote:

"roman" wrote:

OK, and where there about bugs?

However, as it later turned out, the interfaces in WebVision and QtVision look different, something I only discovered now. I am attaching another screenshot showing the difference in display. The first example showed the working user interface on Qt.

And that is obvious for different visualizers, which smoothing is not a bug fixing also but it is a feature appending.

Your example just show the difference in the extending hex color on Qt and Web, that is the format is not standard in whole and even in Web appeared newly. ]]> Bug tracker roman FormEl table ceil color http://oscada.org/ua/forum/posts///10414/ Thu, 09 Oct 2025 18:51:02 +0300 Just see the source code of the related visualizer before open bugs The forum section description states that this section should be used to report errors and inaccuracies in the documentation. Since I couldn't find a description of this specific feature in the documentation, the original purpose of this post was to supplement the documentation. But as it turns out, this is more like a problem. OK, and where there about bugs? However, as it later turned out, the interfaces in WebVision and QtVision look different, something I only discovered now. I am attaching another screenshot showing the difference in display. The first example showed the working user interface on Qt. "roman" wrote:

Just see the source code of the related visualizer before open bugs

The forum section description states that this section should be used to report errors and inaccuracies in the documentation. Since I couldn't find a description of this specific feature in the documentation, the original purpose of this post was to supplement the documentation. But as it turns out, this is more like a problem.

"roman" wrote:

OK, and where there about bugs?

However, as it later turned out, the interfaces in WebVision and QtVision look different, something I only discovered now. I am attaching another screenshot showing the difference in display. The first example showed the working user interface on Qt.

]]> Bug tracker walhi FormEl table ceil color http://oscada.org/ua/forum/posts///10413/ Thu, 09 Oct 2025 18:09:23 +0300 And that is not a bug!!! I am attaching an example of a table where this appears and a screenshot. OK, and where there about bugs? That is only the WebBrowser behavior at transmission the color in hex, which OpenSCADA treats in noway! Just see the source code of the related visualizer before open bugs — http://oscada.org/svn/trunk/OpenSCADA/src/moduls/ui/WebVision/WebVisionVCA.js "walhi" wrote:

"roman" wrote:

And that is not a bug!!!

I am attaching an example of a table where this appears and a screenshot.

OK, and where there about bugs?

That is only the WebBrowser behavior at transmission the color in hex, which OpenSCADA treats in noway!

Just see the source code of the related visualizer before open bugs — http://oscada.org/svn/trunk/OpenSCADA/src/moduls/ui/WebVision/WebVisionVCA.js ]]> Bug tracker roman FormEl table ceil color http://oscada.org/ua/forum/posts///10412/ Thu, 09 Oct 2025 16:08:36 +0300 And that is not a bug!!! I am attaching an example of a table where this appears and a screenshot. <tbl colsWdthFit='1' sel = 'row'>" <h><s width = '45%'>Цвет</s><s width = '45%'>Значение</s></h> <r><s color='red-127'>_</s><s>red-127</s></r> <r><s color='red'>_</s><s>red</s></r> <r><s color='#FF0000-255'>_</s><s>#FF0000-255, непрозрачный красный RGB-A</s></r> <r><s color='#FF0000FF'>_</s><s>#FF0000FF, непрозрачный красный RGBA</s></r> <r><s color='#FFFF0000'>_</s><s>#FFFF0000, непрозрачный красный ARGB</s></r> <r><s color='#FF000040'>_</s><s>#FF000040, прозрачный красный RGBA</s></r> <r><s color='#40FF0000'>_</s><s>#40FF0000, прозрачный красный ARGB</s></r> </tbl> "roman" wrote:

And that is not a bug!!!

I am attaching an example of a table where this appears and a screenshot.

HTML
<tbl colsWdthFit='1' sel = 'row'>"
<h><s width = '45%'>Цвет</s><s width = '45%'>Значение</s></h>
<r><s color='red-127'>_</s><s>red-127</s></r>
<r><s color='red'>_</s><s>red</s></r>
<r><s color='#FF0000-255'>_</s><s>#FF0000-255, непрозрачный красный RGB-A</s></r>
<r><s color='#FF0000FF'>_</s><s>#FF0000FF, непрозрачный красный RGBA</s></r>
<r><s color='#FFFF0000'>_</s><s>#FFFF0000, непрозрачный красный ARGB</s></r>
<r><s color='#FF000040'>_</s><s>#FF000040, прозрачный красный RGBA</s></r>
<r><s color='#40FF0000'>_</s><s>#40FF0000, прозрачный красный ARGB</s></r>
</tbl>
]]> Bug tracker walhi FormEl table ceil color http://oscada.org/ua/forum/posts///10411/ Thu, 09 Oct 2025 14:48:06 +0300 Hello. I've discovered that widgets like FormEl Table have a non-standard implementation of cell color support. See in the ElFigure primitive due to that is a standard for all primitives! And that is not a bug!!! "walhi" wrote:

Hello. I've discovered that widgets like FormEl Table have a non-standard implementation of cell color support.

See in the ElFigure primitive due to that is a standard for all primitives!

And that is not a bug!!! ]]> Bug tracker roman FormEl table ceil color http://oscada.org/ua/forum/posts///10410/ Thu, 09 Oct 2025 14:33:15 +0300 Hello. I've discovered that widgets like FormEl Table have a non-standard implementation of cell color support. Experiments have shown that the color specification standard adopted in OpenSCADA (the RGB HEX value plus a separate alpha channel in DEC) is not recognized, and the standard HTML is parsed incorrectly. Instead of the RGBA ordering, the ARGB ordering is used, but I couldn't find any mention of this in the documentation. Bug tracker walhi Big syslog http://oscada.org/ua/forum/posts///10408/ Mon, 29 Sep 2025 16:35:27 +0300 You may have installed and running in the background the service configurations from openscada-server or openscada-plc with different message levels! No. One station is running. I'm checking it with tail -f /var/log/syslog, and the messages disappear if I uncheck all the boxes in the configurator "to stderr", "to stdout", and "to syslog". There's no response at the change message level". I found the problem. Level 0 was set in the PLC diagnostics. I was sure that the level set in the workstation settings took precedence over the one specified for the PLC. The only remaining issue was redirecting stdout/stder to syslog, which only occurred on one project and one operating system. "roman" wrote:

You may have installed and running in the background the service configurations from openscada-server or openscada-plc with different message levels!


No. One station is running. I'm checking it with tail -f /var/log/syslog, and the messages disappear if I uncheck all the boxes in the configurator "to stderr", "to stdout", and "to syslog". There's no response at the change message level". I found the problem. Level 0 was set in the PLC diagnostics. I was sure that the level set in the workstation settings took precedence over the one specified for the PLC. The only remaining issue was redirecting stdout/stder to syslog, which only occurred on one project and one operating system. ]]> Bug tracker walhi Big syslog http://oscada.org/ua/forum/posts///10407/ Mon, 29 Sep 2025 15:52:20 +0300 And the log size in whole is dependent only from your project, who generates extra messages!!! The problem is that the syslog add-on is disabled and the message level is set to 1, but in fact, messages with a level of 0 are logged. And this only occurs on Ubuntu. Then that is not syslog in whole but a replacement from systemd which writes stdout or stderr of the service programs. In any way, OpenSCADA writes messages corresponding to the pointed level, what you can see from the sources — http://oscada.org/svn/trunk/OpenSCADA/src/tmess.cpp You may have installed and running in the background the service configurations from openscada-server or openscada-plc with different message levels! "walhi" wrote:


And the log size in whole is dependent only from your project, who generates extra messages!!!

The problem is that the syslog add-on is disabled and the message level is set to 1, but in fact, messages with a level of 0 are logged. And this only occurs on Ubuntu.

Then that is not syslog in whole but a replacement from systemd which writes stdout or stderr of the service programs.

In any way, OpenSCADA writes messages corresponding to the pointed level, what you can see from the sources — http://oscada.org/svn/trunk/OpenSCADA/src/tmess.cpp

You may have installed and running in the background the service configurations from openscada-server or openscada-plc with different message levels! ]]> Bug tracker roman