Trouble with Panelview Communication

[CB_Will]

I have a panelview plus 6 1000 that I am trying to VNC into. I have the VNC settings correct on the panelview but I get a message that the panelview took too long to respond. I tried to ping it. I can not ping it for some reason. The panelview is working just fine and communicating with the PLC's.

 

[Operaghost]

Welcome to the forum!

So being unable to ping it is the first thing to solve. Nothing else is going to work until you resolve that.

• What is your IP address and mask?
• What is the PV IP address and mask?
• How are you physically connecting? Is there a switch, are you connecting directly?

Details will help us to help you.

OG

 

[CB_Will]

My PC is 10.0.97.xx sub- 255.255.255.0
Panelview is 10.0.98.xxx sub- 255.255.255.0

The ethernet cable runs from the panelview to a N-tron switch.

 

[plvlce]

My PC is 10.0.97.xx sub- 255.255.255.0
Panelview is 10.0.98.xxx sub- 255.255.255.0

With those mask settings your PC is not on the same network as the Panelview. You will not be able to communicate with those settings unless you have a routing, NAT, etc device in between.

Any setting of 255 in subnet mask means the corresponding IP octet must match exactly.

 

[CB_Will]

I am able to ping other PV's with the same setup but of course a different octet at the end of the IP on the panelview.

 

[Operaghost]

My PC is 10.0.97.xx sub- 255.255.255.0
Panelview is 10.0.98.xxx sub- 255.255.255.0

The ethernet cable runs from the panelview to a N-tron switch.

10.0.97.xx with the subnet mask of 255.255.255.0 means that the starting address for that network is 10.0.97.0 and the ending address is 10.0.97.255. The first and last addresses cannot be used by devices so the usable addresses are 10.0.97.1 through 10.0.97.254.

The PV has the same setup except it is on the 10.0.98.x network. That means your PV and your computer are on separate networks. They might all be cabled together on the same switch, but address-wise, they are on separate networks and cannot talk to each other.

To resolve this would require some device to route data from one network to the other. A router, or what is called a Layer 3 switch could potentially do this, but they are quite expensive and require some expertise to setup.

If you MUST keep using these addresses, then you could make this work without extra hardware by changing the subnet for all devices to 255.255.252.0

With this subnet, your network addresses would start at 10.0.96.0 and end with 10.0.99.255. Any devices within that range would be able to talk without need for a routing device. Just be aware that this is a non-standard mask and it could be confusing to people that tend to use the default 255.255.255.0 for everything.

OG

EDIT: OK I didn't ask this before, but do your devices have a gateway IP address specified? Usually you would have an IP address, a subnet mask, and a gateway address. If you do have a gateway (something other than 0.0.0.0), then you already have a routing device that would allow the devices to talk across the separate networks. That would explain why you are able to ping other devices.

 

[CB_Will]

I do believe we have a routing device. We do utilize the gateway. (10.0.98.1)

10.0.97.x is all of our computers, printers, etc.

10.0.98.x is our plant systems. PLC's, drive, PV's, etc.

We can normally communicate between the two just fine.

 

[Operaghost]

Ok that tells us we don't have an issue with addresses. We can set that aside.

The next thing to look at is checking the physical connections. Check your cable to the PV. Try a different cable if you have one available. Cables can go bad. Verify at the switch you see the indicator lighting up as you unplug and plug back in the network cable.

Some switches can be configured to where specific ports may be shutdown or assigned special settings. If there is a port designated specifically for the PV, make sure you are using that port. Plugging in to any available port may not work.

Lastly, make certain the PV is using the address you think it is using. If you access the Configuration screen, it is usually displayed along the bottom left corner.

OG

Ok, one other item to try is to open a Command Prompt window on your PC and enter "tracert 10.0.98.xx" replace the "xx" with the last octet for your PV. This tool will show the route your computer is taking when attempting to talk with that PV. It should show the message going to your local gateway (such as 10.0.97.1), the remote gateway (10.0.98.1), and then your PV. If you see it reaching your local gateway then you know your network is good. If you see it reaching the remote gateway (probably the same physical device) then we know the gateway is routing the data across the networks. If it fails to find your PV then we know it is an issue on that network or that device. You can use it on one of your other PV devices first so you can see what it should look like when everything is working properly.

 

[CB_Will]

All of that checks fine.

The Panelview is communicating with the PLC. They both plug into an N-tron switch and then to the switch.

The IP, subnet, and gateway are all correct.

 

[Operaghost]

Tracert would be my next step. See where the communications are getting lost. Again, use it first with a "good" PV so you see what it should look like. Then do it again for the problem child.

OG

 

[CB_Will]

So I have been working on this and found a few things. I can not ping ANYTHING in the tree underneath the first E-net card. One ethernet card in my main panel goes to the "smart" switch. Everything else underneath it in the tree goes to a N-tron "dumb" switch and then to a different E-net card on the same chassis.

I ran an ethernet cable from the N-tron to the "smart" switch port that was the same VLAN as the main E-net card. I was then able to ping everything but ran into problems by adding all of these devices to the main tree.

My problem seems to be trying to communicate through the AB hardware. Thoughts on that?????

I tried the Tracert. The panelview that I can not ping just stops at 10.0.97.1, the gateway for my own PC.

 

[celichi]

I will mention this just, probably not going to help you, but it was something I ran into.

I had a switch that would stop communicating because the ARP table was full, and could not assign any more MAC Addresses.

I rebooted the switch(which apparently flushes the ARP table) and bingo, everything started to talk.

 

[CB_Will]

I will mention this just, probably not going to help you, but it was something I ran into.

I had a switch that would stop communicating because the ARP table was full, and could not assign any more MAC Addresses.

I rebooted the switch(which apparently flushes the ARP table) and bingo, everything started to talk.

Sadly that did not work either. I reset power to it over the weekend and still have no luck.

Thank you for the suggestion though.

 

[CB_Will]

I still do not know why we can not ping the panelviews when their communication goes through the backplane but we came up with a work around.

Our solution was running the panelview to directly to a port on the "smart" switch, put the port to the right VLAN, and reset the communications path on the runtime file. Now our Panelview works correctly AND we can VNC into them.