Emerson Exchange 365

• Not Answered

DeltaV/Modbus .CSV string Server to Client data upload

My company has developed a Win-IoT based instrument for use in the bio-process market to measure process output.  Each measurement result and supporting information is written to a line in a .csv file.  We are working on creating a background app that will upload the latest data segment to a DeltaV network.  We are considering using the Modbus protocol via TCP.  Our goal is to create the most "universal" data transfer style possible that can transmit a line of up to 82 ASCII characters. As this is our first foray into this market, we have a limited understanding of data types and conversion functions that exist and might be considered "standard". For reference, a new line of data would be available no sooner than 4 minutes after the last line of data.

Could the Modbus ASCII protocol be used to send a line of .csv data directly?  Everything I have read suggests that the Modbus RTU protocol is preferable to the Modbus ASCII protocol.  One option we are looking at would be to use the onboard app to convert the ASCII characters to their HEX values, and use the first 41 Input Registers to transmit the HEX encoded ASCII data.   Is there a function that can be used on the Client side to convert the HEX values back to ASCII characters for data storage?  Is there an even better way?

For full disclosure, I also posted a similar question on the Life Sciences forum before I found this forum.

Thank you for your time and consideration.

John Barnacle

John Barnacle

• 7 Jan 2021 6:01 PM
• Cancel

5 Replies

• Andre Dicaire

  

  • 7 Jan 2021 6:23 PM

  I would suggest you develop for OPC UA. Serial busses like Modbus ASCI and RTU are generally being replaced by Modbus TCP, with bridges providing continued support for existing installations of these serial protocols. Although Modbus is pretty ubiquitous, it requires mapping, which means the data loses context. An OPC UA interface would align more with the IIoT digital transformation age. Exposing the data with a browsable name space would be a much better intuitive solution. Also, OPC UA brings more options for secure data transfer, supporting security certificates and encryption.
  
  Of course, having both allows you better access to market.

  Andre Dicaire

  • Cancel
• John Barnacle

  

  • 11 Jan 2021 7:34 PM

  In reply to Andre Dicaire:

  Hello Andre,
  Thank you for your reply. We did look at the possibility of utilizing an OPC UA interface, but the initial research suggested that Modbus is still more universally adopted at this point, and budgetary reasons require us to focus on a single solution in the short run. While the Modbus connection will be via a LAN port and TCP, the formatting of the actual data to be transmitted is where we could use advice. The intent of the string transmission from our instrument is to export the data, in the form of a line of CSV (comma separated values) ASCII characters from the most recent instrument measurement for storage at the Client level. As we develop the application that would reside on the instrument to facilitate said transmission, we are looking for the optimal format for the transmission and the typical way to provide "decoding" instructions for the Client side. Any advice would be appreciated.

  • Cancel
• Andre Dicaire

  

  • 11 Jan 2021 11:22 PM

  In reply to John Barnacle:

  The challenge with MODBUS is that it was not designed for text. The Holding registers are basically 16 bit integers which can form signed or unsigned values as 16 bit o r32 bit words or as floating point numbers. These can be interpreted as strings but not all clients do so natively.
  
  I think you also have to be clear on the character set you are supporting so the bytes that represent them can be read correctly. You will end up with two bytes of data per 16 bit holding register, and each Byte represents a character. To read the string, one has to read know which registers contain a given string and assemble the string by reading these registers/bytes in the proper order.
  
  Also note that not all Modbus TCP clients support the entire Holding Register map. Some still use 49999 as the maximum addressable register, which was common when Modbus was younger. Staying below this limit would ensure your product can be deployed everywhere.

  Andre Dicaire

  • Cancel
• John Barnacle

  

  • 12 Jan 2021 7:53 PM

  In reply to Andre Dicaire:

  We did recognize the fact that Modbus is geared towards numeric data, which is what led us to consider using HEX encoded ASCII. There are a total of six fields in the data. The CSV structure of the line of data controls the field assignments of the data within the string. The instrument control software limits the possible characters to those in the ASCII set, and also limits the maximum length of the string (commas included) to 82 characters. It would seem that we could transmit, with a maximum of 41 registers, a HEX representation of the CSV string in the same order as it is saved in the Server (instrument) data file. For strings that don't use the maximum characters in each field, a NUL character would terminate the overall string. Is this something that could easily be converted from the transmitted HEX back to ASCII on the Client side?
  Thanks,
  John Barnacle

  • Cancel
• AdrianOffield

  

  • 14 Jan 2021 9:06 AM

  In reply to John Barnacle:

  I did something similar for transmitting GPS coordinates via Lorawan network, GPS coordinates obtained as string from GPS module, then sent via a 20byte packet to a UDP port on a server. GPS coordinates were given as string rather than FP.
  
  If your data is serialized, why not just present data in holding registers, every 4 minutes that data refreshes, you an even present floating point values.
  
  Alternatively, have you looked at Node-RED, its a interface I've used before in IOT projects to manipulate outputs into other formats. Might be useful in this instance.

  • Cancel