Announcement

Collapse
No announcement yet.

Do-More H2-DM1E

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

  • Do-More H2-DM1E

    Nice and grunty (using my first one on a job now and it's growing on me) but there's one big issue... RIO is through the same Ethernet port as many of the useful 'other' functions that make the Do-More platform so nice.

    This is a problem - good practice is that IO isn't on the same physical network as any of your 'other stuff' like HMI / programming access, peer-to-peer, etc.

    Doing the job properly with RIO necessitates an ECOM in the rack to segregate the RIO from the aforementioned 'other stuff' and all of a sudden there's a whole lot of clunky workarounds through the ECOM to try and replicate some of the nice D-More functions.

    Either the ECOM needs upgrading, or a seperate RIO 'scanner' port be added to the H2 platform somehow.

    Cheers,
    Bushy
    Last edited by BushPig; 05-21-2019, 03:19 PM.

  • #2
    Use a BRX if you can. Two, pretty much full capability Ethernet ports (with a POM), AND newer backplane and I/O design thrown in.

    Comment


    • #3
      Thanks for the post. I have made the Product Manager aware of your feedback and it is greatly appreciated.
      If you have an urgent issue, please contact AutomationDirect's Technical Support team at 1(800) 633-0405 or (770) 844-4200. Thank you

      Comment


      • #4
        As a follow up to this, we're using the BRX in some applications and are faced with exactly the same issue... RIO needs to go out of the same ethernet port that does all of the cool interweb type stuff... which is actually not cool. The add on ethernet port needs to have additional capability for the same reasons as the H2-DM1E / ECOM combination needs additional capability. Close, but no cigar just yet.

        Comment


        • #5
          In 205 systems, you can use an H2-ERM100 module (Ethernet Remote Master). It is a co-processor that updates I/O completely asynchronous to the PLC CPU, with RIO on a completely isolated network. The main CPU can then communicate with "other stuff", on THAT network.

          You configure that module using ERM Workbench. Based on how you configure it, the Remote I/O can show up in DLV or DLX or DLY. ERM100 supports the various EBC100 models of remote CPUs (H2-EBC100, T1H-EBC100, BX-EBC100) along with GSEDRV100. Note that the GSEDRV100 support won't be "native Do-more" with a GS structure, but will be controlled via DLV/DLX/DLY memory manually.
          There are 10 kinds of people in this world, those who know binary, and those who do not.

          Comment


          • #6
            Thanks Franji.... it's a 'fix' but is a relatively common workaround - have had to do similar before. The extra engineering hours on development and / or interpreting what someone has done previously can very quickly negate savings in hardware. We go from an elegant solution to a clunky workaround simply to 'do the right thing' and separate the RIO from the rest of the world.

            The real solution is for the product to evolve to where it has a fully functional (in terms of supporting RIO, drives, 3rd party Modbus devices, etc.) second Ethernet port... It's a lot to ask from free software on a budget hardware platform I know, but I for one would be happy to pay a little more for that functionality.
            Last edited by BushPig; 04-09-2020, 03:37 PM.

            Comment


            • #7
              Its funny because Productivity has the opposite problem: a second ethernet port for RIO that everyone seems to ask for making it able to be used for regular network traffic too and not RIO only.

              Cant win either way I guess.

              Comment


              • #8
                The bottom line is that users like to segregate networks, and there are lots of good reasons to do so. The problem with Ethernet in particular, is that you can do so many different things on a port at the same time. There is finite capacity in a PLC, and communications is usually a secondary function, so doing everything everywhere can overwhelm the PLC. RIO is different from most because it is fundamental to the control, and because it's also very bounded in terms of how much bandwidth it uses. It's a logical thing to break out for more than one reason.

                But alas, we do listen! We are going to look at what it would take to build a new Ethernet POM that would be master focused, to complement the ECOMLT which is slave focused. At the minimum, it ought to be possible to have a separate RIO controller, but it may be possible to do selected additional master functions. No promises, but we do want to investigate. This is not the first time we've gotten this request, so we understand the need.

                Comment

                Working...
                X