@Jan-Reitinger Hi Jan,

Thanks for clearign that up.

I'm not sure what happened with the slave device, it hasn't been changed at all, a mystery! If I find the issue I'll le you know.

Cheers,
Mike

@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).
e8e7f83c-6ba9-44db-9318-cb844cbf6d51-image.png

Cheers,
Jan

@mtomek Hello,
I'm really sorry—I somehow overlooked the fact that you were posting in this old thread. The "Warning 1 1" indicates that the buffer for serial communication between the Master and Slave devices is full:

#define WARNING_SERIAL 1 #define WARNING_SERIAL_BUFFER_FULL 1

Have you added any new data communication or changed the communication speed recently? I’d also like to point out that REXduino is a third-party project, and we don’t have direct control over it. I found the explanation for the warning directly in the source code here:
https://github.com/jaroslavs/REXduino/blob/master/REXduino_slave/REXduino_slave.ino

Cheers,
Jan

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 with the community!

Good luck with your project.

Tomas

@mtomek Hi Michal,

if the period of read/write request won't be shorter than a few seconds I would use REXYGEN REST API - see docs: https://www.rexygen.com/doc/ENGLISH/MANUALS/RexRestApi/RexRestApi_ENG.html

Have a look at the "0302 IoT Integrations" examples folder - it contains some examples on using REST API.

Cheers,
Tomas

@jarek If the UniPi you are using have RS485 bus it will work.

@mikeyh Hi Mike,
I'm sorry for the late reply. Unfortunately, we do not have a floating licenses yet. We are counting on something similar in the future, but I'm irfaid it will take some time.
Cheers,
Jan

The problem was indeed a licensing issue, it is now solved thanks to Rexygen support - excellent customer service as always.

Hi!
Thanks for reaching out. In general, it is possible.
However, you would need to edit the sketch for REXduino in order to read out the touch position and communicate it to REXYGEN which could be pretty challenging (depending on your programming skills). It would require knowledge of the REXduino communication mechanism which is not documented (except the code).

What about posting the touch position information via REST API to REXYGEN? Example "0302-11 ESP8266 REST API" might be used as a hint.

Kind Regards,
Tomas

@mikeyh
Hi Mike,
do you have the same versions of REXYGEN on your Raspberry Pi and PC? Can the RPi be pinged from your computer?

Cheers,
Jan