Issue with Goto Display in MAIN - FTVS

[jkerekes]

This is really crazy. Does the button depress initially before you login?

 

[kandymann]

This is really crazy. Does the button depress initially before you login?

haha I know. It really is.

Yes, it depresses before you log in but nothing happens like it's supposed to bec no one is logged in. Once you login, it depresses and you are on the OH screen. Go back to the MAIN screen, it will not depress.

This is driving me insane. I deleted the Goto button and made a new one. Same thing happens. It makes no sense. I created a similar application a little while back and it worked flawlessly. I never had this issue with a goto button on the MAIN screen.

Sigh

 

[kandymann]

Are you using FTV Machine Edition or Supervisory Edition?

On FTVME there is no Enable feature, so the best option is using the Visibility. I always draw a dummy button behind the real button.

If you use VBA code (FTVSE), you need to enable/activate the Operator Hub button when:

a) A user executes a login/logout action.
b) The main screen is invoked.

This is really crazy. Does the button depress initially before you login?

I figured it out.

The displays Display Type were set to 'Replace' instead of 'On Top'.

Now it works just fine.

 

[jkerekes]

So the focus of the active screen was different than what it appeared to be? Can you give more details?

 

[ASF]

Set the diagnostics screen up to be always active, and see what entries you get when you press the button the first time, and then the second time. Post a screenshot highlighting both instances, and we can probably be a little more targeted in our suggestions, rather than just pot shots. Also, confirm that both the OH button and the Main button on the OH screen are Go To Display buttons and not macro buttons or something else.

But seeing as we're all taking pot shots, three of my own guesses at to what might be happening:

1. As others have suggested, there are two "buttons" that look identical, one on top of the other. One of them is a GoToDisplay button that opens the OH display; the other does nothing. Something is triggering the visibility (or potentially even size or position) of one of the buttons - it could be that the non-reactive button is appearing on top of the real button and blocking you from pressing the real button, or it could be that the real button is disappearing and leaving behind the non-responsive button.

2. Something is writing to your "replace display number" global connection, which will block you from selecting any screen while the number is non-zero. This one is quite plausible, and you should see a message about this in the diagnostics list if it's the problem.

3. I had an application recently where if a datalogging activeX control failed to start, the whole screen froze. Nothing would work at all, and buttons wouldn't even animate being pressed. Is it possible that you're triggering something when you come back to the main screen that's getting your HMI tied in a knot? The easy way to test this one is to create a new go to any screen button way away from the existing buttons, and see if you have the same issues. Of course, if pot shot #2 is correct it won't work either - but of course, you tested that one out first, so it's not that

Good luck!

[edit] you're all a lot quicker than me this morning. But having said that, this should all still work using replace displays - I'm beginning to suspect that my pot shot #2 was the issue, and that the only reason it works now is that the "replace display number" global connection only works on replace-type displays. So you just broke that functionality to fix your problem.

I'd be checking out the global connections, and seeing what writes to them - you may have bigger problems to deal with...

 

[kandymann]

[edit] you're all a lot quicker than me this morning. But having said that, this should all still work using replace displays - I'm beginning to suspect that my pot shot #2 was the issue, and that the only reason it works now is that the "replace display number" global connection only works on replace-type displays. So you just broke that functionality to fix your problem.

I'd be checking out the global connections, and seeing what writes to them - you may have bigger problems to deal with...

Thank you for the reply. Very much appreciated. I must admit I am not a seasoned FTVS ME designer. I had to teach myself how to use the software. I am also aware that simply making something work does not imply that it is correct.

Could you elaborate more about how this will work with replace displays? My global connections has no tags assigned to the display. I am ignorant here I must admit. A little explanation would be very helpful and appreciative.

This application will be used locally only. No remote control will ever be used here.

Thanks again

 

[ASF]

If there are no global connections assigned then my fears are unfounded (except the "afraid of things I don't understand" one, because I don't understand why it didn't work and now does! )

Quick spiel on the display types and remote connections:

An on top display is a display that opens over the top of another one. The previous display is still open behind it. Generally, these are used for popups. If you make them the full size of the screen, they will appear to act just like replace displays, but all of your other displays are still open behind them. It's best practice not to use these for all you "full screen" displays because things like "previous display" buttons only work on replace type displays, and you may load the PVP processor up with updating all of the displays behind the one you can see continuously (don't quote me on that second one, I've not seen any official warning of such, but it would make sense to me).

A replace type display replaces the current display when it is called. This is what you should generally use for all your full screen displays. There are exceptions of course, but for the most part it applies.

In your global connections, you have two connections you can assign to do with the displays. Well, possibly more, but two that I'm interested in here.

Your "Replace Display Number" is not, despite what you might well assume, a command to replace the display with display number x, rather it is an indication of the current replace-type display. You can use this to tell your PLC which display is currently showing on the PVP. Of course - this only works if you're using replace-type displays, which is another reason to use them where possible.

The "Remote Display Number" is a connection that you can assign which will command the PVP to select display x. If you set this tag to 1, the PVP will display screen 1. If you set it to 7, it will display screen 7. This can be used to, for example, have your PLC bring up the alarms display when a new alarm occurs.

There are a few tricks to getting this working properly, and you must remember to set the Remote Display Number back to zero once you're done or the PVP will be stuck on that screen and unable to go anywhere else. But if you're not actually using that, not your problem - just something to keep in mind if you ever do.