enbt <--> enbt over different subnets

Hello,

Our Eng and IT depts have decided to split my dept into separate vlans based on machine type. I have two machines, both RSLogix 5000, that were on the same subnet but are now on different ones. The respective enbt modules in each plc's project tree have been setup according to the new addressing scheme. But now are not able to talk to each other.

Plc A 192.139.5.xx subnet 255.255.255.0 gtwy 192.139.5.1

Plc B 192.139.6.xx subnet 255.255.255.0 gtwy 192.139.6.1

As stated the above info is entered into each plc's project tree correctly.

I put a pc on one of the subnets and could ping the other subnet just fine.

I can go online with either of the machines just fine.

Not sure but I think this is an IT/vlan issue. Can someone shed some light on this?

Thanks from a vlan noob,

Don

I was almost sure it was going to be an IT issue.

Since you say you can ping the controllers and go online with them, I'm not so sure.

What exactly do you mean by "are not able to talk to each other?"

If you are using produced/consumed tags they must be unicast rather than multicast as multicast cannot go beyond the local subnet. In V16 and above you can configure the produced/consumed tags to be unicast.

Thanks for your reply.

Plc A can't communicate to Plc B and vice versa. Produced and Consumed tags are unicast in both processors.

Hmmm. Did you also check that in the I/O tree under connection that 'use unicast connection' is checked. If it isn't it should produce a module fault.

Then it sounds like something in the switch between the two subnets is not properly configured.

It could be that only certain ports and/or protocols are allowed between to the two subnets. For example, RSLinx uses TCP and UDP port 44818. Ping uses ICMP instead of TCP or UDP. Which could allow you to ping but not much more. This would require IT to reconfigure the switch. Although if you are able to connect and upload/download it would appear that is working.

I still feel like I'm missing a vital clue here. What faults are you seeing?

Thanks again! The specific error is 16#203 connection timed out. I did check and use unicast connection is check.

Thanks again Timbert

Try changing your subnet mask to 255.255.252.0

On the computer where you are able to ping and go online get a command prompt and run the command IPConfig. What is the subnet mask set to on that computer?

I'm lost.

I resorted to TechConnect. [minus 10 points for Gryffindor]

According to 55468, in the I/O tree of the consumer, you need to set the connection or format of the producer to 'none' not 'rack optimization' or else you get a 16#203 fault. (This doesn't happen with my 1756-EN2TRs curiously enough).

I'm with TConnolly on this one.

Change your subnet mask on both PLC's. I think 255.255.254.0 would do it.

Cheers

Mark

TConnolly said:

Try changing your subnet mask to 255.255.252.0

On the computer where you are able to ping and go online get a command prompt and run the command IPConfig. What is the subnet mask set to on that computer?

Click to expand...

Yes. 255.255.255.0

Timbert said:

I'm lost.

I resorted to TechConnect. [minus 10 points for Gryffindor]

According to 55468, in the I/O tree of the consumer, you need to set the connection or format of the producer to 'none' not 'rack optimization' or else you get a 16#203 fault. (This doesn't happen with my 1756-EN2TRs curiously enough).

Click to expand...

I tried this. but it didn't get me anywhere. The thing is, The plc to plc connection has to be made first right? Then you can create your produced and consumed tags. Initially, I was just readdressing existing connections which are "pathways" for existing produced/consumed tags. I tried setting up a new connection to a different plc on the different subnet (from 192.139.5.x to 192.139.6.x) with no produced/consumed tags yet created and got the same result.

MarkNightingale said:

I'm with TConnolly on this one.

Change your subnet mask on both PLC's. I think 255.255.254.0 would do it.

Cheers

Mark

Click to expand...

I had previously tried 255.255.248.0 with the same result. Also tried 255.255.0.0 - no good either.

I appreciate the assistance guys. Due to time constraints we have to back up and leave the machines on the same subnet for now. And hopefully attack this at a later date.

Thanks again.

Yes, the subnet mask needs to ignore those differing bits in the third octet, +1 for changing the subnet mask in both cards as well as the supporting PCs.

I am no expert, but I would try 254 in the 3rd position if Troy's suggestion did not pan out.

There are lots of ways to set up VLANs so its difficult to say exactly what to do.
The VLANs could have been setup tagged or untagged as access or trunk ports and they may or not be overlapping- and that all makes a difference how to get things going. Assuming they are all non-overlapped untagged access ports (sort of like just turning your switch into a few separate switches), then they really are simply separate VLANs, and it takes a Layer 3 device (a router) to allow connections between the LANs. Since your ping works I'm guessing that is how its set up?? A router would then be used to specify a route for each LAN: the first VLAN would have a route to the second VLAN and the second VLAN would have a route to the first VLAN. And there would need to be firewall rules that allow access between the LANs. An IT person would be a great resource here...

I would first start with plugging your laptop into the switch/cable that is local on one of the machines. Change your IP to match that comm modules IP range then ping the other device. If no communication can be established I would ask IT/Engineering to look into the VLAN configuration. Could be as simple as trunking a port on your switch. What exactly does your network architecture consist of? What switches are local to the equipment, what does your backbone network operate on?

Success!

Sorry for not reporting back sooner but our start-up was hectic to say the least! We finally did get this issue resolved!

I had a misunderstanding about the differences between errors codes 16#203 and 16#204. See 50924 Because of that, I incorrectly thought that a 203 error meant that I was not communicating at all. As it turns out, even with error 203 the messages and produced/consumed tags were working. I developed a massive case of tunnel vision about the error and didn't go further. Shame on me.

As stated in an earlier post, I had tried the suggestion that Timbert gave on rack comms to "none" on the consumer end and at that time it did not get rid of the error. During that time the IT guys were still making some changes because it appeared to not be working. Ultimately setting the consumer rack comms to "none" got rid of the error just as Timbert said!

I really appreciate the help. Thank you all!

Thanks for reporting back and letting us know. I'm glad you got it working.

I had forgotten about the subtle yet profound difference between a 16#203 and 16#204.

I wish they would have called the error something different. Something like:

16#203 Timeout -- connected but incomplete data transfer
16#204 Timeout -- not connected, no response

I would think it would make it more obvious where to look, whether network or PLC.