Page 1 of 1
Re: master esp idf 4.2 Characteristic read fail error
Posted: Wed Jul 29, 2020 4:07 pm
by alllllllllllllllllll
Hi everyone, I'm testing the master implementation released in v4.2. Unfortunately, I'm unable to read a register of the slave device; as a result, I obtain a timeout error. Is there someone who know how to solve the problem?
Re: master esp idf 4.2 Characteristic read fail error
Posted: Thu Jul 30, 2020 6:31 am
by ESP_alisitsyn
Hi alllllllllllllllllll,
The esp_idf v4.2 is able to read and write Modbus data. The ESP_ERR_TIMEOUT means slave was not able to respond during timeout.
Please check:
1. Your serial connection using RS485_echo example.
2. Enable CONFIG_FMB_TIMER_ISR_IN_IRAM to avoid serial hendler delays if you use NVS flash functions.
CONFIG_FMB_TIMER_PORT_ENABLED should be disabled to avoid failures when you have other tasks started on the same CPU. This increases delays of MB processing but allows to decrease issues in your application.
CONFIG_FMB_SERIAL_TASK_PRIO - should be set to your (highest task priority + 1) executed on the same CPU.
3. In some cases when WiFi coexist with Modbus it is still possible to get errors. I propose to retry modbus request in this case.
If the above does not help please send me your sdkconfig and project to reproduce issue.
Re: master esp idf 4.2 Characteristic read fail error
Posted: Fri Jul 31, 2020 7:41 am
by alllllllllllllllllll
Hi ESP_alisitsyn, yesterday I solved the problem by changing the type of data in the CID description (from float to uint8).
I'm not completely sure that this was the source of the problem, however now it seems to work (it store the temperature value in the "value")
Re: master esp idf 4.2 Characteristic read fail error
Posted: Mon Aug 03, 2020 7:41 am
by alllllllllllllllllll
Hi ESP_alisitsyn, regarding the point 3, what do you suggest when both Wfi and Modbus communication must run at the same time for the purpose of the project ?
Re: master esp idf 4.2 Characteristic read fail error
Posted: Tue Aug 04, 2020 8:58 am
by ESP_alisitsyn
Hi alllllllllllllllllll,
The modbus component was designed to work with UART driver and using FreeRtos API and active objects instead of interrupts. The wifi related tasks or tasks which access NVS memory may suspend the serial tasks in modbus stack and delay processsing in this case the timeout error is expected behavior. In previous post described the kconfig options that should be taken into account when modbus coexists with Wifi tasks and they should help in this case. In order to increase reliability in this case propose to do retry when stack returns timeout error. Something like this:
Code: Select all
err == ESP_ERR_TIMEOUT;
for (int retry = 0; (retry < MB_MAX_RETRY) && (err != ESP_OK); retry++) {
err = mbc_master_get_parameter(cid, (char*)param_descriptor->param_key,
(uint8_t*)&value, &type);
}
Also root reason of your issue may be the configuration of Modbus host software used on your side. It is very usual problem as well as interface connection. Try to use slave example to communicate with your master or I would propose the ModbusPoll host software to check Modbus errors.
Also please check the simple_modbus code sent you before to simply read/write registers instead of mapping parameters.