PLCS.net - Interactive Q & A

PLCS.net - Interactive Q & A (http://www.plctalk.net/qanda/index.php)
-   LIVE PLC Questions And Answers (http://www.plctalk.net/qanda/forumdisplay.php?f=2)
-   -   RSView ME Go To Display button issue (http://www.plctalk.net/qanda/showthread.php?t=123731)

daba February 11th, 2020 08:35 PM

RSView ME Go To Display button issue
 
Hi Guys, I need some help here.

I have an ME project where a "Go To Display" button on my "Log In" display will only work once, after first start-up.

This is doing my head in, there should be no reason why it does not work.

I have put the APA file on dropbox for your comments.

There are 3 log-ins, "operator", "controller", and "maintenance", none of which require a password.

user "operator" has access code A only

user "controller" has access codes A & B

user "maintenance" has access codes A & B & C

The button "Point Control System" is a Go To Display "Opening Main" button, and it has visibility if CurrentUserHasCode( A ), but it will only work once. After a log out, and/or a log-in of another, or the same user, it does not open the "Opening Main" display again.

I cannot see how or why this doesn't work, so any comments would be much appreciated.

ASF February 11th, 2020 11:24 PM

I can't give you a properly satisfying answer, but I was able to replicate the problem and find a solution.

I was testing using the "test application" feature in FTView v11. At startup, as you say, you log in and the button works. When you navigate back to the log in/log out display, the button does not work. It does not even "click" (normally when testing on the PC you can see the button depress as you hold the mouse button down, and some sort of entry is made in the diagnostics log - neither of these happen). The same held true if I copied and pasted the button and removed animation, or created a new button from scratch - all completely inoperable once you navigate back to that display.

This led me believe that the problem lay in the configuration of the display itself, so I went digging there. I found that the log in/log out display is an on-top display and its dimensions are slightly larger than the resolution of the configured HMI. Changing this to a "replace" type display, or reducing the dimensions below the hardware resolution resolved the problem.

I can't say why it behaves that way - perhaps there's something different about how the system calls the initial displays vs how they're called using a go-to display button. One other possible factor is that it appears that all of your displays are numbered zero except the Opening Main display, which is numbered one. I wouldn't have thought that should make a difference either, but when you've got behaviour as inexplicable as this, anything could be a factor.

daba February 12th, 2020 01:18 AM

Many thanks for your reply ASF, and thanks for the time you spent testing.


The "Opening" display is set to 1024 x 768, the same as the configured HMI, I can't see where it may be "slightly larger".



I will try your suggestion to make it a "replace" display later, today I have to go to site for a meeting.

Operaghost February 12th, 2020 09:56 AM

I see the same thing here and without reading ASF post, came to the same conclusion.

Because your Project Settings has the Border checkbox ticked, your actual screen size is 1018x762. Notice the SIEMENS text at the bottom is slightly cut off in Runtime but fully visible in development. So this On Top display is larger than the view-able space. My guess is that when a display goes off screen some objects must be automatically disabled.

OG

Operaghost February 12th, 2020 10:29 AM

Ok wait, I think I figured it out..............

When you are on the "Opening Main" screen and click on the Log In/Out button it is displaying the ON TOP display called "Opening". "The Opening Main" display is still open behind that window. You can't see it because the ON TOP display is fully covering it.

When you click on the button to re-open that display, it can't because it is already open behind the ON TOP display. You need a CLOSE button on the "Opening" display to close it and display the screen behind it.

Or, change the "Opening" display to a REPLACE.

OG

ASF February 12th, 2020 04:56 PM

Quote:

Originally Posted by Operaghost (Post 839991)
Ok wait, I think I figured it out..............

When you are on the "Opening Main" screen and click on the Log In/Out button it is displaying the ON TOP display called "Opening". "The Opening Main" display is still open behind that window. You can't see it because the ON TOP display is fully covering it.

When you click on the button to re-open that display, it can't because it is already open behind the ON TOP display. You need a CLOSE button on the "Opening" display to close it and display the screen behind it.

Or, change the "Opening" display to a REPLACE.

OG

I don't think that's the case - I'm 99% certain that if you have an on top window open with a replace display behind it, you can still press a go to display button and have the replace button "replace" the on top window. Unless, of course, you have the "cannot be replaced" checkbox ticked on the on top window, which is not the case here. At the very least, the button should still allow you to click it, and there should be an entry made in the diagnostics log about "this display is already open". Neither of these occur - the button appears to be completely "frozen" and doesn't make any attempt to perform it's configured command.

Also, if this were true, then simply making the on top window slightly smaller would not have solved the problem - you'd still have the replace window behind the on top window. But resizing the on top display resolved the issue when I tested it.


Good pick up on the border checkbox in the project settings though, I didn't spot that one. I just realised the dimensions were bigger than the allowed screen area because when I changed it to a replace type display, the dimensions were automatically reduced to 1018x762 as you mentioned.

Operaghost February 13th, 2020 10:02 AM

Just verified my results.

I created a new application with a Main display that was an On-top and I created two replace displays (Screen1 and Screen2). Each display had a Goto for the other displays.

When I jumped from Main to Screen1 and then back to Main, the Screen1 button was disabled. But, the Screen2 button worked. If I jumped from Main to Screen2 and then back, the Screen1 button worked but the Screen2 was disabled.

No messages are logged about the display already being open.

The size of the On-top display was never a factor. I started out like daba with a screen only slightly too big. Then brought it down to a small window. No difference.

When I tested Daba's application, changing the size of the On-top did not make a difference. You said that it did. But did you also change it to a Replace? Changing to a Replace was definitely the cure-all regardless of the screen size.

FactoryTalk View SE
Out of curiosity, I did the same setup in FactoryTalk View SE. I saw nearly the same results. The difference being that I could see that pressing the "frozen" button here did work as I could see the command being executed. But the On-top window remained open, covering the display behind it. I could have added another command to have it close the On top and open the Replace. And again, the size of the display made no difference. But here at least I could use my mouse to move or close windows.

OG

ASF February 13th, 2020 04:42 PM

Quite right - I was sure that reducing the size solved the problem, but I've just tried again and as you say it doesn't.

Seems odd, but in any case there's a semi-logical explanation at least \_(ツ)_/

daba February 13th, 2020 08:06 PM

Quote:

Originally Posted by ASF (Post 840178)
Quite right - I was sure that reducing the size solved the problem, but I've just tried again and as you say it doesn't.

Seems odd, but in any case there's a semi-logical explanation at least \_(ツ)_/


This has become somewhat more complex.


What I had tried to achieve was if the currently logged-in user had "Logged Out", then the display changed back to the "Log-in" or "Opening" display, with no user logged in.



This has become a bit of a nightmare, because I can only test the application in a Windows XP environment running FTView version 7. This creates a runtime version 5 while testing, but the final application has to be compiled for a version 4 terminal

Operaghost February 14th, 2020 09:02 AM

I do not envy you there!

:banghead:

OG


All times are GMT -4. The time now is 05:23 PM.

.