Using hostname instead of IP address in Kepware

[Erik vdH]

Hi,

Has anyone figured out how to access a PLC via a hostname in Kepware rather than it's IP address. You can do it in Linx but the Kepware ID field seems to only accept xxx.xxx.xxx.xxx IP address. This is no good because I have dynamic IP address for the PLC.

I'm trying in ControlLogix driver but a similar problem for modbus Ethernet as well.

 

[LadderLogic]

In the controls world dynamic IP addresses are not popular; not many PLC brands even support them. If they do, that is only for initial setup or remote troubleshooting, not for data collection.

If your PLC does support a dynamic IP and has a name registered with your DNS server, you would have to write your own little program to find the actual IP address and pass it on to the KEPServer.

 

[Erik vdH]

Anyone have any suggestions on how to get around it, or know of any PLC drivers (other than Kepware or Linx) that will allow the use of a name.

Anyone know of any routing type utility which I can point Kepware to using a dummy IP address, but it then keeps up with the hostname.

 

[surferb]

In the controls world dynamic IP addresses are not popular; not many PLC brands even support them. If they do, that is only for initial setup or remote troubleshooting, not for data collection.

...which is really lame and antiquated, btw, especially with the PITA factor of changing PLC IP addresses, which needn't be difficult.

You might contact Kepware directly about that.

 

[LadderLogic]

...which is really lame and antiquated, btw, especially with the PITA factor of changing PLC IP

Well, I mostly work with PLCs where changing of IP address (or, for that matter, any other network settings, like subnet mask and gateway address) requires power cycle. Talk about unnecessary complications.

On the other hand: I don't know. Say, there are PLCs that support DNS and there is an OPC server or any other application that can call a PLC by network name. Like in many companies, our network is a domain; only IT people have the right to register names in the domain; I can assign any name I want (as long as it is not being used) but without registering it, it will not be available across the network. So what is the point? All I need and get form the IT now is the range of IP addresses reserved for the controls use and that is all.

 

[surferb]

Well, DNS is one (useful) aspect of this, but I was really referring to the ability to assign MAC address reservations to a DHCP server, which allows you to centrally manage device IP addresses. This technique also works well with other nodes whose addresses rarely change such as servers and printers.

Of note to you - IT can add DNS (A) entries for any device regardless of domain membership and any nodes using that DNS server will be able to resolve it.

A lot of this frustration comes with defining requirements and the delineation between controls and IT.

Well, I mostly work with PLCs where changing of IP address (or, for that matter, any other network settings, like subnet mask and gateway address) requires power cycle. Talk about unnecessary complications.

On the other hand: I don't know. Say, there are PLCs that support DNS and there is an OPC server or any other application that can call a PLC by network name. Like in many companies, our network is a domain; only IT people have the right to register names in the domain; I can assign any name I want (as long as it is not being used) but without registering it, it will not be available across the network. So what is the point? All I need and get form the IT now is the range of IP addresses reserved for the controls use and that is all.

 

[cjd1965]

Hi
Not really relevant but I got the IT Dept to assign me an IP netwok of my own, which is still on the domain and can assign anything i want in the range xxx.xxx.xxx.???

Cheers

 

[surferb]

That's good! There are still many control systems out there where someone used addresses like 1.2.3.4 because they had no idea what they were doing, which can cause interoperability/remote access headaches.

Hi
Not really relevant but I got the IT Dept to assign me an IP netwok of my own, which is still on the domain and can assign anything i want in the range xxx.xxx.xxx.???

Cheers

 

[daba]

I find the whole concept of using dynamic IP addressing with DHCP or BOOTP for Industrial Control equipment slightly bizarre.

Who's going to modify the DHCP or BOOTP lookup at 3 am when a plant maintenance engineer swaps out a faulty Ethernet Comms module in a PLC system?

The new one won't be recognised by DHCP/BOOTP as it has a new MAC ID

 

[surferb]

It's applicable for cases where you have a robust infastructure and many PLCs to manage. It's easist to use static addresses for smaller setups.

