@MikeyH
Hi Mike,

Without seeing the full schema, my guess would be a data type mismatch. It looks like the block with the val0-2 inputs might be expecting an integer (long) data type. If that's the case, any incoming real number would get automatically rounded or truncated, which would explain the lost decimal places.
4c1bb596-2757-4241-9838-e73fc8ea7611-image.png

Cheers,
Jan

@cechurat
Hi,
I apologize for the delayed response. I needed to consult this issue further before getting back to you.

Afterwards, I verified the following behavior: after creating the simroot folder and enabling write access to it, running my project in Simulation mode causes crashes. The issue disappears when I set log.file.enabled=1 in rexcore.cfg.

This can be used as a temporary workaround, although it slightly slows down execution, especially when the simulation is run repeatedly many times.

If there is a better systematic solution, please let me know.

Best regards,
Stepan

@MikeyH Hi Mike,

Thanks for the details. Currently, there is no direct support for such data representation.

For small-scale, I can imagine using the CNDR function block. You can also check the STEAM function block, but it appears the data you require is missing there.

There is also the possibility to use, e.g., Python or a C library if available.

Let me know your thoughts on this.

Regards,
Tomas

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

@MikeyH Hi Mike,

This error is triggered when something is preventing Studio from writing to the Project location. Do you have all related folders available for read and write?

If the issue persists, can you share a minimal project with us? Thanks

Cheers, Tomas

sorry, I've just worked it out using the Bitwise demultiplexer

f8e2817e-be2b-4795-8b4f-ac8a5581218b-image.png

@har Hi har,

Thanks for the additional info. We are not able to provide free support on this since it's your custom Python script. The error is not related to the Rexygen ecosystem. It seems that the CPU dispatcher is being initialised multiple times.

Tomas

@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 !

Hi Tomas,

Thank you for your quick and precise response -- this is precisely what I was looking for.

@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).

@carvin Hi carvin,

thanks for your feedback. I would suggest to use the SRTF function block with some certain subsystem (e.g. "sybsystem_slow") within your fast task.

Would that solve your issue?

Cheers,
Tomas

Hi Carvin,

Thanks for the question. With all the provided information I don't see anything suspicious. Please, can you share the whole project (mdl files at minimum) just to see all other information and configuration which are not visible from the screenshot?

Just be aware that arrays and vectors in REXYGEN are connected by references so the flow of "information" is different from ordinary "wire" flow where the wire starts somewhere and goes somewhere else. Contrary reference contains the same data in every instance.

Kind regards,
Tomas

@Jan-Reitinger Hi Jan,

All sorted, thank you.

Cheers,
Mike

@TourneurHello,
Thank you for sharing the details of your progress and providing such comprehensive information. Taking small steps is indeed the best approach and the most reliable way to achieve your goals. If you encounter any further issues, please do not hesitate to reach out.

A note in the documentation: "If you want to replace the WeBuDi interface with the Rexygen HMI designer interface, just delete the index.hmi.js and save the HMI as index.hmi.svg" is mentioned because the visualization was created using WeBuDi in the above steps. If you didn't follow this process for WeBuDi, this note is not relevant to you.

Keep up the great work, and we're here to help whenever you need it!

Cheers,
Jan

@cechurat Hi Tomas,

No problem, and thank you for your help as always.

Cheers,
Mike

@Jan-Reitinger Thank you so much for efficient help. Now it works exactly as I wish.

@Jan-Reitinger Thank you so much for efficient help. So far I have used Inport and Outport blocks for working with subsystems. Now I am able to use them to exchange data between tasks.