RSView SE 4.0 Issues

Has anyone had an issue with the screens in RSView SE 4.0 refusing to refresh or just acting weird?

For instance, I have some toggle buttons that are pressed and do not change states, when I leave that display and return to it, they have changed. This is an intermittent problem.

Another button which aborts a display causes the cursor to stay locked in a small area until I push the Windows key on the keyboard. This one happens every time.

The HMI is an AB 1200 touchscreen PC.

Thanks

Yes I have seen this too but on a PV+ 1000. I had asked this same question on the forum back in 2006. Was told to try updating the firmware. I was using ver 3.2 at the time. On the PV+ there is a setting for tag update rate. Changing this might help.

I found two .dll files on rockwell knowledgebase that fixed that problem. I can't re-find them. I have them on my laptop at work. If no one can point them to you before monday I will post them.

I got the dll's from work and zipped them, too big for the forum. Zipped each alone, but still to big. Sorry.

As for "The HMI is an AB 1200 touchscreen PC", I take it that you are running a Versaview, not a PV+. I had the same issue with a 1700 Versaview and it turned out to be a bad NIC card. You can also have a bad crimp on the ethernet cable. As for the software, make sure that all PC are set to AB recommendations and up to the current patch level. You can also check the diagnostic viewer to help with the trbleshooting.

Cursor lock up see rockwell I found the answer. ID #4994

demmons said:

Has anyone had an issue with the screens in RSView SE 4.0 refusing to refresh or just acting weird?

Click to expand...

Many times. Usually in banner type displays, but it can happen anywhere if SE doesn't **THINK** something is being used. It orphans updates for whatever reason. My quick fix solution, is to have a button on my main menu that aborts all displays, flushes the cache, and re-opens all home windows.

demmons said:

For instance, I have some toggle buttons that are pressed and do not change states, when I leave that display and return to it, they have changed. This is an intermittent problem.

Click to expand...

Toggle buttons are the devil. DO NOT put LOGIC on your HMI. Use only momentary, or momentary-indicator button objects on the HMI. "Toggle" or "Latching" objects on an HMI are just invitations for disaster. IMHO, an HMI should do only two things control wise., A) READ the current state from controlled/monitored devices, and B) Relay an operators touch (momentary) to controlled devices.
Once you start using "Latched" or "Toggle" objects in an HMI, you are putting control LOGIC in the HMI, which is not a good idea.

demmons said:

Another button which aborts a display causes the cursor to stay locked in a small area until I push the Windows key on the keyboard. This one happens every time.

The HMI is an AB 1200 touchscreen PC.

Thanks

Click to expand...

Absolutely no idea, but that sounds more touch-screen driver issue then an HMI problem. ALTHOUGH, if you abort all windows in SE, well, it can't re-open default ones, so will just sit there, dumb and stupid.

Thanks for all of your input. A couple of notes:

• The PC is a 6181P12TPXP integrated computer, AB's replacement for the now obsolete (I'm told) VersaView.
• I absolutely agree with not using the HMI to toggle, unfortunately this is a customers program and I was instructed only to make sure the tags worked.
• I also like the idea of the abort button to restart the application. (It's like the three finger salute with only one finger

Thanks again for all of your ideas, links, and efforts. I will report back shortly and let you know how I made out.

If you tie the abort command to the button press action, it will lock the cursor in the button area. Try tying the abort command to the button release action.

Thanks for the input everybody.

I uploaded all the patches and put the abort command where it belonged in the button release area. It seems to be working better.

Thanks all.

demmons said:

Thanks for the input everybody.

I uploaded all the patches and put the abort command where it belonged in the button release area. It seems to be working better.

Thanks all.

Click to expand...

That was a good enough point that it should be emphasized... Virtually ALL actions should be of the "On Release" type, if you are using an action button and not a dedicated momentary or other type of PB.

Simply because that means that your operators finger is away from the screen before it does something. Nasty things can sometimes happen if a screen-switch is active "On Press", and in the same spot on a new screen is a button that can cause motion or do something else unexpected.