Hi, is it possible to generate hardware PWM with RPi, using GPIO12 or GPIO13? I see there are flags for these pins in 0120-00_IO_Flags example, but I want to be sure. Thanks, Stepan

@Jan-Reitinger Thanks for explanation! I promise I will study the documentation in more details next time. However, still I have some remarks here.

Regarding SAT documentation:
"The maximal rate at which the active limits may vary is given by time constants tp (positive slope) and tn (negative slope)."
This statement is ambigous for me.
If we say maximal rate of the signal is affected by some parameter rate_max, then from technical point of view, higher
rate_max means higher allowable rate (1st derivative), thus indicating being close to immediate changes of the signal.
So if rate_max reaches infinity, immediate changes are allowed.

Then we should say the maximal rate at which the active limits may vary is given by INVERSE OF time constants tp,
and rate_max = 1/tp, meaning that the meaning of logic in choice of parameters tp and tn is actually inverse.

This is actually declared in the documentation of RLIM block as the steepest rise per second, and should be also repeated for for documentation of SAT to keep documentation consistent.

I tried series connection of CNR and RLIM, and changing CNR on the fly. If tp=0.1, then maximal slope is 10, and the new value of CNR is
reached in 0.1s, following linear ramp signal. This is OK, and similar functionality works for SAT block.

Also, reading "time constants tp and tn" may indicate presence of some dynamics like first-order system 1/(tp*s+1) or 1/(tn*s+1), because this technical term is ususally used
when talking about dynamic systems. It would be much better to simply use "parameters tp and tn" instead to make things clear.

@Jan-Reitinger I am thankful that you made this clear !

@Jan-Reitinger

Thanks. I tried both 3.00.2 rev. 16743 and 3.04 17159. Check out the video recording:

https://drive.google.com/file/d/1-A4vBMiOb91N9w5tX6H8bUDGmSjGPXCG/view?usp=sharing

Hi,
I am facing some troubles with the SAT block.
It should respect either variable limits or fixed limits, based on HLD signal.
However, in my project, only inner fixed limits (+0.75 , -0.75) are considered no matter if HLD is on or off.

Hello,

I am encountering issues with remote parameter setting. My initial goal was to assign a specific filename to the CNA block so that I could specify the data file before running my project. After several unsuccessful attempts, I investigated further and discovered additional issues.

Below is a summary of the four experiments I conducted:

1. Remote Parameter Setting via SETPS for the CNS Block

I attempted to change the scv parameter of the testing CNS block using the SETPS command.

The parameter did not update as expected; it remained unchanged.

2. Remote Parameter Setting via SETPX for the CNS Block

Repeating the same experiment, this time I used the SETPX command to change the scv parameter.

This approach worked correctly—the scv parameter was successfully updated.

Since both experiments target the same parameter in the same block, SETPS and SETPX should ideally produce equivalent results.

3. Remote Parameter Setting via SETPX for the CNA Block

I attempted to set a specific filename for the CNA block to allow pre-specification of the data file.

First, I tried to change the filename parameter, but this was unsuccessful.

I also tried updating the nmax parameter, but that too did not work.

4. Remote Parameter Setting via SETPX for the CNR Block

As a control test, I changed the ycn parameter of the testing CNR block using SETPX.

This operation executed without any issues.

The REXYGEN project is attached for further review.

myproject_exec.mdl myproject_task.mdl

@Jan-Reitinger Nice. Just one small remark: There's no need to use a two-dimensional input here—even formally. You can define a system with a one-dimensional input, a certain number of states, and possibly a different number of outputs. Instead of using u(t)=[sin(2πt);0] you can simply write u=u1=sin(2πt).

@Jan-Reitinger I suggest having both "reference model" suffering from noises and "reference exact model" for comparison of EKF efficiency and performance.
Please take a look at my suggestions and let me know your opinion. It seems to work. Maybe it needs a bit tuning in terms of Q,R, versus noise generators. Also, I am fighting with alignment of free text within boxes.
Here is my update:
linear-system_v2.zip

@Jan-Reitinger Sure! I'm glad to have contributed to the collection of examples. Regarding the timing issue, I may have used the wrong terminology. I don’t observe 'Overtime' in the Task Diagnostics, but I do see 'CoreWarning GTimer: Period overtime.' in the System log.

This issue occurs in the original 'EKF.zip' mentioned at the beginning of this thread—at least on my PC. It may function correctly on other machines. It may be due to using Windows instead of Linux. I will tes it on Linux.

Here is the screenshot:

Moreover:
I just realized that the current version of the example is not fully correct because it lacks process noise and measurement noise. It seems that process noise should be implemented within the block currently referred to as the 'Reference Exact Model,' which would no longer be 'exact.' Measurement noise can be simply introduced as an added signal to the model's output.

I will try to incorporate these modifications in the next few days. I plan to create a 'Reference Model' that mimics the real process while accounting for both types of noise. Once I have refined the example to meet my expectations, I will get back to you.

@Jan-Reitinger I upgraded your example. Now it uses exact reference model both for verification and emulating output measurements to be used as input to the estimator.

However, there is some timing issue here. I use tick=0.02, ntick0=4. It means period of the task is 80 ms. If I go lower with that, I receive overtime in diagnostics. This is odd, because it means that computational load is too high.
It should be much less than that.
Here is my current version:
EKF_John.zip

@stepan-ozana Regarding "Update - second part of the problem": In the meantime, I conducted a simple test of my idea using CallExt(".Taskname.blockname"), and it seems to work. If anyone is interested, I can share the test results here.

.test_on_demand_running.zip