Panelview plus 7 is slow and locks machine up.

Recently we upgraded a panelview for a piece of equipment at my job, that originally had a panelview 600 (that worked great) to a panelview plus 7 not so great. (it locks program up, slow to respond with changes on the screen).

The program was designed with DFI serial between PV600 to micrologix 1500 LRP on com 1 , com 2 is set for DFI also and is used to communicate with 3 Powerflex 4 drives. The program has 39 displays with recipes..

The new PVP 7 uses a usb to serial converter to communicate with the Micrologix 1500 LRP.

The displays refresh settings were set to 1 sec. with the conversion, but I have changed them to .25 msec. and it seemed to help but not well enough.

But I am not sure were else to go with this. Any suggestions would helpful.

thiefgold0913 said:

Recently we upgraded a panelview for a piece of equipment at my job, that originally had a panelview 600 (that worked great) to a panelview plus 7 not so great. (it locks program up, slow to respond with changes on the screen).

The program was designed with DFI serial between PV600 to micrologix 1500 LRP on com 1 , com 2 is set for DFI also and is used to communicate with 3 Powerflex 4 drives. The program has 39 displays with recipes..

The new PVP 7 uses a usb to serial converter to communicate with the Micrologix 1500 LRP.

The displays refresh settings were set to 1 sec. with the conversion, but I have changed them to .25 msec. and it seemed to help but not well enough.

But I am not sure were else to go with this. Any suggestions would helpful.

Click to expand...

Look for Gradients in your graphics. Eventhough the PV7+ is supposed to be high end, its graphic processor cannot handle gradient shades. The more gradients on a screen, the slower the screen takes to load.

Thanks for the response!
I don't think that is the problem though, because panelbulider32 doesn't offer that feature and the program was converted from a PBA. file to a MED. file in factorytalk studio.
The problem I seen the other day was when I was scrolling the control list from recipe to recipe it wasn't changing quickly it would take 2-3 seconds to update the screen list, but on that screen it has two things that are happening the recipe name's are displayed as you use scroll up and down(whether it is a recipe or a recipe that is not used and what mandrel it goes with). So I think it is and communication problem or a tag structure in the program.

thiefgold0913 said:

The new PVP 7 uses a usb to serial converter to communicate with the Micrologix 1500 LRP.

Click to expand...

This would be my prime suspect.

Does the PV700 have a serial port?

No it does not have a serial port.

Here is what I would do:

Order a red lion HMI. Download Crimson 3.0 and re-develop the application.

Get a serial cable here.

While waiting for the parts to arrive, you can test the Crimson 3.0 application using its emulator. If you end up using a CR1000 or CR3000 HMI, download Crimson 3.1 and import the file you created with Crimson 3.0. Crimson 3.1 doesn't have an emulator.

When you are done converting to Red Lion, you will probably have to explain to your A/B distributor why you will never buy a Panelview again.

^^^ What he said...

I hear what you are saying, but the company I work for is strictly A/B. When we had a new piece of equipment come in with there new line of panelview component series the company was kind of up in arms with the manufacture of the equipment. Just because it wasn't there standard panelview series and they were unfamiliar with the new line of PVc terminal.
But I like your idea. If I did do the change I would go with a PVc. The biggest obstacle I would have, is how many screens it uses.

One thing that FactoryTalk View does fairly well (and better then Crimson or Indusoft, by two preferred platforms) is communication diagnosis.

I would create a display with the FactoryTalk diagnostic summary object on it, and look for communication or addressing errors. The symptoms you describe could come from just a few syntax or typographical errors that cause the serial driver to stack up with retries.

Back off the Display update rate to 1.0 or 0.5 seconds at first, until you are sure there are no comms errors, then try reducing it. I wouldn't go a lot faster than 500 ms for a pure DF1 serial connection.

That's a good idea Ken. Thanks for the help.

Instead of USB to serial, I would try an AB ENI module, which is serial to Ethernet.

This is follow up and I did what Ken suggested and I monitored it for a while yesterday, but I never seen any errors when the operators would make adjustments or variety changes it was just slow.

OkiePC said:

Here is what I would do:

Order a red lion HMI. Download Crimson 3.0 and re-develop the application.

Get a serial cable here.

While waiting for the parts to arrive, you can test the Crimson 3.0 application using its emulator. If you end up using a CR1000 or CR3000 HMI, download Crimson 3.1 and import the file you created with Crimson 3.0. Crimson 3.1 doesn't have an emulator.

When you are done converting to Red Lion, you will probably have to explain to your A/B distributor why you will never buy a Panelview again.

Click to expand...

Ha. Don't poke fun at AB for this issue just yet.
Like Ken said, the PanelView Plus does a (substantially) better job at giving you diagnostics for comms or operator actions.

I think this post is about bytes/second; which would be an issue for Crimson as well.

Ken Roach said:

Back off the Display update rate to 1.0 or 0.5 seconds at first, until you are sure there are no comms errors, then try reducing it. I wouldn't go a lot faster than 500 ms for a pure DF1 serial connection.

Click to expand...

I agree.
Change the tag update rates to be 1.0 seconds; no faster (no less then 1.0).

Check all of these:
Global Connections
Alarm Setup
Display Settings (for every display)

thiefgold0913 said:

Recently we upgraded a panelview for a piece of equipment at my job, that originally had a panelview 600 (that worked great) to a panelview plus 7 not so great. (it locks program up, slow to respond with changes on the screen).

The program was designed with DFI serial between PV600 to micrologix 1500 LRP on com 1 , com 2 is set for DFI also and is used to communicate with 3 Powerflex 4 drives. The program has 39 displays with recipes..

The new PVP 7 uses a usb to serial converter to communicate with the Micrologix 1500 LRP.

The displays refresh settings were set to 1 sec. with the conversion, but I have changed them to .25 msec. and it seemed to help but not well enough.

But I am not sure were else to go with this. Any suggestions would helpful.

Click to expand...

Most likely the PVP is asking for too much data too fast.
There is a Rockwell KnowlegeBase article on SLC/PLC DF1 serial communications for PanelView Plus which talks about the comms in painfully boring detail.

The short of it is this: bytes per second.
Check your DF1 settings to get your baud rate. Divide by 8 for your bytes per second.
The DF1 protocol is pretty efficient, low overhead. So you can approximate that your DF1 settings for bytes/second is about the actual data of bytes/second that you will get at the PVP.


A simple test to see if you are overloading the comms network:
- place a numeric display on your screen
- point that to a msec timer in your PLC
- run the project and watch the timer on the screen

The msec between updates should = your screen update rate.
So if your screen update rate is set to 1.0 seconds, then your timer should change exactly every second.
I you get anything more that 1000 msec then you are overloading your comms network.
The larger the number, the greater the overloading.


The other item to check is outstanding packets.
In RSLinx Enterprise you should be able to right-click on the DF1 driver (or the PLC) and change the properties.
Try changing that down to 1 outstanding packet and retest.