Add support to function 17 (0x11) Report Slave ID (IDFGH-13856)

[ezamp]

Checklist

• [X] Checked the issue tracker for similar issues to ensure this is not a duplicate.
• [X] Described the feature in detail and justified the reason for the request.
• [X] Provided specific use cases and examples.

Feature description

Add support for function 17 (0x11) to the _mbc_master_send_request()_ function.

Use cases

It is often necessary to read the information that the device manufacturer makes available through the Device Information

Alternatives

No response

Additional context

No response

[alisitsyn]

@ezamp,

Thanks for request. The function 0x11 Report Slave ID (Serial Line only) is supported by Master and slave. However, the serial master does not send the request for this command. This command is vendor specific and includes some vendor specific context that suppose some options of realization in user application instead of default stack implementation. I would advice you to implement it on your side. I can explain the way on how to implement this. Will this work for your project?

[ezamp]

When do you plan to release? If you need help testing it, I'm available. Thanks

[alisitsyn]

I will try to do the guide as soon as possible once I have a chance to switch to this. This will need to apply the change to the stack on your side. I will let you know soon. Do you need to use this for Master or Slave implementation or for both?

[ezamp]

I need this only for master

[alisitsyn]

@ezamp ,

The update is below. The master is able to send the 0x17 command and get response using the mbc_master_send_request() function. I did not have time to adequately test this yet. Please try and report any issues observed. Let me know if you have any issues to patch the component (options are possible).

    mb_param_request_t req = {0};

    uint8_t info_buf[64] = {0}; // byte buffer to save the response from slave (spare bytes added).

    // Command - 17 (0x11) Report Slave ID (Serial Line only)
    req.command = 0x11; // The command get slave info
    // The command contains vendor specific data.
    // This version of command handler needs to define expected number of registers 
    // that will be returned from concrete slave (is not standardized).
    // The returned slave info data will be stored in the `info_buf` with expected number of registers.
    // The handler uses the standard callback function to read input registers.
    req.reg_size = 16;
    // This example will requires the slave info from slave UID = 1.
    // It can be modified accordingly for other slaves.
    req.slave_addr = 0x01;

    err = mbc_master_send_request(&req, &info_buf[0]);

master support for 17 (0x11) Report Slave ID command.

[ezamp]

Thank you for the commit. The request is sent and the master receives the response. I have some doubts about the register size (reg_size) I need to enter in the request, from the log I can see that the master responds with 59 bytes. I always get the error “ESP_ERR_INVALID_RESPONSE,” probably because I entered the wrong size.

Log: D (5503) MB_PORT_COMMON: xMBMasterRunResTake:Take MB resource (500 ticks). D (5513) MB_PORT_COMMON: xMBMasterRunResTake:Take MB resource (500 ticks). D (5523) MB_PORT_COMMON: 4856483:EV_MASTER_FRAME_TRANSMIT D (5523) POLL transmit buffer: 11 D (5533) MB_PORT_COMMON: eMBMasterRTUSend: Port enter critical. D (5533) MB_PORT_COMMON: eMBMasterRTUSend: Port exit critical D (5543) MB_PORT_COMMON: xMBMasterPortSerialSendRequest default D (5543) MB_PORT_COMMON: vMBMasterPortTimersRespondTimeoutEnable Respond enable timeout. D (5553) MB_MASTER_SERIAL: MB_TX_buffer sent: (5) bytes. D (5563) MB_PORT_COMMON: vMBMasterRxSemaRelease:RX semaphore is free. D (5563) MB_PORT_COMMON: 4856483:EV_MASTER_FRAME_SENT D (5573) POLL sent buffer: 11 D (5593) MB_PORT_COMMON: xMBPortSerialWaitEvent, UART event: 0 D (5593) MB_MASTER_SERIAL: MB_uart[2] event: D (5593) MB_MASTER_SERIAL: Data event, len: 62. D (5603) MB_MASTER_SERIAL: Received data: 63(bytes in buffer) D (5603) MB_MASTER_SERIAL: Timeout occured, processed: 63 bytes D (5613) MB_PORT_COMMON: 4856483:EV_MASTER_FRAME_RECEIVED D (5613) MB_PORT_COMMON: xMBMasterPortSerialGetResponse default D (5623) MB_PORT_COMMON: eMBMasterRTUReceive: Port enter critical. D (5623) MB_PORT_COMMON: eMBMasterRTUReceive: Port exit critical D (5633) MB_PORT_COMMON: 4856483: Packet data received successfully (0). D (5643) POLL receive buffer: 11 39 01 04 03 24 ff 04 0b 00 0a 30 30 30 30 30 D (5643) POLL receive buffer: 31 30 34 30 33 32 34 32 34 30 34 32 32 30 30 30 D (5653) POLL receive buffer: 32 37 33 00 00 00 00 00 00 00 00 00 00 00 00 00 D (5663) POLL receive buffer: 00 00 00 00 00 00 00 00 00 00 00 D (5663) MB_PORT_COMMON: 4856483:EV_MASTER_EXECUTE D (5673) MB_PORT_COMMON: 4856483:EV_MASTER_ERROR_PROCESS D (5683) MB_PORT_COMMON: vMBMasterErrorCBExecuteFunction:Callback execute data handler failure. D (5683) MB_PORT_COMMON: Transaction (4856483), processing time(us) = 152365 D (5693) MB_PORT_COMMON: eMBMasterWaitRequestFinish: returned event = 0x400 E (5703) MB_CONTROLLER_MASTER: mbc_master_send_request(94): Master send request failure error=(0x108) (ESP_ERR_INVALID_RESPONSE).

[alisitsyn]

Thanks for feedback. Yes, the error seems appear because of incorrect size of response. I did use the input registers mapping callback function because there is pros of this for later implementation. I got your point and it worth to change it using its own mapping. Unfortunately, I have some other high priority work for now and can not spend time for this. Could you wait some time or otherwise could you be able to update the handler function to use just bytes count in the response to map them to output data. The change is very simple.