Something Silly, PVP7 IP Address

PLC Pie Guy

Member
Join Date
Jun 2013
Location
Halifax
Posts
1,144
Folks.

Iv the luxury of replacing a PVP7 that got hosed down internally this morning.
It happens here. I'm used to it. However, today, the PVPlus1000 replacement, a PVP7, Performance model, Series B terminal has a different feel to it.

First thing I notice, a big orange sticker on the box. It tells me that there is a new operating system in this unit (Series B). Many changes, biggest one to us, is the loss of VNC viewer. Not impressed.

Anyway, I'm having troubles setting the IP address. It allows me to switch the Automatic address switch to OFF, it allows me to easily enter my Subnet mask and gateway as expected. However, when I go to the IP Address field, its already populated with 0.0.0.0 If I try to enter a value into any one of these it doesn't. After several presses of any numerical key, it will show one digit, however, upon pressing the next key, the zeros return.

Iv tried with the USB keyboard as well with the same results as described above.

Its really odd and I'm guessing there is some secret AB ritual I need to perform before I'm granted access to set an IP address.

Anybody else have this issue?

Thanks
 
Have proceeded as instructed by BachPhi. Perhaps AB should re-write their "Quick Start Guide"

Worst thing is, I cant believe we just paid this much for 2 (Performance Model) PanelViews that lack VNC. Iv got free HMIs that have VNC. We use VNC for everything here..... How is it even an option to drop that. I know they boast the ViewPoint, but were not setup for ViewPoint, nor do HMIS have capacity to run view point without adding external memory to them. Then to have one out of 40 or so HMI on ViewPoint rather than VNC is a PITA.
Just my Monday ramable.


Anyway, Firmware is upgrading now.

Thank you.
 
I suspect VNC will be reenabled at some point with a firmware update. Whatever updates they did behind the scenes probably affected the VNC tool and prevented it from working properly. Doesn't help if you were using VNC and suddenly it is gone.

Question though...Unlike Logix controllers, previous PanelViews always shipped with the latest firmware. But BachPhi is saying to just do a firmware upgrade. Are they shipping these new units with just a base firmware now?

OG
 
I suspect VNC will be reenabled at some point with a firmware update. Whatever updates they did behind the scenes probably affected the VNC tool and prevented it from working properly. Doesn't help if you were using VNC and suddenly it is gone.

Question though...Unlike Logix controllers, previous PanelViews always shipped with the latest firmware. But BachPhi is saying to just do a firmware upgrade. Are they shipping these new units with just a base firmware now?

OG

They ship in a similar state as controllers. You must flash the series B PanelViews before you can use them. I stop watched it, this adds ~21 minutes of setup to get to the ME station menu. Might not sound like much, until you have to setup a dozen of them for customers who have been waiting for them.

As BachPhi mentioned, there is a bug in the initial setup, where it wants you to set the IP address, but it won't change from 0.0.0.0. I think if you were to plug it into a network with a DHCP server, it would receive the address, but it is better to just skip it. You have to end up setting it anyway in ME station.

Another weird quirk, PING response is disabled by default. After fumbling through the network weirdness on the first one, we tried pinging it to make sure that the address took. No response. You have to shutdown to the W10 desktop, go into some settings and turn ping response on. It would still accept MER's over a network with this turned off, but it won't respond to a ping command until you do this step.

Also, we're apparently running another lap around the cursor not being able to be turned off.

Edit: I was told by our distributor that eventually, they'll ship with usable firmware and won't have to be flashed out of the box.
 
Last edited:
I ran into this with my first Series B PVP 7 a couple of weeks ago. According to the Knowledge Base, you can't set an IP address out of the box unless the network port is active. I haven't tried that yet because I just replaced the Series B with an older spare when I couldn't get the address set. Honestly, it is so ridiculous that it is hard to believe.

https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1134737
 
So another annoying issue.

I use this new PVP7, Series B, to replace a PVP1000. Iv done this with other HMI's in this process as there are 3 of them, using the same project, the others were replaced with Series A, I'm thinking my issue is related to this somehow.

In my application, I have a string tag. Its called IP_Address_Local and is a Memory tag. Retentive, Initial value is 0.0.0.0

I have a string input enable button on one of my screens.
I set the tag IP_Address_Local here. I set it to 172.16.5.23 for my specific application during runtime to tell the HMI which position in the process its in. This contributes to visibility statements thought the project.

I can set this Tag as I have always done in the String entry during the runtime. However, now when I leave the screen that I set this value on, the value of the Tag IP_Address_Local switches to 169.254.80.77.

I can find no instances of Macros that write to this tag, I can find no Global Connections that point to this tag. I cant find this tag anywhere in the project other than in the visibility expressions that its been purposed for. No other way to writ to this Memory tag that I can find. Yet, its getting this value of 169.254.80.77 from somewhere. This IP address of 169 doesn't exist in our systems anywhere. I'm thinking is some sort of Rockwell DHCP thing, but how is it ending up in my string tag?

This is the exact same application I run on the Series A PVP7 and PVP1000 with no issues. I simply opened my APA, restored it and changed the model of PV.

