@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

Dear Jan, thank you for this quick reply. In the coming days I will send an email to the supplied email address. To be continued.

Greetings,
Alex

we discussed the I2C communication details with the developers and both continuous reading and using multiple I2C commands within a single task cycle should be possible in your use case.

Unfortunately, there is no MCP342x device available on my side right now, but I will try to get one so the behavior can be reproduced and tested. In the meantime, could you please send a minimal version of your project, either here on the forum or to support@rexygen.com? That will make it much easier to see what is going on in your specific setup and suggest a concrete solution.

Cheers,
Jan

Great to see you experimenting with REXYGEN and getting good results so far! It’s nice that you started from the example library — that’s definitely the right approach. The I2C function in REXYGEN works a bit differently compared to Arduino or other low-level implementations. Since REXYGEN tasks usually don’t run with very short cycle times, a single I2C call performs both write and read operations within one cycle. This command takes care of sending the message, waiting briefly, and then reading the response. That means you don’t need to manually handle the NAK or stop condition — the function itself takes care of it.

I looked through your code and have a few notes that might help:

• I noticed that right after calculating channel1, you have a return 0;. Because of that, the code for channel2 never runs — I guess that’s just for debugging, but it’s worth pointing out.
• In each REXYGEN cycle, you currently configure the converter for continuous read mode. This might not behave as you expect, and it’s probably unnecessary. Try switching to one-shot mode first and see what kind of values you get. Later, you can set continuous mode once, and then in your main() you can just read the data by setting i2c_write_count = 0. That way, the I2C function won’t send any configuration bytes, it will only read — according to the documentation, that should work.
• You can use the Trace() function to print out the value of i2c_ret_fun for debugging. Keep in mind that you need to enable these messages in the system log:
  Go to Target → Diagnostic messages, tick Information in Function block messages, and make sure Enable logging is checked in the Options tab of the block properties dialog. Only then you’ll see the messages in the System log.
• And finally, double-check the I2C address of the MCP3424 — it’s configurable, so make sure it matches your hardware setup.

Hope this helps you move forward! Please let us know how it goes — it’s always interesting to see REXLANG + I2C projects in action.

Cheers,
Jan