modbus_read_registers returns -1, error= No Error

[Matthew Brown]

I've had intermittent errors on modbus_read_registers 

I'm reading just one register, and intermittently it returns -1  

   mb = modbus_new_tcp(ipAddr_.c_str(), port_);

    if (mb == NULL){ return false; }

    if (0 == modbus_connect(mb)){

      modbus_set_response_timeout(mb, 4, 0);

      initialized = true;

      return true;

    }

    return false;

  const unsigned INPUT_REG = 512;

  uint16_t inputs = 0;

  int ok = modbus_read_registers(mb, INPUT_REG, 1, &inputs);

  if (ok != 1){

    std::cout << "Error reading " << std::endl;

  }

  std::cout << "Read " << inputs << std::endl;

  int bitmask_ = 8;

  uint16_t bitsToSet = inputs;

  // toggle bit

  if (bitsToSet& bitmask_){

    bitsToSet &= ~bitmask_;

  }

  else{

    bitsToSet |= bitmask_;

  }

  const unsigned OUTPUT_REG = 512;

  ok = modbus_write_registers(mb, OUTPUT_REG, 1, &bitsToSet);

  if (ok != 1){

    std::cout << "Error writing " << std::endl;

  }

I've stepped into the code when this occurs.  modbus_read_registers calls read_registers, which calls send_msg, which calls

 rc = ctx->backend->send(ctx, msg, msg_length);

This send returns -1

Inside send_msg the error number is 0, "no error"

This happens with several similar, brand new, devices (digital input modules by Wago, Turk, and SMC)

OS= Win7

libmodbus 3.1.2

I can't step into send, so don't know what conditions it would return a -1 

Just before this I was also getting an intermittent "bad file descriptor".  I had to increase modbus_set_response_timeout to as much as 4 seconds to make this (largely) go away.

So, can anyone show me documentation for modbus_read_registers that indicates what a -1 return value means, with errno= 0 ?  

Of course, I'd like to make it go away.

[Stéphane Raimbault]

I don't understand why so many people ask me for the documentation (available as man pages too: man libmodbus, man modbus_get_byte_timeout, etc)

http://libmodbus.org/docs/v3.1.2/ (linked from libmodbus.org).

What I can do to improve the visibility of the docs?

Stéhane

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "libmodbus".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse libmodbus+...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Matthew Brown]

I was being too subtle.  Yes, of course I've seen the documentation.  It says that modbus_read_registers (only) returns error EMBMDATA, which is not true in this case.  No where in the documentation does it say what a return value of -1 is, nor what it means when it returns -1 and errno = 0.  There are several places in the code where it explicitly returns -1, yet this behavior is undocumented.  In this case, I think a lower level function is returning -1 (I can't step into it right now in VS), and modbus_read_registers is just passing it along.

Don't get me wrong -- this is a great piece of code and I am not ungrateful.  I was hoping that someone else had documented this behavior.

Meanwhile, can you help me fix this?   It is becoming a blocker, since it appears to my team that libmodbus is unreliable.

Merci

=Matt

[Matthew Brown]

One other piece of information: whenever this error occurs, all subsequent attempts to read instantly return the same -1 with errno=0.  Restarting the program clears it.

[Matthew Brown]

Well, I've done a cold boot and set error recovery to MODBUS_ERROR_RECOVERY_PROTOCOL now it is consistently Bad File Descriptor.

Could someone explain what that is in this (TCP) context?

[Stéphane Raimbault]

I codes under Linux and OS X so the documentation of errors is right for these OS but not for windows.

I hate Windows so I need help to improve the support of Windows on this OS.

There are a few PR and issues on the subject you could look at:

https://github.com/stephane/libmodbus/pull/128 

[Stéphane Raimbault]

May be the socket has just been closed on server.

Could you describe your set up and paste useful parts of your code, please?

[Matthew Brown]

That's what it appears to be.  Don't know why.  Reopening the socket seems to work.  Code is, as above, with a loop calling it repeatedly.