The PVs IP address is set to 172.16.5.23 as shown in the settings of the unit. Also, it talks to the PLC just fine. Everything works, all the Parameter files are good, all other tags are being read or written to as I far as I can tell. Alarms and security all work.

Any thoyughts?
 
169.254 addresses are not a Rockwell thing, the are what I would call "fallback" addresses (for lack of a better term) where the computer didn't receive an IP via DHCP. Eventually the PC will give up and default to a 169.254 address.

internet said:
An IP address starting in 169.254 is called an APIPA address. Windows grabs one of these when it can’t reach a DHCP server.
 
I'm thinking is some sort of Rockwell DHCP thing, but how is it ending up in my string tag?

No idea how it's ending up in your tag, but it sounds more like Windows then Rockwell. 169.254 is the address range that Windows will assign if it is configured for DHCP but cannot reach a DHCP server.
 
169.254 addresses are not a Rockwell thing, the are what I would call "fallback" addresses (for lack of a better term) where the computer didn't receive an IP via DHCP. Eventually the PC will give up and default to a 169.254 address.

Ok Understood.
I just recognize the 169.254.xxz.xyz from the Micro800's. They go to this out of the box when DHCP is enabled.
 
Ok Understood.
I just recognize the 169.254.xxz.xyz from the Micro800's. They go to this out of the box when DHCP is enabled.

When a device configured to use DHCP fails to obtain an IP address from a DHCP server they will default to what Microsoft called an Automatic Private IP Address (APIPA). I think they started this practice right around Windows 98 or so.

To be clear, most devices will exhibit this behavior. This is not limited to Micro800 products. It is a common practice in modern computer operating systems, but it is also common in most Ethernet connected devices. If they are configured out-of-the-box for DHCP and fail to obtain an address, then we see this result.

OG
 
Note that, in a pinch, it is not overly complex to configure a PC to use a 169.254.0.0/255.255.0.0 address and connect a CAT-x cable directly from the PC to the PLC that has defaulted to the APIPA address, and modify the PLC configuration from there (including setting a static IP for the PLC on the target network).

E.g. for MicroLogix at least, the default configuration is to use BootP, the servers for which are rare. So connecting via a PC-PLC APIPA network and re-configuring the PLC (e.g. to us DHCP on the next power cycle), shaves enough yak hair to bootstrap the process of working with that PLC over the LAN to more familiar ground.

But it is probably easier to either connect the PLC to a network that has a DHCP (or BootP) server, or run a DHCP/BootP server on the PC without changing its network configuration.

Also, if the PC ethernet jack does not do autodetect for the wiring, you may need a special cable, or to connect both to the same switch.
 
So after Rockwell Support spent a bunch a time with my application and situation here. This is what they come back with.

After further experimenting I discovered that if you had the DHCP set to ON then you set it to off and cycle power on the HMI it still acts like DHCP is ON, if you go back and toggle the DHCP to ON then OFF again enter the IP and subnet and cycle power it then seems to work, this was happening on my Series B, it was displaying some unknown 169.xxx.xxx.xxx address too.



See if you can duplicate this, more than likely a Series B anomaly.


I haven't gotten back to test this theory yet...
 
So after Rockwell Support spent a bunch a time with my application and situation here. This is what they come back with.

After further experimenting I discovered that if you had the DHCP set to ON then you set it to off and cycle power on the HMI it still acts like DHCP is ON, if you go back and toggle the DHCP to ON then OFF again enter the IP and subnet and cycle power it then seems to work, this was happening on my Series B, it was displaying some unknown 169.xxx.xxx.xxx address too.



See if you can duplicate this, more than likely a Series B anomaly.


I haven't gotten back to test this theory yet...

There is a little more to this and I will explain. The whole time I was wondering where could the 169 IP address be coming from?

Little did I know, I never noticed, there is an activeX control object on some of the screens that poll the I.P. address from the PanelView. Iv never known it was there, as its always grabbed the address I set in the PV with no troubles at all. Until I grabbed this SeriesB model. The IP address is correctly set in the PV but the ActiveX is returning the 169 from places unknown.

I just wanted to mention that there was the ActiveX writing to my IP address to clarify why my simple String Input to the IP_Local _tag was being overwritten. I haven't used them(ActiveX) before so I wasn't really watching out for it. Also, the object itself sits just outside of the display on the screen so I didn't even see it there without expanding the display window past the runtime size. I wish ME had a cross reference feature. So you could see any reference to the tag just like in Studio.
 

Similar Topics

I have a new job programming PLCs and HMIs after being away from them for ~7 years. I am trying to establish a test setup with an old AB...
Replies
9
Views
3,877
Hi, on some PCs that we use at customer locations and that are running non-critical programs, and are running with 'normal' Windows i.e. not Win 7...
Replies
7
Views
1,896
When I calculate a "rate" it is the amount of time it took to fill a certain amount of something. Please look at this image and explain to me how...
Replies
15
Views
3,598
Hi there. In the past I have read many posts about Advanced HMI in forum. I have a potential project for which Advanced HMI could be used, but...
Replies
26
Views
12,824
Was having trouble w/ a schneider drive intermittently giving me a motor run on. It would hang up on start. It was driving me batty. Increasing...
Replies
2
Views
1,469
Back
Top Bottom