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

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

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

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

@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

@BailP Hello,
yes, there are REXYGEN packages (version 3) for Bookworm. Details are described here.

Cheers,
Jan

@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

@georgedumitru I think the best documentation is this thread here on the forum. Byte array reading from communication is also discussed there.

Another helpful tool is definitely the example located at C:\Program Files\REX Controls\REXYGEN 2.50.12.14711\Examples\0203_Function_Blocks_REXLANG.

Hi George,

Thanks for your question. You need to create a kind of state machine which basically does the following (one line = one task period):

Write() - send a read request to the device Read() - save received data and length into a global buffer/variable and distinguish if the received message is complete Retry and repeat Read() if the previously received message was not complete

You will need to introduce a timeout - it can happen that you lost some data so there should be some timeout when you say "Message incomplete, resend the read request".

Cheers,
Tomas

@hrabalo Hi,

Thanks for getting back to us. I'm glad it works for you now.

Good luck with your project.

Cheers, Tomas

@pancirm
Hello Michal,
as far as we know, no one implemented the eBUS in REXYGEN. However, implementation should be possible, for example, via eBUS <-> USB converter and REXLANG or Python programming block.

Cheers,
Jan

@belgacom You are welcome 🙂

Hi Toni,
FilterIdMask can be used for filtering messages from more devices. In your case, there is only one device, so you can set FilterIdMask as 0xfff. For message decomposing, use the INTSM blocks (www.rexygen.com/doc/ENGLISH/MANUALS/BRef/INTSM.html). The basic example of using INTSM block can be found in this thread: https://forum.rexygen.com/topic/174/reading-and-writing-4-byte-floating-point-from-modbus?_=1609251284153
For decomposing a byte value into bits can be used block BDOCT(www.rexygen.com/doc/ENGLISH/MANUALS/BRef/BDOCT.html).

Cheers,
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