News:

  • August 26, 2026, 02:38:32 AM

Login with username, password and session length

Author Topic: Modbus TCP Ascii Protocol  (Read 28036 times)

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3843
    • Host Engineering
Re: Modbus TCP Ascii Protocol
« Reply #15 on: August 10, 2018, 04:13:28 PM »
I found this on the Simply Modbus website:
1.  Add up all the data bytes in the message (before converting to ASCII and without the initial colon and final CR/LF).
2.  Throw away any bits that carry over 8 bits.
3.  Make the result negative (by twos compliment) to get the LRC byte.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6172
  • Yes Pinky, Do-more will control the world!
Re: Modbus TCP Ascii Protocol
« Reply #16 on: August 10, 2018, 04:15:47 PM »
Different LRC apparently. The one in the instruction is what Koyo uses in their serial protocols. The sum and invert is different.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2126
  • YKPAIHA
    • ATU, Inc.
Re: Modbus TCP Ascii Protocol
« Reply #17 on: August 10, 2018, 04:19:16 PM »
Maybe add a another choice for Modbus ASCII LRC and one for LRC Koyo?

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2126
  • YKPAIHA
    • ATU, Inc.
Re: Modbus TCP Ascii Protocol
« Reply #18 on: August 14, 2018, 10:43:47 AM »
Any possibility of adding the MODBUS LRC to the Checksum instruction?

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6172
  • Yes Pinky, Do-more will control the world!
Re: Modbus TCP Ascii Protocol
« Reply #19 on: August 14, 2018, 11:35:30 AM »
No time soon.

But I think it can already do what you need. Change to Checksum:8 and output to a signed byte LRC, then use MATH LRC = -LRC to do the two's complement.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2126
  • YKPAIHA
    • ATU, Inc.
Re: Modbus TCP Ascii Protocol
« Reply #20 on: August 14, 2018, 03:00:40 PM »
using the StreamIn instruction
When specifying a Data Buffer Block
Does it Store the data byte for byte received or characters received? For instance if I receive 1 byte containing 2 characters, does it store the 2 characters in separate bytes or 1 byte as it is received.  If you have the terminator characters unchecked, does it store those bytes or does it strip them out?
Here is the issue
When I receive the data into a Long String, I get 107 characters when I check to look for the termination Characters

When I uncheck that box and store it in a data buffer and wait for a timeout, the instruction receives 96 bytes and no sign of termination characters in the data block buffer. Just trying to make sense of what is going on. First time I am trying to write a protocol and it won't be the last.
« Last Edit: August 14, 2018, 04:40:07 PM by ATU »

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6172
  • Yes Pinky, Do-more will control the world!
Re: Modbus TCP Ascii Protocol
« Reply #21 on: August 14, 2018, 07:37:30 PM »
No conversions. Byte in, byte out. Terminators are stored as received, unless the strip option is specified.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2126
  • YKPAIHA
    • ATU, Inc.
Re: Modbus TCP Ascii Protocol
« Reply #22 on: August 14, 2018, 09:33:10 PM »
I finally got it to work with the string method. Seemed to be the best way to handle it. Read it into one large string and then parse out the data as sub=strings and then do the conversions.
BTW, the string to data conversion instructions saved me a ton of work. Nice job on those.
« Last Edit: August 15, 2018, 09:07:52 AM by ATU »