Topics created by stepan.ozana

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

@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 @stepan-ozana,

The delay you're observing in Windows is likely due to process prioritization and interruption handling, which are less efficient and harder to control compared to a Linux-based system like Debian or Raspberry Pi OS. In Linux, you have better control over how processes are scheduled and managed, allowing the system to run more smoothly and minimizing the BUSY signal duration. Windows, on the other hand, tends to introduce more overhead when executing external processes, even if the script itself does nothing, due to the way it handles process management at the system level.

Additionally, our systems on Raspberry Pi use a real-time kernel, which further improves the timing and responsiveness of processes. That's why we recommend running time-critical processes on Debian-based systems.

Cheers,
Jan

@stepan-ozana Thanks for sharing your solution! Unfortunately, I don't have the required toolboxes to run the script on my computer. However, the code is well-documented and well-organized, which should make it easy for anyone with the necessary Matlab toolboxes to use it without any issues.

'modbus' requires one of the following: Industrial Communication Toolbox MATLAB Coder Support Package for NVIDIA Jetson and NVIDIA DRIVE Platforms Error in example_ModbusTcpIP_Comm_RpiToPC (line 9) m = modbus('tcpip', IP_ADDR,MODBUS_PORT) %establish communication with the server (client)

Cheers,
Jan

@stepan-ozana
Thank you for confirmation. I will update the example. Unfortunately, quite large changes occur across Matlab versions, and there are situations where a script from older versions stops working in newer ones.

Cheers,
Jan

@stepan-ozana Thanks for sharing your solution with the community!

Good luck with your project.

Tomas

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

@stepan-ozana Hello, yes PWM flags should work as HW PWM on GPIO12, GPIO13, GPIO18, GPIO19 pins. The functionality should be the same as described here: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html
https://www.electronicwings.com/raspberry-pi/raspberry-pi-pwm-generation-using-python-and-c

Best regards,
Jan

Me and my colleague finally implemented some functional solution. We make it public if anyone is interested. Many thanks to Ing. Tomáš Dočekal!
MCP4725_REXDuino_2_50_10.zip

Or, possibly N DEL blocks may also do the job.

@stepan-ozana said in Python block in 2.50.10 with RPi and external library:

Hi, I tested the block PYTHON with 2.50.10 (testing version) and RPi 3b+. Generally it works fine, however I got into troubles when using some externally installed library, particularly pysolnp (https://pypi.org/project/pysolnp/).
Here is the use case and description of what I did:
As the Buster brings both Python 2.7.16 and 3.7.3, I set the default Python3 like this:
Edit nano ~/.bashrc , add alias python='/usr/bin/python3' and alias pip=pip3, then run source ~/.bashrc.
After that, typing python --version, it shows python 3.7.3 as required by PYTHON block in Rexygen.
Then I was able to install pysolnp according official guide: pip install pysolnp.
If I run any script manually (for example the initial basic example on the web https://pypi.org/project/pysolnp/), it works fine. It uses imported pysolnp library and gives the results as expected.
However, if I run it within REXYGEN project, I got error in Rexygen diagnostics saying that 'no module named pysolnp was found'. When I run help('modules') from Python command line, I see pysolnp in the list of modules.
Is it possible that for some reason older Python 2.7.16 is called from Rexygen environment? This would maybe explain the situtation as I didn't import pysolnp here but into 3.7.3. If this is the case, how to fix this to tell Rexygen to call python3 instead of python2? On the other hand, Rexygen would probably show different error regarding version of Python itself, because it needs Python 3.7.x according documentation.
P.S. The same use case under Windows+Rexygen+pysolnp works fine.
Best regards, Stepan

I made it work. It was an issue with different user accounts. I had the package installed under pi user but it has to be installed under root user. Then it works perfectly.

You are right, I am sorry for my mistake. According documentation https://www.rexcontrols.cz/media/2.50.5/doc/PDF/CZECH/BRef_CZ.pdf
it seemed it was in basic installation. So it would be appropriate to modify my question: DO you consider embedding FMUCS to MODEL library in future? Thank you Stepan

Dear Stepan,
interesting question. When switched to flight mode, the hardware footprint (SiteID) of your laptop changes because wifi adapters disappear completely.

The solution is to obtain demo licence keys for both normal and flight mode at https://licensing.rexygen.com/homepage/demo-licence and add both of them manually to C:\ProgramData\REX Controls\REX_2_50_9_10649\RexCore\licence.txt. That way you'll always have a valid licence for your laptop.

Hope this helps, let me know.

Best regards
Jaroslav

Glad I could help!

Best regards
Jaroslav

Hi Stepan,
thanks for reporting and explaining this. Since version 2.10.8 is outdated and there is no problem in the current version 2.50.9, we're not going to fix this. Please apply a workaround as you suggested. Thanks for understanding.

Kind regards
Jaroslav

Thanks for the explanation, now I understand. Nice solution.

Jaroslav