RECV command in CP1L-E from NJ-301 in different subnet

[MechEngi 0]

Following my post from yesterday and the fix proposed by @chelton, I went ahead and expanded the solution to multiple PLCs in the shop.

Now I'm stumbling on another layer of difficulty : I have to RECV in a CP1L-E (10.1.14.214) from a NJ-301 (10.1.46.118).

Both PLC's are physically connected to the same Ethernet Switch in the shop, but the IT guys decided to add a new subnet for PLCs and equipment some time ago.

I read Michael Walsh's answer on this post but I couldn't figure out how to set things up properly with 2 subnets that are not consecutive.

What do I need to setup in the CP1L-E to be able to RECV properly? There is certainly a routing table setup that I need to add but I cannot figure it out by myself.

Here is the current setup :

• In the NJ, I have a UINT variable mapped At %W0, Network Publish set to "Output"
• The RECV command in the CP1L-E is as follows:
  • C0 = 0001 (1 word)
  • C1 = 0001 (Port 0, network 1)
  • C2 = 7600 (node 118, unit address 0)
  • C3 = 0203 (port 2, 3 retries)
  • C4 = 0032 (5 sec timeout)
• The Built-in Ethernet parameters in the CP1L-E are attached

Thanks !

Edited 9 Aug 2023 by MechEngi
removed wrong attachment

[pturmel 160]

You will almost certainly need a router, not a switch.  (Fire the IT guys?)

[MechEngi 0]

13 hours ago, pturmel said:

You will almost certainly need a router, not a switch.  (Fire the IT guys?)

To my untrained eyes, these two devices are interchangeable, so I may have used the wrong term. In any case, as mentionned, they are both physically connected to the same device (be it a switch or a router). I'm guessing there is nothing special to do in that device to allow communications between the two PLCs?

[pturmel 160]

1 hour ago, MechEngi said:

these two devices are interchangeable

Nope.  Let me summarize:

• An ethernet hub broadcasts packets coming in one port out the other ports.  This behavior matches the original coaxial taps and can be implemented with just switched amplifiers.
• An ethernet switch examines the MAC address on packets entering a particularly port and attempts to direct the packet out the port that is known to have that MAC address, eliminating excess traffic on other ports.  Where not contended, modern ethernet switches will stream the packet from inbound to outbound ports with just the latency of the header.  Switches fall back to broadcast for unknown MAC addresses, and apply various rules to deliberate broadcasts, multicast, and certain other kinds of packets.
• An internet protocol router examines the destination IP address of a packet entering one port (and if ethernet, addressed to the router by MAC) to determine which of its ports, if any, have a compatible subnet.  If configured to do so, the router will forward unmatched packets to an upstream router.

When you have two incompatible subnets living on the same switch, packets destined for the opposite subnet will be directed to the source's gateway MAC address for routing, since the subnet indicates that the packet is not local.  If there's no router to echo the packet back out onto the switch with the corresponding MAC target (learned with ARP), the packet will simply land in the bit bucket on the floor.

[MechEngi 0]

That's a very interesting summary. Thank you for taking the time to write that down.

After furter investigation, it seems that our plant's netword is as follows :

• A bunch of equipment on subnet 10.1.14, wired to a few switches
• A bunch of equipment on subnet 10.1.46 wired to a few switches, sometimes on the same switch
• 2 routers for the whole plant into which all the switches are connected

5 hours ago, pturmel said:

When you have two incompatible subnets living on the same switch, packets destined for the opposite subnet will be directed to the source's gateway MAC address for routing, since the subnet indicates that the packet is not local.

That means that our current network architecture is viable for my original intent, is that correct? The end router will eventually receive the packet and somehow (this is the part I'm interested in, if there's a setup to do) send it back to the right place ?

[pturmel 160]

2 hours ago, MechEngi said:

The end router will eventually receive the packet and somehow (this is the part I'm interested in, if there's a setup to do) send it back to the right place ?

Unlikely, highly dependent on the router implementation.  Lots of simple ones will choke on sending a routed packet back out the same port it came in on.  Even the best routers will choke if a given subnet reaches the router via multiple paths.

Mixing subnets on one switch is simply unsupportable (unless you are segregating by VLAN, and the router knows the VLANs).

Supported layout, if you are not using VLANs:

• Every switch must have one and only one subnet assigned.
• Routers must have single (logical) ports connecting to each subnet.

If you are using VLANs, each VLAN can be considered a separate switch, even across multiple physical switches, and then the above rules apply to the VLANs themselves.

(An IT person who set up what you described is incompetent.  IMNSHO.)

[pturmel 160]

Consider making a diagram that shows the connections between your switches and routers, plus the two devices in your OP (showing which switches they connect to).  Ask your IT person what the routing behavior is for those two devices in that setup.

[chelton 66]

If your able to connect to both plc's without changing your workstation ip it would suggest that the default gateways are set and there is a route already in place.

[MechEngi 0]

15 hours ago, pturmel said:

Mixing subnets on one switch is simply unsupportable (unless you are segregating by VLAN, and the router knows the VLANs).

After asking the IT guy, we do have a VLAN on subnet 10.1.46 (VLAN 20).

10 hours ago, chelton said:

If your able to connect to both plc's without changing your workstation ip it would suggest that the default gateways are set and there is a route already in place.

Yes that is the case. I even have a central HMI that connects easily to both PLC's. That is also the main reason why I posted here. I figured that if my PC and the central HMI can both easily connect to either PLC's, then the PLC's can certainly communicate with each other rather easily.

[chelton 66]

In your device you are performing the recv on you will need to add an entry in the fins/UDP tab. This is where you can map a fins node address to an ethernet address. Fins addressing on a local network is based on the last octet of the ip address, however when trying to reach a unit on a different subnet you will need to add the mapping.

If the NJ is the device your trying to RECV from you will need to set up the source data as  CJ memory addressing by using the "AT" address translation. Some processors you have to enable the CJ memory areas. 

[MechEngi 0]

On 8/11/2023 at 5:01 PM, chelton said:

In your device you are performing the recv on you will need to add an entry in the fins/UDP tab. This is where you can map a fins node address to an ethernet address. Fins addressing on a local network is based on the last octet of the ip address, however when trying to reach a unit on a different subnet you will need to add the mapping.

This was my first tought, but I'm unfamiliar with how that works in CX-Programmer. I tried something but it did not work.

Here is a screenshot of the parameters that I tried in the FINS/UDP menu :

Here are the current (unchanged) network settings: 

What did I do wrong?