I don't buy the "maintenance engineer at 3 AM" cliche as a defending argument in this case. That engineer will need to set the IP address of the new module that he replaces in any case - nothing prevents him from statically assigning it for "field expedient" cases. Then IT or whoever can set up the MAC reservation on the following business day, in accordance with your organized plan. But I think we're really missing the point...

In a high availability system support personnel need to be equipped to deal problems that impact production. This is applicable ANY TIME of day. Network infastructure falls into this category for many organizations. This implies that IT isn't a 9-5 job. There are many ways your company can skin this one ~ on call IT, cross train night shift to support the network, etc. The important point here is to erode that silly line between controls and IT where services overlap. I'm not suggesting that IT program your PLCs or that you write server group policies, but there is a "happy medium".

I find the whole concept of using dynamic IP addressing with DHCP or BOOTP for Industrial Control equipment slightly bizarre.

Who's going to modify the DHCP or BOOTP lookup at 3 am when a plant maintenance engineer swaps out a faulty Ethernet Comms module in a PLC system?

The new one won't be recognised by DHCP/BOOTP as it has a new MAC ID

 

[LadderLogic]

I guess this may work. As long as the IT is willing to... ehhh... unclench the fist.

 

[surferb]

Agreed - that's a whole different (culture) problem in itself...

I guess this may work. As long as the IT is willing to... ehhh... unclench the fist.

 

[cjd1965]

I simply use static IP's and have a list on the wall in my office where people can read it out of hours.. maybe not the most secure but it does the job well, and since a lot of GE PLC's only have static ip's it works a treat.

Cheers

 

[daba]

I don't buy the "maintenance engineer at 3 AM" cliche as a defending argument in this case. That engineer will need to set the IP address of the new module that he replaces in any case - nothing prevents him from statically assigning it for "field expedient" cases. Then IT or whoever can set up the MAC reservation on the following business day, in accordance with your organized plan. But I think we're really missing the point...

So the plant maintenance engineers will need to know how to set static IP addresses for all the equipment anyway.
Then there is further encumbent workload on the IT staff to update their relation list.
Then the plant maintenance engineer has to go and reset the module to use static addressing.
Then there is a need for a forced shut-down and power-cycle to test that the dynamic addressing works as expected (you shouldn't leave it to chance).

Why not just leave it be at static addressing ?

Please explain the urgent need to have it dynamically addressed.

Just what advantages does it offer ?

 

[surferb]

Seriously, how common is the 3AM module crash? If it occurs often then you have deeper systemic problems. Doing things properly mitigates outages. If the night crew knows what they're doing then the PLC gets fixed correctly the first time. If prior planning was done, the replacement part could already have a DHCP reservation. The "field expedient" approach allows you to get the process running without necessarily depending on a DHCP server. If the process can't EVER be taken down, then IT removes the old DHCP reservation and that PLC is set to static. Otherwise, you reset the PLC during the next downtime. The process really isn't complicated.

I never said anything was wrong with static addressing - in fact it's almost always the way to go in an industrial environment. I was mentioning a centralized management technique utilizing DHCP, in which the IPs rarely change - a very different usage than we usually think with dynamic addressing. One advantage is that this is conducive to separate VLANs for PLCs, which is a good way to protect them from broadcast storms and other common threats. It also promotes the requirement for IT to delegate some level of control and to understand industrial requirements, both of which I believe are inevitable emerging trends. I've seen it far too often where both sides are angry with each other for incidents that occurred due to simple misunderstandings of how the other worked.

If you have a robust network with a good network engineer, you'll have lots of cool options with respect to remote access, VLANs, dynamically "cutting" subnets, dealing with users/equipment across multiple physical sites, etc, without any, or with very little outage. This obviously isn't the technique for the plant whose 1 maintenance guy is also the PLC programmer, HMI designer, and local IT support.

So the plant maintenance engineers will need to know how to set static IP addresses for all the equipment anyway.
Then there is further encumbent workload on the IT staff to update their relation list.
Then the plant maintenance engineer has to go and reset the module to use static addressing.
Then there is a need for a forced shut-down and power-cycle to test that the dynamic addressing works as expected (you shouldn't leave it to chance).

Why not just leave it be at static addressing ?

Please explain the urgent need to have it dynamically addressed.

Just what advantages does it offer ?