Announcement

Collapse
No announcement yet.

General MODBUS functionality within Do-More

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts


  • General MODBUS functionality within Do-More

    Hello,

    I have a Direct Logic 205 with a H2-DM1E CPU. I am interested in using a HMI that communicates using MODBUS RTU. So I would setup the CPU with MODBUS RTU Server (Slave) enabled on the RS-232 Serial port. Reading through the help files it looks like any MODBUS communication must go through the MI, MC, MIR, and MHR memory blocks. Is this correct? There is no direct addressing other memory locations?
    If that is the case, what is the best method to keep data in those MODBUS memory blocks current? A MEMCOPY every scan?


  • #2
    Look at PUBLISH and SUBSCRIB. These are instructions specifically for dealing with writing or reading of non-Do-more data (e.g. MIR and MHR). For example, say you are dealing with REAL (DWORD) values where your HMI's endian-ness does not match Do-more's. You may need to swap words or do unaligned copies to get it in the right format of what your HMI expects. PUBLISH and SUBSCRIB do that.
    There are 10 kinds of people in this world, those who know binary, and those who do not.

    Comment



    • #3
      Stick your SUBSCRIB in $tTopOfScan and PUBLISH in $tBottomOfScan system tasks.
      There are 10 kinds of people in this world, those who know binary, and those who do not.

      Comment



      • #4
        Yes, Modbus server only addresses those blocks. Primarily is a security concern, but also a sanity and practicality concern...trying to map the entire range of possible Do-more memories to Modbus is problematic for a number of reasons.

        If you don't need to manipulate the data at all, MEMCOPY is the fastest way. The PUBLISH and SUBSCRIB instructions already mentioned are for moving data too, probably not as fast as MEMCOPY, but allow you to handle byte and word ordering, as well as format manipulations if required.

        And the Modbus server memories can be used like any other memory in the controller, so you can write your program to reference them directly so they don't have to be copied.

        Comment



        • #5
          Originally posted by BobO View Post
          Yes, Modbus server only addresses those blocks. Primarily is a security concern, but also a sanity and practicality concern...trying to map the entire range of possible Do-more memories to Modbus is problematic for a number of reasons.
          As I'm not a Do-More user and only know how Click (which addresses EVERYTHING) and Productivity (which lets you assign addresses to any tag willy nilly or in a fill-down scenario), why is it problematic? I rather like how Click does it. I know that C1 will always equal 18185 or 4708 in hex (I'm still at a complete loss as why hex is offset from the 984 address by -1)

          Comment



          • #6
            Block lengths of all built-in blocks can change, and user blocks can come and go and/or change length. Now that we've added user data types it's even worse, since user types can change record size. Since there are limited Modbus data types and ranges, it would be next to impossible to map the entire Do-more image register without Modbus offsets changing every time the Do-more map changes. This means everything that references a Modbus location would have to get touched...or more likely...doesn't and stuff gets broke.

            But that is all secondary to the fact that Modbus is completely unsecured. There is zero chance at this time that I would design a controller that allowed open access to my entire memory space with a de-facto standard protocol. Different people disagree, but I think it is unwise.

            Comment



            • #7
              Makes sense and I completely agree with the security aspect. As a guy who came into the industry from more of a IT role previous to, the lack of security in the PLC world was pretty astonishing to me. Up until what, 14 months ago, Productivity had no security at all, I couldn't even lock down my program. Even a lot of the "newer" standards have no real security to my knowledge. You guys seem to have one of the only platforms that has interdevice security.

              Comment

              Working...
              X