Modbus RTU Master stops working when client connects to SoftAP (IDFGH-9849)

[dfun90]

ESP Chip: ESP32-WROOM ESP-IDF Version: 4.4.4 Freemodbus Version: 1.0.10

Hey. I'm running into an issue using the modbus component. Before I describe the problem in itself, I must say that the setup for the modbus master I'm using is a bit of an unique case. There are 4 modbus slave devices connected to the ESP32 over RS485 with a CD4052 multiplexer inbetween, because those modbus devices somehow don't have a way to change their Slave IDs. The program switches through the channels of the CD4052 multiplexer to communicate with each of those modbus slave devices. (Channel switching is done by setting the A & B pins on the CD4052 multiplexer to HIGH or low)

The pin configuration is as following:

UART_NUM_1
TX -> GPIO_NUM_18, RX -> GPIO_NUM_19
A Channel -> GPIO_NUM_22, B Channel -> GPIO_NUM_21

This in itself works as intended, each different modbus slave device can be read out. Now to the problem(s) itself:

1. Whenever a client connects to the ESP32's WiFi SoftAP, a few seconds later the modbus communication (or underlying UART connection) stops working

• Current "workaround": Destroy and re-init the modbus master - while this works, it's not really a solution, since the data gets read in a fast interval and several seconds of no data would be noticeable

2. The same behavior starts to happen irregularly, even without any clients connected to the WiFi SoftAP - not reliably re-producable, but it might be related to the issue itself - in the worst case even a destroy and re-init of the modbus master doesn't work here

The console output whenever the problem happens is as following:

MB_CONTROLLER_MASTER: mbc_master_get_parameter(76): Master get parameter failure, error=(0x108) (ESP_ERR_INVALID_RESPONSE).
MB_CONTROLLER_MASTER: mbc_master_get_parameter(76): Master get parameter failure, error=(0x107) (ESP_ERR_TIMEOUT).

While the occasional ESP_ERR_INVALID_RESPONSE or rather ESP_ERR_TIMEOUT is something I wouldn't be concerned with, the amount it happens under these circumstances is too much.

The other tasks running besides this on the ESP32 are as following:

• SD-Card reader via SPI (Pins: MOSI 13, MISO 5, CLK 14, CS 15) and a task to check if the VFS is ready (CPU 1)
• Another device connected via UART (external bluetooth module, Pins: UART_NUM_2, TX 16, RX 17, 27 and 26) with an event task and task to send data (CPU1)
• Task to read ADC1 channels (CPU 0)
• WiFi SoftAP + STA
• HTTP + Websocket Server + task to send messages to a connected client via WS

I have already tried playing around with the task priorities, giving the modbus master a higher priority, but it doesn't change anything in the behavior. Also tried different sdkconfig settings regarding the modbus component, but nothing helped. These are the current settings related to modbus:

CONFIG_MB_MASTER_TIMEOUT_MS_RESPOND=150
CONFIG_MB_MASTER_DELAY_MS_CONVERT=200
CONFIG_MB_QUEUE_LENGTH=4
CONFIG_MB_SERIAL_TASK_STACK_SIZE=4096
CONFIG_MB_SERIAL_BUF_SIZE=256
CONFIG_MB_SERIAL_TASK_PRIO=23
# CONFIG_MB_CONTROLLER_SLAVE_ID_SUPPORT is not set
CONFIG_MB_CONTROLLER_NOTIFY_TIMEOUT=10
CONFIG_MB_CONTROLLER_NOTIFY_QUEUE_SIZE=8
CONFIG_MB_CONTROLLER_STACK_SIZE=4096
CONFIG_MB_EVENT_QUEUE_TIMEOUT=10
# CONFIG_MB_TIMER_PORT_ENABLED is not set

I've gone ahead and attached the log output from when the problem happens, the related code snippets for the modbus and a simple schematic of how it's all connected together. I'm not sure if this is a problem with the modbus component itself, the use of a multiplexer or just some rookie mistake on my end, but I'm at the end of thinking what else I could try.

Any help on this would be great, thanks! Please let me know if you need any further information.

Log The Code Snippet Schematic

[alisitsyn]

Hello @dfun90,

Thank you for this issue. Yes, your use case of Modbus is unique. I would like to start with some aspects of communication: First of all the Modbus has some deterministic aspects related to slave response time FMB_MASTER_TIMEOUT_MS_RESPOND. The master sends the request and waits slave response during this time and then returns the ESP_ERR_TIMEOUT if the response did not come from slave.

Thank you for provided information, it is not enough to see full picture of your project but I can see some aspects of incorrect configuration of Modbus. Below are my comments to start with:

1. Your slaves response time can be > 200 ms as per your log:

   I (16565) cd4052_switch_channel: Channel 2 selected (A=0, B=1)
   I (16772) modbus_master_read_slaves: (CH2) SN 2210 temperature: 220 - json: [220]
   I (16774) modbus_master_read_slaves: (CH2) Data [220] added to sensor_collection for ID: RSPRO2

   but the CONFIG_MB_MASTER_TIMEOUT_MS_RESPOND is set by default to 150 ms. This configuration even works when you do not start your other services but it as expected fails when the services start working. I propose to change this time to maximum slave response time + switch time.

2. The Modbus use the esp-timer to trigger response timeout. Its task priority is 22, but CONFIG_MB_SERIAL_TASK_PRIO = 23 (maximum) that can prevent esp-timer to work properly. You need to decrease the priority to something like 10 (need to check your other task priority and play with this.

3. The "WiFi SoftAP + STA, HTTP + Websocket Server" use the high priority tasks of Wifi driver and LWIP and do intensive work that applies to normal flow of modbus tasks that does impossible to process the data from your slaves + due to short response time.

   MB_CONTROLLER_MASTER: mbc_master_get_parameter(76): Master get parameter failure, error=(0x107) (ESP_ERR_TIMEOUT).

4. The FMB_PORT_TASK_AFFINITY can be helpfull and allows starting WiFi related tasks on one CPU and the Modbus tasks and your other lower priority tasks on other CPU. By default, the WiFi tasks are running on CORE0 with the Modbus tasks and this prevents Modbus to work properly. See the Built-In Task Priorities. For example, changing the FMB_PORT_TASK_AFFINITY to CPU1 can help to solve issue. See the Modbus issues and solutions section

5. I think it is better to add the pull up to RXD pin of ESP32 connected to CD4052 to avoid possible slave switching issues.

Please try to follow the above recommendations and let me know the results. Thanks.

[alisitsyn]

Hello @dfun90,

Could you share some update for this issue? Thanks.

[alisitsyn]

Hello @dfun90,

The issue will be closed. Feel free to reopen.