Skip to content

Conversation

@jbysewski
Copy link
Contributor

This patch extracts common serial driver functionality into modbus-serial*.c/h and adds modbus-ascii upon this common serial driver. I was able to test the implementation against a chain of RS485/Modbus ASCII pressure sensors.

The setting of serial mode and rts is done via a forward to the modbus-serial module which keeps the current API but is not very clean IMHO.

Heads-up:
Some of the ascii implementation is based upon patches/pull-requests surrounding this project.

Google groups thread: https://groups.google.com/forum/#!topic/libmodbus/2A-ocabMhrE

@stephane stephane added the valid label Aug 4, 2015
@stephane
Copy link
Owner

stephane commented Aug 4, 2015

First review: good work!
I think a few 'switch/case' could be improved and we need to add tests and documentation.
I intend to work on it this month...

@stephane stephane mentioned this pull request Aug 27, 2015
@stephane stephane added this to the v3.4.0 milestone Oct 15, 2015
@AlexLonardi
Copy link

Hi,
we had stressed this patch and some minor bugs are emerged when the modbus interface is set as slave:

  1. Every reply misses of ':' at start, so we edited _modbus_ascii_build_response_basis as follows:
static int _modbus_ascii_build_response_basis(sft_t *sft, uint8_t *rsp)
{
  rsp[0] = ':';
  rsp[1] = sft->slave;
  rsp[2] = sft->function;

  return _MODBUS_ASCII_PRESET_RSP_LENGTH;
}

Redefining _MODBUS_ASCII_PRESET_RSP_LENGTH macro as follows

_MODBUS_ASCII_PRESET_RSP_LENGTH 3
  1. We'had got stored a float value of 8.86 in register, which translates to unsigned values (49807,16653), in hex (0xC28F,0x410D). When replying to a read register request, _modbus_ascii_send detects 0X0D as a '\r' character, skipping its translation to ascii. So, we've modified the code as follows, specializing the if statement:
static ssize_t _modbus_ascii_send(modbus_t *ctx, const uint8_t *req, int req_length)
{    
    uint8_t ascii_req[3 + (MODBUS_ASCII_MAX_ADU_LENGTH * 2)];
    ssize_t i, j = 0;

    for (i = 0; i < req_length; i++) {
        if ((i == 0 && req[i] == ':') ||
                ((i == req_length - 2) && (req[i] == '\r')) ||
                ((i == req_length - 1) && (req[i] == '\n')))
        {
            ascii_req[j++] = req[i];
        } else {
            ascii_req[j++] = nibble_to_hex_ascii(req[i] >> 4);
            ascii_req[j++] = nibble_to_hex_ascii(req[i] & 0x0f);
        }
    }
    ascii_req[j] = '\0';

    ssize_t size = _modbus_serial_send(ctx, ascii_req, j);
    return ((size - 3) / 2) +3;
}

@stephane stephane modified the milestones: v3.2.0, v3.4.0 May 11, 2016
@stephane stephane self-assigned this May 11, 2016
@stephane stephane modified the milestones: v3.4.0, v3.2.0 May 17, 2016
stephane added a commit that referenced this pull request May 17, 2016
Thanks to AlexLonardi.
@stephane
Copy link
Owner

Thank you @jbysewski and @AlexLonardi .

I created a new branch called https://github.com/stephane/libmodbus/tree/ascii-support to work on that, I need help to work on:

  1. https://github.com/stephane/libmodbus/blob/ascii-support/src/modbus-ascii.c#L211, I think MODBUS_MAX_ADU_LENGTH must depend on backend...
  2. many possible overflows
  3. run unit tests with success
  4. missing documentation for modbus_ascii_new (yes I intend to rename modbus_rtu_new too !)

stephane added a commit that referenced this pull request May 18, 2016
Thanks to AlexLonardi.
@ulimitedCoder
Copy link

I am looking to use the ascii-support in libmodbus. What is the current working status for the branch? Is it stable enough to work with?

@lyesba
Copy link

lyesba commented Apr 26, 2017

hi
thank you for i job
i want ,can i use the ASCII support with the libmodbus, if yes I would like to know how to add this ?
great regard

@yuanfanggo
Copy link

good job

@ghost
Copy link

ghost commented Mar 31, 2020

ascii-support branch has a double free bug in rtu mode, this line needs to be deleted,

free(ctx->backend_data);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants