@AlexanderH Hi Alexander,

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

@AlexanderH Hi Alexander,

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

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.

Hi @gninaus,

With version 3.0, REXYGEN introduced a new licensing policy. You can find the details here:
https://eshop.rexcontrols.com/pages/licensing-policy

Could you please send us your license information at support@rexygen.com?
You can find the license info via REXYGEN Studio by using the menu Target -> Connect and then again Target -> Licensing.

Also, please attach the REXYGEN Studio Compiler output related to licensing. Here’s an example:

This will help us identify what part of the configuration requires a higher license and provide further guidance.

Cheers,
Jan

@MikeyH Hi Mike,

It's a duplicate of this one: https://forum.rexygen.com/post/1707 - check the project timing.

Cheers,
Tomas

@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

@AlexanderH Hi Alexander,
do you see any error messages in the system log? If so, what kind?

Does setting the outputs work as expected?

When reading inputs, I think you should both write and read within the same I2C() call — in other words, both counters should be non-zero. Usually, sending a request and receiving a response over I²C takes much less time than the REXYGEN task execution period. That’s why the I2C() function is designed to send data and, if a response is expected, receive it within the same cycle. I don’t know the exact details of the PCF8574A protocol, but I would assume that you need to perform the write and the read together in one call.

By the way, the code you pasted looks a bit broken here on the forum – that’s probably due to Markdown formatting. Please enclose the entire script in a code block using triple backticks (```) or upload it here as a text file. That way it will be much easier to read.

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).

Cheers,
Jan