Panelview 1000 communications

[SNK]

You don't need to use the addresses in the PLC to use them in an HMI application.
(The x's denote that they are USED in the ladder part of the program)
As pointed out before, the literature is indicating a Controlnet problem.....
(Obviously not a ControlNet 1000 right?)
Call Rockwell, and ask them what that error is showing up for.
It is a really straight-forward task that you are attempting to compile,and should work.
Good Luck, I have to go shovel snow now....I live in Canada...

 

[Eddie Willers]

Error 634 is a general error code indicating a network communication error, and can happen with any network interface.

It's the other words that make a subtle but important difference.

634 Read Timeout
IP: 10.26.32.28 Tag: b60:0/0; Length 2

You are not getting a "PanelView Offline" indicating the terminal is not connected to an Ethernet link. You are not getting a "Read Fail", which would indicate the B60:x data elements do not exist (which we can see they do).

You are getting a Read Timeout, indicating that the PanelView attempted to read from the SLC-5/05 but did not get a response from the SLC-5/05.

This could be a number of things, including something firmware related or something unusual on your switched network (any VLANs active ?).

I notice that your SLC-5/05 is a Series B, OS501, FRN 5 controller. That's a pretty old (about 7 years) release, so there might be some changes to the SLC firmware or the PanelView firmware that affect you. A call to Tech Support might help clear that up.

I also found an RA technote, ID# 20490, that addresses some of the potential reasons for this error code on a PanelView Standard terminal.

 

[SNK]

Again, Error 634 is ONLY referenced under the CONTROLNET errors in the Std Panelview manual.
Just a question....Has this terminal been Flash Upgraded?
Read the manual for that error. You will see that it is NOT ethernet related.
As posted previously, you don't need any program for the PV to function communication-wise for the PLC.
It will even work in Program Mode without having errors.
I have worked on hundreds of these units, there has to be something very simple that we all are missing......

 

[Eddie Willers]

The first time I mentioned it, it was from memory.

But I know I've seen that code on other terminals, and I found a bunch of references to it in the Knowledgebase.

It's in the User Manual as a General Code, and in multiple mentions as a code for ControlNet terminals, and one mention for DeviceNet terminals (which is probably where I've seen it most). My copy of the manual is from November 2004, but I downloaded the November 2007 and that part appears the same.

My guess is that because the terminal shows up in an RSLinx browse and he can configure and run an Ethernet application on it, that the Ethernet unit just adopts the ControlNet terminal codes with regard to timeout and read fail.

From this description and having seen the project files for both, I'm leaning towards a firmware problem or an IP subnet or Ethernet media problem.

Any chance, flashthomas, that you are familiar with port mirroring and the Ethereal sniffer ?

 

[OkiePC]

Error 634 is a general error code indicating a network communication error, and can happen with any network interface.

I concur with Eddie on this one. I have seen it on my ethernet panelview standard when the SLC it was trying to read/write was simply not powered.

 

[Ken Roach]

I have used more PanelView Standards on ControlNet than on EtherNet/IP, and I remember getting this error quite a bit on a noisy, long ControlNet with PLC-5C15 controllers on a project out in Montana. But again, different architecture.

The other day I was at a seminar presented by a Hirschmann rep where he described the usefulness of VLANs when you have a 10 Mb/s Half Duplex device that you're plugging into a switched network that includes a lot of other devices.

I'd try isolating this SLC and this PanelView onto a switch separate from the plant network (if they aren't already) to see if that makes a difference.

 

[panic mode]

i agree about isolating them from the plant network
try to make it work and then play with it, move it back to plant network etc.

if it was me doealing with this, i would first try pinging both nodes to verify they are really there (i've seen situations where RSLinx takes some time to show connection loss).

there is nothing in the comm. settings that looks suspicious but i've never tried class A subnet (who in the world other than ISP has need for class A?). once isolated try something more common like class B or C (mask 255.255.0.0 or 255.255.255.0) since this is something that works.

 

[Bob A.]

When I complete the screen development, I test it from the PC before sending it to the PV. If there are PLC address problems, etc. you will know before trying to get it to work in the PV.

The other thing that I remember seeing is that you can copy the PLC address to the target address that you are sending to the PV. When you start up the application in the PV, there is an option to keep the address that the PV is currently using or to change to the the one that will be in the new file. This process must be managed carefully to stay on track. This usually sorts itself out, once everything is the same, but if something new is present, I have gotton lost a few times. I don't remember the errors that I saw, but the symptoms are as you describe.

Best Regards,

Bob A.

 

[SNK]

Bob, there is no method of test on the PC for PB32 applications.
You must be thinking about the PV+ models.

Do what Panic Mode suggests, and change your subnet to 255.255.255 and do a point to point test first.

I have already assumed that you have pinged and associated the Ethernet IP's already.

Worst case scenario, I will dump your projects into 2 units on Monday and let you know. From the applications that I looked at, there shouldn't have been any issues.

Best of Luck.
Again, what firmware is residing in the PV?
Maybe it is worth-while to flash to the most current.
Maybe, it was flashed with the wrong-application.
I have seen crazier stuff than that happen.....

 

[beanpole_ecc]

i know this is an old thread but i noticed that it's sort of been dropped without a definite resolution. I'm currently experiencing the exact same scenario that flashthomas was describing and was wondering if anyone has an answer? I've set up a few of these ethernet plc to pv scenarios and have never run across this problem until now. All settings and device setups all seem to be correct and should work but the pv is giving a read timeout error. I also compared my programs to flashthomas' and the setups mirror each other. Anyone have any thoughts?