Do-More remote bases - stuck with octal I/O?

[Scot]

I've run into another issue when migrating from Direct Logic to Do-More.
My Direct Logic PLCs have multiple local expansions and multiple remote expansions.
I understand that all Do-More expansions are remotes.

But this is my problem: I keep my remote expansion network separate from my PLC network. My PLC network will have a minimum of 10 PLCs (each with multiple expansions) and 8 C-More screens and at least 1 PC. It only makes sense to keep the expansion bases on dedicated networks, not accessible to the outside world.
To do that, I must use a ERM100 card in the CPU base and EBC100 cards in each expansion base. That's no big deal. But by doing that, some of the benefits of the Do-More processor disappear.
The biggest one is: the ERM writes to DL memory in the Do-More (octal).
It's nothing like the Ethernet IO Master option where all the IO is mapped so neatly. But having expansion bases on the same network as processors is a really bad idea. That leads to a lot of network traffic on 1 network and that expansion base traffic is critical.

Am I missing some other way to add remote racks to a Do-More that maps the IO in a better manner? Having decimal based IO mapping in the main rack and octal based IO mapping in remote racks is not something I want to do. I am already committed to using Do-More in the power plant expansion that's being installed right now. I'd really like to come up with a way to consistently map the IO in the 4 separate PLCs that will be installed there and their various expansion racks.

[franji1]

To get around that one issue, you can easily move DLX memory into X memory.  MEMCOPY on BYTE-casted boundaries will work just fine.  Do the same with your Do-more Y writing to DLY, "Analog In" DLV to WX, and WY to "Analog Out" DLV, all using different MEMCOPY instructions.  Just make sure your "dummy" X/Y/WX/WY are NOT tied to any REAL I/O.  Maybe start the discretes around X400/Y400 and the analogs around WX100/WY100?

MEMCOPY DLX0:UB X400:UB 8 // will copy 8 UNSIGNED BYTES (64 bits) of DLX0 thru DLX77 into X400 thru X463
MEMCOPY WY100 DLV1400 16  // will copy 16 WORDs of WY100 thru WY115 into DLV1400 thru DLV1417

[BobO]

Well, if it were me, I would expand X and Y memory to the required size and just bulk copy between DLX/DLY and X/Y in TopOfScan and BottomOfScan.

[Scot]

While that's not difficult to do and the discretes are not a lot of bytes, the analog is a full word per input/output and it's every scan.
It also doesn't fix the wiring issue. The base with the CPU will have inputs and outputs numbered base 10 (decimal) while all of the expansions will be octal. My electricians will have a fit and it's going to lead to confusion and mistakes. There's no real software fix to the hardware issue.

I tried remapping a CPU base to use DLX input ranges but that didn't work. Then they could be all octal which is much easier on the electricians doing the wiring because every card can start at an xx0 address (x0-17, x20-37, x40-57, etc instead of x0-15, x16-31, x32-47, etc). But some cards numbered base 10 and some numbered base 8 isn't going to work out well.

If the ERM card was a bit more compatible with the Do-more, there wouldn't be an issue at all.

It's nice for a small setup that the Do-more's built in network port works so well but it isn't ready for a factory installation. Expansion communication is critically important and it should have a dedicated connection just for reliability sake.

But logical input/output is critical too.

I am beginning to wonder if I can rely on a network switch (maybe a managed switch) to efficiently route traffic and not use an ERM card for expansion bases. But I REALLY want to avoid that. The new Do-mores are going in a power plant. It has to run over 8000 hours per year. These PLCs have to be completely flawless. Some Do-more features are very attractive in that regard (bumpless editing in particular). But the expansion communication is a major issue that will take more than a memory copy every scan to fix correctly.

The perfect fix would be an ERM card or firmware the would map Do-more I/O the same as the built-in port does.

[franji1]

The perfect fix would be an ERM card or firmware the would map Do-more I/O the same as the built-in port does.

Or a second Ethernet port on a Do-more CPU.  Both of these ideas have been discussed.

[Scot]

A 2nd port on the CPU dedicated to expansion bases would be ideal. There can't be very many installations that use just a single rack.

Does expansion communication use the IPX protocol?
While I can build networks, I'm not a network engineer. Right now I'm heavily leaning toward relying on the routing capabilities of network switches. I just have no idea how much bandwidth each expansion base requires.

[plcnut]

Would it be possible to use the Do-more built in port for your I/O and then an ECOM100 for your PLC network?

[BobO]

I'm not understanding the issue with copying. All DL205 modules are powers of two whether they are the local or remote. The memory addresses are simply base 10 or base 8. The result of moving ERM data to X/Y or local data to DLX/DLY should produce all decimal or all octal. If the bulk copy causes an unacceptable hit, that's a different issue, but copying produces the exact result as if ERM published to normal I/O memory.

My personal preference would be to use the onboard port for I/O and an ECOM for other traffic. And for what it's worth, we tested the Ethernet Remote Master on our office network, configured with 16 remote based, with all manner of other traffic including normal programming, and it worked great. Our specific guidance is to isolate I/O and other traffic, but it does work pretty well with all on the onboard.

But to help me better understand, can you give a quick overview of all the comm requirements and devices in the system?

We discussed making the ERM work like the onboard port, but that was far more work than we had time to do. Having ERM target X/Y would be fairly easy, but integrating the configuration into the Do-more system config would be deceptively complicated.

[BobO]

Just had a heart to heart discussion with the ERM firmware guy about adding a fully native mode for Do-more. After some deliberation, we think it is not trivial, but if we redo the PLC facing interface it is of manageable complexity. This would be a "coloring outside the lines" approach, but would allow an ERM to look essentially identical to the onboard Ethernet I/O. I won't publicly commit to a timeframe, except to say that we understand the need and would like to do a better job with this.

[Scot]

The copying isn't really a problem. But it will be a physical wiring problem. We would have a mixture of bases using base 10 I/O numbering and bases using base 8. That will lead to problems both during installation and during troubleshooting later.

Using the onboard for I/O and the ECOM for plant LAN sounds like a good idea. I'll experiment with that some. That will of course change the way Peerlink is coded (through ECOM mapped V memory rather than the PL structure and maybe no rate data) but it still should work.

I'll try to describe an overview of the communications.

There are currently 5 locations with PLC hardware. The new plant will add a minimum of 6 more (but I suspect there will be several more - remote expansion bases are much more efficient than running large amounts of control wiring).

Each location is connected with fiber and has a network panel where the conversions are made between fiber and copper.

