Modbus Slave Example UART Event Queue Full

[Nikostpn]

Hi all,

I'm working with this example with ESP-IDF V4.3.2:
https://github.com/espressif/esp-idf/tr ... l/mb_slave

I have the Modbus slave running as one of my threads. When I interlace with a test program, I get the following:

When I try to get my slave polled at 10 Hz (100 ms), I get a UART event queue full, which I don't know how to clear.

I've modified the example by separating the initialization functions and the code running functions, which I've put into their own "Modbus_start()" function, which is what gets passed into the xTaskCreate function.

Code: Select all

if(event & (MB_EVENT_HOLDING_REG_WR | MB_EVENT_HOLDING_REG_RD))
        {
            // Get parameter information from parameter queue
            ESP_ERROR_CHECK(mbc_slave_get_param_info(&reg_info, MB_PAR_INFO_GET_TOUT));

            ESP_LOGI(SLAVE_TAG, "HOLDING %s (%u us), ADDR:%u, TYPE:%u, INST_ADDR:0x%.4x, SIZE:%u",
                    rw_str,
                    (uint32_t)reg_info.time_stamp,
                    (uint32_t)reg_info.mb_offset,
                    (uint32_t)reg_info.type,
                    (uint32_t)reg_info.address,
                    (uint32_t)reg_info.size);
        }

What are some ways to avoid the UART event queue full or clear it, and how can I make sure my Modbus device gets the data from the ESP32, as it is critical to the application?

Thank you!

[ESP_alisitsyn]

Hi @Nikostpn ,

> I've modified the example by separating the initialization functions and the code running functions, which I've put into their own "Modbus_start()" function, which is what gets passed into the xTaskCreate function.

Unfortunately, you didn't provide enough information and changed the code to recognize the problem. Now I can just guess.
If in your code you check just the condition below but if your master reads/writes other registers the Modbus register info queue will be full because you do not get data from this queue.

Code: Select all

if(event & (MB_EVENT_HOLDING_REG_WR | MB_EVENT_HOLDING_REG_RD))

Please filter all possible flags in your code as provided in the example. Please provide more information that would help to confirm your issue.

[Nikostpn]

Hi @ESP_alisitsyn,

Sorry for the late reply!

The problem went away after the MB master code was configured to poll all the holding registers (the only registers used in the application) as needed; the problem was due to the fact master had to read and write to separate (holding) registers really fast. Do you think that would cause the issue that I was seeing?

If so, I'm still wondering, because looking through the available ESP code, I don't know how to access the UART queue, as it seems to be abstracted away. I wanted to know more about that data structure if I'd have to dig deeper.

Thank you!

[ESP_alisitsyn]

Hi @Nikostpn,

Thank you for your answer.

It is strange that you see the UART queue full. Do you have other tasks with a priority higher than Modbus kconfig value CONFIG_FMB_PORT_TASK_PRIO? What is the priority of the task which is running the Modbus read/write functions? The UART queue full may happen if the UART task does not process the events on time https://github.com/espressif/esp-idf/bl ... ial.c#L124. The kconfig value CONFIG_FMB_PORT_TASK_AFFINITY can change the CPU on which the Modbus tasks are running if you have other tasks and help to solve issues. Please try to experiment with the priorities and let me know the results. Unfortunately, I do not see the whole picture of your problem. Are you able to read and write registers using standard slave example with your master https://github.com/espressif/esp-idf/tr ... l/mb_slave?
Does it work the same way with your master?

the problem was due to the fact master had to read and write to separate (holding) registers really fast. Do you think that would cause the issue that I was seeing?

Yes, this may be a reason. In case your master has been configured with the small slave response time but the slave can not read and process requests and send responses during the master respond timeout. So, the master sends the next request while the previous one is still pending. Please try to play with the priorities of the tasks. What is the slave response timeout configured in your master?

I will try to check this and am waiting for information from you.

Thanks.

[Nikostpn]

Hi ESP_alisitsyn,

I've never replied, but the issue was resolved by using an appropriate Modbus handler. and library The original issue came from interfacing with a LabVIEW program, which (if I remember correctly) would poll the registers directly without using a Modbus interface (that is, just send the bytes corresponding to what the request would look like over the serial line), and thus most likely not using appropriate timings and so on. It was a pain, but we decided to actually sit down and find an appropriate library and everything worked fine with some fine-tuning once we did.

[ESP_alisitsyn]

Hi Nikostpn,

Thank you for your feedback. I did not catch exactly if you updated the LabVIEW library to work with Modbus or just decided to use other Modbus library on the application side. Any way the good thing is that your issue is solved. Good luck!

[Nikostpn]

ESP_alisitsyn,

Thank you! The Modbus library was for the LabVIEW side; the ESP stuff worked fine.