@MikeyH Hi Mike,
We found out that there were changes to systemd in Bookworm. On the clean image, there is a problem in DNS after installing DWM. We will adjust the DWM installation accordingly so that everything works on Bookworm and older distributions. We'll let you know when we have a solution.

Cheers,
Jan

Hello @stepan-ozana,
The main point from our developer's explanation is that the problem occurs because the Python script assigns outputs from inputs only during the initialization phase (init). However, while the CNR block sets its output directly in init (based on its parameter), the VTOR block likely receives its output settings only after the first run of its main function.

Generally, blocks should not process inputs from other blocks during init. During init, each block should manage itself: check parameter settings and initialize its own outputs to starting values. Any processing of inputs and outputs involving other blocks should happen in the main runtime phase.

In this case, CNR correctly sets its output in init according to its parameter, which is acceptable. VTOR must read its inputs to set outputs, so it does this later in the main function, which is also correct.

Thus, the VTOR output being zero initially can happen because it does not update outputs until the main function runs, unlike CNR which sets fixed output at init. This explains the observed behavior with the VTOR1 showing zeros at first while sharing the same Python script with another block

In this specific case, the error message "Configuration requires higher license than available on the target device" indicates that RexCore did not find the new version of the license. If an older license version is present on the device and is sufficient concerning the scope of the project, this information should appear in the log and the project should run normally. In such a case, please ignore the error message.

This error message will be revised in future versions of REXYGEN.

Hi @gninaus,

With version 3.0, REXYGEN introduced a new licensing policy. You can find the details here:
https://eshop.rexcontrols.com/pages/licensing-policy

Could you please send us your license information at support@rexygen.com?
You can find the license info via REXYGEN Studio by using the menu Target -> Connect and then again Target -> Licensing.

Also, please attach the REXYGEN Studio Compiler output related to licensing. Here’s an example:

This will help us identify what part of the configuration requires a higher license and provide further guidance.

Cheers,
Jan

@AlexanderH Hi,
I'm sorry. For some reason I didn't get an email notifying me that you had replied. I'm glad you finally resolved the issue.

Cheers,
Jan

@AlexanderH Hi Alexander,
do you see any error messages in the system log? If so, what kind?

Does setting the outputs work as expected?

When reading inputs, I think you should both write and read within the same I2C() call — in other words, both counters should be non-zero. Usually, sending a request and receiving a response over I²C takes much less time than the REXYGEN task execution period. That’s why the I2C() function is designed to send data and, if a response is expected, receive it within the same cycle. I don’t know the exact details of the PCF8574A protocol, but I would assume that you need to perform the write and the read together in one call.

By the way, the code you pasted looks a bit broken here on the forum – that’s probably due to Markdown formatting. Please enclose the entire script in a code block using triple backticks (```) or upload it here as a text file. That way it will be much easier to read.

Cheers,
Jan

@har Hi har,

This error is related to the timing issue of the 'data_collect' task. The task takes longer to complete than the allotted time. Based on the image, I would guess that the Python block will take the most time to execute. In your case, I would inspect the timing of the whole project and also the diagnostics of task (Target ->Diagnostics -> data_collect and select the Task tab as shown bellow).

Cheers,
Jan

Hi har,
Check if RexCore is running. I see that you are solving the Python code in another thread. It is possible that your code is not only causing the error, but also causing the entire RexCore to crash. Try connecting to the Raspberry via SSH and enter the command:

systemctl status rexcore

Cheers,
Jan

@stepan-ozana
The problem is caused by a large value in the parameters tn and tp. The change occurs, but it is very slow. For a faster transition between values, set lower parameter values. For an immediate change, set 0.

@stepan-ozana Hello,
thank you for your report.

Please, what version of REXYGEN are you using? I've tested it now on 3.0.4.17197 and everything seems to work. I'm attaching a printscreen and the project.
myproject_exec.mdl myproject_task.mdl

Best regards,
Jan

Hello Štěpán,

Thanks for the detailed summary — that’s really helpful!

Regarding the first experiment with the SETPS command:
The reason the CNSTEST1:scv parameter wasn’t updated is due to the SETF parameter of the SETPS block being set to "on". In this configuration, the value is only updated on a rising edge at the SET input.
To allow the value to be updated continuously, set SETF to "off". This way, the parameter will be updated in each cycle regardless of input transitions.

As for the issue with setting the CNA:filename parameter:
The filename specified here is not part of the application on the target device. Instead, the file resides on the host PC, and its contents are imported into the project during compilation.
That’s why the filename parameter cannot be changed online — it only serves as a reference for the compiler, not as a runtime variable.
Similarly, updating the nmax parameter isn't possible either, because REXYGEN does not support dynamic arrays — both the size and content of arrays are fixed during compilation.

As a general rule, parameters that can be modified online via SETP blocks are the same ones you can manually change in Watch mode — in other words, those that are not greyed out in the parameter list. If a parameter is greyed out, it means it’s read-only during runtime and cannot be changed programmatically either.

Cheers,
Jan