Add support to function 17 (0x11) Report Slave ID (IDFGH-13856) #76
Comments
github-actions
bot
changed the title
|
Thanks for request. The function |
|
When do you plan to release? |
|
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? |
|
I need this only for master |
|
@ezamp , The update is below. The master is able to send the 0x17 command and get response using the 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]); |
|
Thank you for the commit. Log: |
|
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. |
|
Thanks for the support. I made the following change in the eMBMasterFuncReportSlaveID function: I'm noticing a problem when I run two requests in sequence, specifically: It seems that the 9 bytes received with the first request are considered for as RX for the second request. Log: |
|
Sorry for the long delay with answer.
The change is incorrect here. The callback function take the number of registers instead.
It seems the response to this command is processed with error then the input FIFO is cleared before further processing. The length of the response looks correct also. The I will update implementation soon and will test it. UPDATE is in progress |
|
Could you send me the device manual or description of this command from your device manual? I see your response and can just guess now. This is the vendor specific part with 3 byte device ID and the number saved as string. |
|
ModBus 0x11.xlsx |
|
Could you check the update with your device? This should work just fine now with the limitation of only even number of bytes (Registers) are mapped into the value buffer. If you need the whole buffer this can be done using the custom vMBMasterErrorCBUserHandler handler. |
|
I did a test with my device and now I can read the response bytes correctly. Log command 0x11: |
Thanks for the update. The issue with two commands in sequence will be fixed as ASAP. I also will need your test. |
|
Thanks. |
Yes, sure, this size can be defined in the kconfig actually. I missed this initially and left as it was. This will be updated as soon as I complete some other work. |
|
The bytes I read are not in the sequence indicated by the manufacturer. Each byte pair (uint16) is represented in little endian. For example: In the log below you can see the “swaps” of positions: |
|
Ah, I see and was expecting this as per your log but it is really vendor specific things. I can do this different way but I think it will not satisfy the specification because all the data in the frame satisfy network format of big-endian. It might be safer to take buffer of the command and process it as required for your device. I will make a decision on how to implement it and will do a bit later. |
Checklist
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
The text was updated successfully, but these errors were encountered: