DNS Names for DmD PLC Connections

[johnr]

There doesn't appear to be any way to assign a DNS name for a PLC IP address when setting up a PLC connection to use within Do-More Designer.  All I can do is enter the numerical IP Address in the usual xxx.xxx.xxx.xxx format.

Could you confirm that this is the case, and if so, are there any plans to add that capability to the DmD software?  Thanks

[BobO]

It's not particularly hard, but this is the first time I've ever heard the request. Control system addresses are not generally subject to reassignment, so abstract addressing isn't a common thing.

[johnr]

I set up a physically isolated Static IP network at my main client over a decade ago, with various DirectSoft/Do-more/C-more nodes.  It's nice and simple and I manage the master IP address table.  But now I do all my work for them remotely, and the only way to access the PLCs is with VNC Viewer to an on-site engineer's computer that has an extra adapter plugged into our automation ring.

So, for this and other reasons, we are now beginning to migrate our PLC and HMI connections onto the main company network, no longer managed by myself or the automation group.  In this particular location this is the only way that we will be allowed to implement remote/VPN access to individual control nodes.

There are scores of DS and DM ethernet nodes involved.   The IT folks will work with us, but the network is way too complex for them to be able to keep all the engineer's PC's and the PLC's and HMI's on one subnet.  There now are segmented VLANs and routable connections, and we can still connect just fine, but we lose our handy NetEdit browsing to find a PLC's address. 

IT agrees to set fixed IP addresses based on unique switch port number or MAC address as we wish, but they would prefer being able to reassign subnets as necessary.  If we convert to defining PLC connections by DNS name, there will be far fewer issues as we progress.

As we all continue to migrate toward more remote connectivity on highly-managed company networks, I would expect to see more of this type of thing.  I thought I'd ask because I figured it's not difficult to implement.  It does involve a subtle change to the connection setup dialog, though, that can potentially throw a lot of users for a loop.

[ADC Product Engineer]

I am actually surprised that this hasn't come up before.  Having DNS handle the IP assignments makes sense from an IT standpoint.  I mean it's what DNS is for. 

[BobO]

I am actually surprised that this hasn't come up before.  Having DNS handle the IP assignments makes sense from an IT standpoint.  I mean it's what DNS is for.

DNS doesn't assign, it reports. And since the IT guy isn't likely the one changing the PLC's IP address, the IP address starts with the controls engineer anyway. In a larger system where you have more than one engineer and IPs are subject to being changed, it makes decent sense to use a name. In the typical H/I/J customer we see a lot of, it really doesn't help that much.

As the PLCs are becoming IoT clients, we are seeing a big increase in the need for DHCP though, so I would also expect more interest in Enterprise level network tools. DNS isn't hard to add to the link. We'll look at it.

[johnr]

I should add something to clarify -

The ability with Do-more to now have two separate Ethernet ports on separate subnets is driving a lot of this.  It allows us to do things that in the past required a PC, hence the request for more PC-like behavior. 

In our first case here, the built-in Ethernet port is used for machine-level control and is all static IP.   Those connections will never be on a wider area network and will remain under the management of the controls guys. 

The POM port is configured as Ethernet #2, for supervisory/SCADA monitoring/programming access only, and that's the port that will be managed on the company LAN.  We don't need control of its IP address as long as we can call it by DNS name.  Our SCADA can do that already, but DM and CM not yet.

If you go to the trouble of implementing, it would make sense to also convert the "Connect to Single device" dialog in NetEdit.  In fact, if you did that first by itself, it would be a nice built-in tool for tracking down DL and DM assigned addresses that are routable.

Thanks as always for hearing us out!

[BobO]

I should add something to clarify -

The ability with Do-more to now have two separate Ethernet ports on separate subnets is driving a lot of this.  It allows us to do things that in the past required a PC, hence the request for more PC-like behavior. 

In our first case here, the built-in Ethernet port is used for machine-level control and is all static IP.   Those connections will never be on a wider area network and will remain under the management of the controls guys. 

The POM port is configured as Ethernet #2, for supervisory/SCADA monitoring/programming access only, and that's the port that will be managed on the company LAN.  We don't need control of its IP address as long as we can call it by DNS name.  Our SCADA can do that already, but DM and CM not yet.

If you go to the trouble of implementing, it would make sense to also convert the "Connect to Single device" dialog in NetEdit.  In fact, if you did that first by itself, it would be a nice built-in tool for tracking down DL and DM assigned addresses that are routable.

Thanks as always for hearing us out!

Couple of things you might find interesting. We are about to release a new Ethernet POM that is basically a secondary internal adapter. It allows for better subnet segregation of built-in network features. Second, since we are doing more IoT apps where the PLC doesn't need or benefit from a fixed IP address, we are adding DHCP to the internal port.

[johnr]

Funny, I never realized that the internal port didn't support DHCP to begin with, we went with the POM for LAN access from the start.

I definitely noted the earlier discussions on the new and improved POM.  Will that be supported in DmD 2.8 or are we looking further out?

[BobO]

We have a significant launch coming in December. DmD 2.8 is part of that launch.

DHCP made sense on ECOMs (including the POM) because they were frequently used as clients. The internal port was used/viewed more as programming, and DHCP didn't make as much sense, and even causes issues for some customers...comm link worked and now doesn't. As BRX has gotten more traction in IoT, DHCP is a big help.

[jwbaker3]

I may be way off base but we use managed switches to port between subnets in the automation systems. We have setup clients plants with vlan's on each line in copper each line has a it's own subnet (the third octet is the line number) we then go to a managed switch to fiber to the automation server. The server is the VPN hub for the plant and has Ignition on it to collect production/downtime data on all of the lines. Thru the VPN I can get to any PLC, HMI etc. in the plant. We also have some clients that don't have the infrastructure or want it, we will put an Ewon or Stridelink on each local subnet and connect that way. 

JW