Hi Mike, I think Jan’s explanation makes sense here. This kind of issue usually happens when the data type changes somewhere in the program flow. If the value is being stored as an integer, the decimal part will get removed automatically. I would check the variable definitions and block settings to make sure they are using the correct data type.

Cheers,
Nichole

@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

@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

Hi everyone,

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

The Problem

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

12-bit: ~5ms (1/240 s) 18-bit: ~267ms (1/3.75 s)

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

The Solution

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

For 12-bit (2 channels):

// Channel 1 - configure + convert + read i2c_bufTx[0] = 0x80; // CH1, one-shot, 12-bit, gain x1 i2c_write_count = 1; i2c_read_count = 0; i2c_ret_fun = I2C(i2c_bus_handle, i2c_chip_address, i2c_bufTx, i2c_write_count, i2c_bufRx, i2c_read_count); Sleep(0.01); // wait for 10 ms before reading the first channel // Data rate: 12bit = 240 SPS, 14bit = 60 SPS, 16bit = 15 SPS, 18bit = 3.75 SPS i2c_write_count = 0; i2c_read_count = 3; i2c_ret_fun = I2C(i2c_bus_handle, i2c_chip_address, i2c_bufTx, i2c_write_count, i2c_bufRx, i2c_read_count); // i2c_bufRx[2] contains configuration byte channel1 = ((i2c_bufRx[0]<<8) + i2c_bufRx[1])/2; i2c_bufTx[0] = 0xA0; // channel 2, one-shot, 12bit, gain 1 (see MCP3424 datasheet) i2c_write_count = 1; i2c_read_count = 0; i2c_ret_fun = I2C(i2c_bus_handle, i2c_chip_address, i2c_bufTx, i2c_write_count, i2c_bufRx, i2c_read_count); Sleep(0.01); // wait for 10 ms before reading the second channel // Data rate: 12bit = 240 SPS, 14bit = 60 SPS, 16bit = 15 SPS, 18bit = 3.75 SPS i2c_write_count = 0; i2c_read_count = 3; i2c_ret_fun = I2C(i2c_bus_handle, i2c_chip_address, i2c_bufTx, i2c_write_count, i2c_bufRx, i2c_read_count); channel2 = ((i2c_bufRx[0]<<8) + i2c_bufRx[1])/2; Important Notes

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.

Example Update

REXYGEN example library will be extended with:

read_mcp3424_12bit.c - 2 channels, 12-bit read_mcp3424_18bit.c - 2 channels, 18-bit

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

Cheers,
Jan

@Jan-Reitinger Thank you Jan. I will try it. Martin

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

@gninaus Hi Guenther,

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

Cheers,
Tomas

In this specific case, the error message "Configuration requires higher license than available on the target device" indicates that RexCore did not find the new version of the license. If an older license version is present on the device and is sufficient concerning the scope of the project, this information should appear in the log and the project should run normally. In such a case, please ignore the error message.

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

@cechurat Hi Tomas,

Yeah I see, thank you.

Cheers,
Mike

@AlexanderH Hi,
I'm sorry. For some reason I didn't get an email notifying me that you had replied. I'm glad you finally resolved the issue.

Cheers,
Jan

@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

@har Hi Har,

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

@MikeyH Hi Mike,

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

@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

Hi har,
Check if RexCore is running. I see that you are solving the Python code in another thread. It is possible that your code is not only causing the error, but also causing the entire RexCore to crash. Try connecting to the Raspberry via SSH and enter the command:

systemctl status rexcore

Cheers,
Jan