Separate networks on MPU & POM ethernet?

[Ssweber]

Hello,
In our plant, I have 1 network that is connected to internet (for computer use), and 1 that is strictly internal, no internet connection, (for plc and cameras).

I want to be able to use the BRX to publish certain data to server. Are you able to connect the MPU to the internet-connected network, and use the ethernet POM for modbus tcp on the non-connected network? Right now they both use 192.168.1.x addressing.

Possible? Would that actually keep it secure?

Also, I noticed that the POM can only do modbus server. I'm currently using the MPU to poll for data from several connected Click CPU's, and I also write data to it from a computer program. I'm a little rusty as to what client/server entails. If I use the POM for modbus tcp, would that restrict me to only writing to the BRX from other devices, or the other way; only polling from the BRX?

Thanks for clarifying this for me!
Sam

[ATU]

You got it right. The POM is only a Modbus Server. It can't initiate any Modbus communications. Other devices have to Read or Write to it.  However, usually that is not an issue if you have a relatively smart device talking with it. You can setup some handshaking registers that the Modbus client polls when new data or commands are present. The main port on the CPU and the POM can be on 2 completely different subnets.

[Ssweber]

Thank you!

[Controls Guy]

And I believe there's a Super POM coming in the next round of hardware releases that will do anything the internal port will do.

[BobO]

And I believe there's a Super POM coming in the next round of hardware releases that will do anything the internal port will do.

Yep...will be called BX-P-ECOMEX. Pretty much does everything the internal port does, except that NetEdit doesn't configure it. It isn't actually module, per se, but just another NIC attached to the CPU. As such, it will have similar rules to PC networking environments...like...routing. It will be necessary for each port to have a different subnet address to function correctly. That is generally a very easy thing since internal network addressing is usually arbitrary, but I'm sure it will cause somebody some heartache. It'll totally mess with your head too. Put both ports on the same subnet and it'll receive a request on the secondary port but answer on the primary. Fun.

Also adding DHCP support on both internal and ECOMEX. More and more folks are using BRX as MQTT edge devices and other client only functions that would benefit from DHCP, so we're adding that too.

[jcottrill]

Hey BobO,

The DHCP news is great!  The MQTT edge device is one case but another case is factories that only have DHCP network segments and no static pools.  In these cases they often use IP reservations to ensure critical devices come up with the same IP.  In these environments, some Engineers and techs can make a mess if they just grab an "open" IP and assign it statically without requesting a reservation. 

[BobO]

Hey BobO,

The DHCP news is great!  The MQTT edge device is one case but another case is factories that only have DHCP network segments and no static pools.  In these cases they often use IP reservations to ensure critical devices come up with the same IP.  In these environments, some Engineers and techs can make a mess if they just grab an "open" IP and assign it statically without requesting a reservation.

The DHCP client stores the last assigned address in retentive RAM and re-requests the same address on subsequent boots, so we're already making at attempt to get the same address. Obviously if the DHCP server is setup to return the reserved address on the basis of the MAC address, better still.

[Controls Guy]

Pretty much does everything the internal port does, except that NetEdit doesn't configure it.

So how DO you configure it?   CPU config only, like the CPU config option now on the ECOM-LTs that can override the NetEdit config?

[BobO]

So how DO you configure it?   CPU config only, like the CPU config option now on the ECOM-LTs that can override the NetEdit config?

The default config is part of the POM config. It can be runtime modified via SETUPIP. The ECOMLT is a different beast because it is a co-processor. The ECOMEX isn't.

[johnr]

Will we still be able to browse the new POM module nodes on NetEdit as long as they are on a common subnet, even though the POM can't be configured from there?  That functionality, or a similar browse utility will be really essential I would think. 

The reason that I ask is that I'm looking at configuring a whole cluster of BRX PLCs on a SCADA VLAN, in a case where each BRX built-in ethernet port is already spoken for as the master for an local, internal machine control bus using custom sockets protocols. 

We're counting on using the POM ECOM modules as our wider area link, and now we'll almost certainly wait for the new POM before fully implementing.  NetEdit is a key management tool for us to verify network connections and proper configurations.

The current ECOMLT is swap-able, even hot-swap-able, I believe.   From the sounds of it, will the new unit not be swap-able without a system re-configure?

[BobO]

NetEdit does works for browse.

ECOMEX is hot-swappable. The POM configuration contains settings for every POM. The ECOMEX can also be reconfigured via SETUPIP.