There are several parallel networks. There is a network camera + internet network, a Plant network (all CPUs and C-Mores are on this and 1 PC), and several expansion base networks (a separate network for each CPU so the only devices on each network are that CPU's ERM and the EBCs for each expansion).

I have D sized drawings for the networks, but I'll try to draw it out and attach it. In my messy freehand drawing, the lines on the bottom and the left sides of each room are the fiber connections between buildings. The power plant will have a fiber connection coming into Room 400 with its Plant LAN connected to the current Plant LAN at the network switch. It will also include a Camera LAN that will connect to the current Camera LAN switch and another dedicated LAN for a turbine monitor PC. Externally, the new network will be similar with its own isolated PLC expansion LANs.

An ERM that appeared the same as onboard I/O would be perfect. To be honest, I thought that's what I was getting into when we selected Do-more for the project. The way you guys are supporting this product, I think you may be right: Do-more just may control the world someday. I haven't seen any other PLC with good support or that even listens to their customers as well as the Do-more.

[BobO]

Do-more actually supported setting the radix for each data type. We fully intended for that to be user-selectable, but doing so was going to give C-more headaches, so we removed the ability. It would probably still work if we turned it on, but would likely create havoc interfacing to C-more and other external devices. It might be possible to add an option to the INI file to enable it, but that might create more confusion than solutions.

[Scot]

I think I have a solution that will work with the single onboard ethernet port and no ERM card.
I think I can use a managed switch like:
http://www.automationdirect.com/adc/Shopping/Catalog/Communications/Ethernet/Ethernet_Switches/Managed_Ethernet_Switches_-a-_Accessories/SE-SW5M-2SC
and setup a VLAN so the fiber ports (Plant LAN) are only accessible by port 1 for example and connect the Do-More to port 1. Then the expansions can connect to the remaining ports (or another switch connected to these other ports) and they will be invisible to the rest of the Network. I should also be able to direct network traffic so the expansion networks use 0 Plant LAN bandwidth.

[HB_GUY]

Being a network guy first, and a PLC guy second, I would say in this case...
I would use managed switches and setup ACL's (Access Control Lists) to control what can talk to what, and also setup QOS (Quality of service) and prioritize the PLC and expansion base traffic either by static IP's or MAC based ACL's.
Alternatively, you could use port based VLANs and put all your expansion ports and HMI's into VLANs and setup routing on the switches so that only the PLC ports can talk to them.
Either of these cases would give guaranteed performance.

Also, as a side note, 100Mb/s switched networks really are quite fast.
On a 100Mb/s network, theoretically each port is capable of 8223.68 1500Byte packets per second (1 Packet every .1216ms), or 148809.52 64KB packets per second (1 Packet every 0.00672ms).

[Scot]

Thanks HB_Guy. Using a managed switch to create 2 virtual networks that are separated does appear to be the best way to go.
Also, thanks for the tutorial on how to do it. I was planning on using the port based solution if I can figure out how to do it something like this:

Port 1: Do-More port - can talk to all ports.
Port 2: Plant LAN port - can only talk to Port 1.
Port 3+: Expansion ports - can not talk to Port 2.

[HB_GUY]

Thanks HB_Guy. Using a managed switch to create 2 virtual networks that are separated does appear to be the best way to go.
Also, thanks for the tutorial on how to do it. I was planning on using the port based solution if I can figure out how to do it something like this:

Port 1: Do-More port - can talk to all ports.
Port 2: Plant LAN port - can only talk to Port 1.
Port 3+: Expansion ports - can not talk to Port 2.

You will need a managed switch that can do VLAN routing. in this scenario, you will need 3 VLANS.
You will have to have different IP subnets on each VLAN. ie. VLAN1 = 192.168.1.x/255.255.255.0 VLAN100=192.168.100.x/255.255.255.0 VLAN101 = 192.168.101.x/255.255.255.0

Port 1 will be VLAN 1 (The management VLAN) Connect this to the production LAN. (It will need an IP address, lets use 192.168.1.254 for this example)
Port 2 will be the PLC VLAN (VLAN 100)(It will need an IP address, lets use 192.168.100.254 for this example)
Ports 3-XX will be the Expansion VLAN (VLAN 101)(It will need an IP address, lets use 192.168.101.254 for this example)

The switch will then need to be configured with routing tables for all VLANS.
Then you will have the issue of routing on the rest of the network. ie, if you are sitting at your desk in the office, you will not be able to connect to the PLC or EXPANSION VLANs  because you are on the "Production" network, and your default gateway does not know about these other subnets/VLANs.

To resolve this, you will have to have a route entered into the default gateway for the "Production" network pointing to the IP address of the switch. (ie Route 192.168.100.x can be found at 192.168.1.254. Do this for both VLANs )

It may be simpler to have only 2 VLANs. Production/Management (VLAN1) and PLC NET (VLAN101).
In VLAN100, only the PLC would be configured with a default gateway (192.168.100.254 in the example above.) All expansion bases would not have a default gateway configured and would not be able to talk to anything outside of their VLAN.
Then only 1 route needs to be added to the company router/default gateway.
(additionally, you could forgo the route added to the company router and just have a static route setup on your workstation. This would prevent anyone else on the network from connecting to the PLC VLAN, as there is no route to it...)

Just a few thoughts. Hope they help.
If you need more help, you can email me at levon _at_ shiftcs _dot_ com