Author Topic: Modbus/TCP Errors on the Nano  (Read 7042 times)

sebraun

  • Newbie
  • Posts: 4
  • Nothing so needs reforming as other peoples habits
    • View Profile
Modbus/TCP Errors on the Nano
« on: September 28, 2015, 07:53:10 AM »
I am using the Nano as a Modbus/TCP client to an Acromag analog input module.  Briefly, I open the channel, leave it open forever, and read two 16 bit registers.  I count the number of failures by evaluating the S2 and S3 status bits.  If STATUS(2) is zero, I count a no-response and if STATUS(3) is zero, I have to close the port and re-open.  If I trigger the read command every second, the number of failures over a 24 hour period is 300+ for both STATUS.  If I trigger the read command on a less frequent basis, every two seconds for instance, the numbers of failures drop to 3 or 4 each every 24 hours on both STATUS bits.
My questions: Why should I experience any failures at all?  Is there a way to issue a read command knowing that all the hardware is ready to go?
I need to query at one second intervals because I am performing Coulomb calculations. I have tested the Acromag analog module with another Modbus/TCP client and it will respond to the same query in considerably less than one second with zero failures.   As well, I cannot add any additional TCP modules until I know how to precisely time them.  I have extensively reviewed the example code supplied with i-Trilogy and there is really no substance there.

support

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3171
    • View Profile
    • Internet Programmable PLCs
Re:Modbus/TCP Errors on the Nano
« Reply #1 on: September 28, 2015, 11:51:35 AM »
When you execute a READMODBUS command the system check the response packet from the server and if it does not receive the packet within a certain time-out period or if it detects a checksum error,  it will report an error via STATUS(2). The program can then issue another READMODBUS command to resend the command and if the communication link is good it should be able to get a good data.

In any communication system it is impossible to guarantee perfect communication with zero errors, especially when it involves packet switching network. So it is therefore necessary to check the integrity of communication and use the result only if the data is good.  The PLC firmware handles multiple background tasks with a single core CPU at relatively slow speed and the Ethernet communication is but one of the many functions it need to handle, so t does as best as it could to minimize the chances of lost packets.  A dedicated Modbus client device or a multi-core PC with GHz CPU and GigaBit Ethernet interface running Modbus TCP client are very different setup from the PLC and is not a one-to-one comparison.
 
Email: support@triplc.com
Tel: 1-877-TRI-PLCS

support

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3171
    • View Profile
    • Internet Programmable PLCs
Re:Modbus/TCP Errors on the Nano
« Reply #2 on: October 16, 2015, 06:40:03 AM »
Our Engineering team has worked on the Modbus TCP client function (i.e. for the PLC to connect to another Modbus TCP server such as Acromag module that you have used) specifically to reduce the error rate and believe we have made good progress.

If your FMD or Nano-10 PLC firmware version is >= r83 you can upgrade the firmware using a special Upgrader software that runs on a Window PC. If you wish to obtain the Upgrader software to test the new firmware please email support@triplc.com and provide your purchase record (a scanned or PDF copy of a past invoice or receipt from TRi or its distributors) and we will provide you with the download instructions.  We would also appreciate if you could provide a brief description of a problem you may have, or just a brief description of your application and the TRi PLC models that you are using.

Email: support@triplc.com
Tel: 1-877-TRI-PLCS