testing panelbuilder32 programs

Is there any way to test a panelview program from the panelbuilder software like you can with the rsview studio software? Or is there a way to access a panelview from a laptop connected ethernet to view the current status of its screens? I have panelviews and processors working fine I am just looking for a way to see a live shot of the screens without having to go underground (coal mine) and stand in front of them. We have had some issues with one pv showing one state of a tag and another pv showing the opposite state of the same tag at the same time.

no.

I agree with Hardwerk. If you can post your PV files and tell us which object and on what screen, we can help you find it.

I would think that if one PV shows a state different from another PV involving the same tag, one of them is not working correct. I would look first at the one not updating i.e. that is not changing states when it should.

Of course it could be a loss of communication and one is going to a default configuration, you may have to watch the program to be certain which is properly updating.

Toggle (Maintained) pushbuttons may display their internal memory of the state rather than that from the PLC. The two displays may be out of sync relative to the PLC.

bernie_carlton said:

Toggle (Maintained) pushbuttons may display their internal memory of the state rather than that from the PLC. The two displays may be out of sync relative to the PLC.

Click to expand...

It is for this exact reasont that I decided long ago never to use these evil screen devices.

Any maintaining shold be done in the PLC. The screen should only report on what the bits and registers are doing. It's number 1 on my HMI suggestions:
http://www.plctalk.net/qanda/showpost.php?p=184338&postcount=2

It's not only the maintained pushbuttons that can be misleading with A/B HMI products. Multistate indicators are another area where the panelview can "lie" to you. It is also my biggest peeve with panelviews.

I started out working with PanelMates which never ever showed me any erroneous values and did not require me to jump through flaming hoops to keep the data accurate.

I still don't understand why a Panelview can't read the values first before displaying any dynamic values. The PanelMate A/B drivers never seemed to have a problem with that.

There are cures (hoop-jumping) for all the PainelViews shortcomings, and most of them involve utilizing the notify and handshake bits and require extra PLC code.

Often, I find panelview applications set up with the "write to controller on power up" bit set to help with this issue, but that can create a whole 'nuther rash of problems. They should also offer a "read from controller on power up" checkbox...

I concur with the advice given in previous posts, scrutinize the use of maintained PB indicators, multi-state indicators, and control lists.

I agree, I've been caught by maintained buttons before. I never use them on PanelView applications. I agree with ndzied1, let the PLC do the latching and maintaining.

rstech said:

I agree, I've been caught by maintained buttons before. I never use them on PanelView applications. I agree with ndzied1, let the PLC do the latching and maintaining.

Click to expand...

At least this was a problem addressed on the PV+