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

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

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

@AlexanderH solved his MCP3424 multi-channel reading issue! Here's the key takeaway:

When reading multiple channels sequentially from MCP3424, conversion time must be respected. Each configuration byte starts a new conversion:

Table 4.3 from MCP3424 datasheet lists all data rates by resolution.

One-shot mode + proper timing between configure/read operations:

For 12-bit (2 channels):

Sleep time scales with resolution - 10ms works for 12-bit, 270ms needed for 18-bit

Original MCP3422 example worked because it read only 1 channel (no channel switching). The message from the previous tick was probably returned as a response.

REXYGEN example library will be extended with:

Big thanks to Alexander for the thorough debugging, testing different timing scenarios, and sharing his working scripts!

Cheers,
Jan

Before I implement my own solution, I’ve been testing conversions with a simple Base64-to-PDF tool to verify that the encoded strings I’m producing are valid.

Has anyone here dealt with converting Base64-encoded content into PDFs directly within Python? I’m wondering whether to use built-in libraries like base64 and fpdf, or if there’s a more efficient way to handle larger files.

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

DWM is not ready for Trixie yet. We are working on it. I will keep you posted when Trixie is supported.

Cheers,
Tomas

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

Yeah I see, thank you.

Cheers,
Mike

Cheers,
Jan

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

I'm sorry, but we are not able to debug third-party Python code for you.

If you made it work under plain Python, then you can send the data to REXYGEN using the REST API. Have a look at "0302-03 REST API Python Bash etc", which sends data to REXYGEN using Python.

Kind regards,
Tomas

This is related to the communication timeout - inspect data length with respect to baudrate and timeouts.

All REXYGEN error codes here in Docs: https://www.rexygen.com/doc/ENGLISH/MANUALS/BRef/BRef_ENGap3.html#x488-487000C

Cheers,
Tomas

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

Is there, or does anyone have an example of using an MCP41X digital 257 position potentiometer with SPI?

Cheers,
Mike

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

Cheers,
Jan

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