PANELVIEW 600 SCREEN LIST

[stickman47 0]

Gents, I am trying to put together a t-shooting system for our Electricians using a PV-600. The concept is to have a list of common problems, and their solutions, by showing key program elements as graphic displays. For instance, Screen 1 has output 1 shown as an indicator to represent Automatic Mode. Other indicators represent the elements necessary to turn on automatic Mode. I can represent each element through a seperate screen and use F10 as a "return to previous", but that only works if I go from screen 1 to screen 2 and back again. If I need to go from screen 1, to screen 2 and then to screen 3, when I try to go back I get trapped in a loop between screen 2 and screen 3. Some of these screens will get very involved in sub-screens. I was thinking of creating a memory block in the plc to keep track of the screen numbers and then use the list that was created to follow my route backwards. Is there an easier way? does Panelview have a better method?

[neilr216 2]

How about creating a main menu with all the screen selections and each selected screen has a return to menu button?

[BobLfoot 301]

If I understand you correctly then you have Screen 1 which is a menu of screens, and a series of sub screens which the Electrician can browse down and hopefully back to follow a chain of thought. My concept is this Each Panelview screen you define will have the following buttons A Main Menu Return Button and a Return to Parent Button. Now this is easy unless parent screens share children. In that case rather than use the goto screen button for the goto parent feature you'll need to do it in the PLC. Since you'll go down several layers you'll want a FIFO and usr FFL/FFU of screen numbers as you broswe. Your concept sounds good it will just be a bear to program. BUT THAT"S WHY WE GET THE BIG BUCKS <LOL>

[Mike Lamond 1]

I think you want to use a LIFO to capture screen history and I don't know why I never thought of using it in an HMI before, other than never needing to backtrack in this manner. I don't think that the programming is that big a bear, though. Let's see if this makes sense to anyone else: 1. Clear the PanelView screen control register (N7:100 in the sample) in the PLC if it is not zero for two seconds, returning screen control to the PV after the PLC forces the screen number. (Borrowed from someone else, thank you.) NEQ N7:100 0 TON T4:100 2 0 EOR XIC T4:100/DN CLR N7:100 EOR 2. The sub-screens (children) are selected in the PanelView by Goto Screen buttons. When the screen number status (N7:101) changes, load the previous screen number (N7:102) into the LIFO (file starting at N7:110, control R6:100) and save the current screen number to the previous screen. Adjust the size (20 shown) as needed. In Version 7.10.00, the LFL/LFU help page lists both 34 and 128 words as the maximum stack size! The screen control reset timer done bit disables the load on a forced screen change. NEQ N7:101 N7:102 OTE B3:100/0 EOR XIC B3:100/0 XIC T4:100/DN BST LFL N7:102 #N7:110 R6:100 20 0 NXB MOV N7:101 N7:102 BND EOR 3. The Return to Previous (parent) button (B3:110/0) triggers a LIFO unload to the screen control register. XIC B3:110/0 LFU N7:100 #N7:110 R6:100 20 0 EOR I don't have a PLC and HMI handy to test this, so let me know if it works. Mike

[BobLfoot 301]

Nice job taking the idea to the next level Mike. I read it over twice and I think it should work for him. Hope he gets to test it and let us know.

[stickman47 0]

Bob, What you had is what I was thinking but Mike certainly has a better plan. It will be a bear to program as the children will have children, like browsing through the ladder with a laptop, only using the HMI to do it. I tried to make a tree to represent following one aspect but I got lost myself. Once I can get a trace on paper I can start developing the code for the file. I looks like the file code may take more space than the origrnal ladder... Thanks to all, Stickman

[stickman47 0]

Mike, In reference to using the HMI as a t-shooting device, I have attached a PVB file of a VERY simple set-up that we use on an uncoiler/end welder. It has reduced the number of times I am called since the Electricians can pretty much see what the problem is. My current project is on a strapping maching that used minimal I/O but is heavily dependent on bit relays to control the sequence. Hope you enjoy 3_P_Welder_REVISED_2_21_07.PVA

[stickman47 0]

Gents, Here is where I am currently. It's not finished but I have been stuck on another project for a while... I hope these attachments are getting through... bander.PVA MAIR_SIGNODE.RSS

[paulengr 44]

I never did it that way. I always used the goto function to select specific screens, and then made all my "goto" buttons global objects. Then I can just turn them on/off as needed for various screens. Although you can certainly use the PLC to control which screen is visible, you will find that the reaction speed of PV->PLC->PV is much slower than you'd expect. Your best "panelview users" will notice that things lag a bit when you do this. It works and when you HAVE to control the screen remotely, it's the only way to do it. Also, any "goto screen" buttons no longer work once you use this, but once you get over it, it's not that bad. An idea to consider from the PV+ sample screens is to have a bunch of on-screen extra indicators that show the troubleshooting info you want but normally make the screen so cluttered that they are useless. Just turn them on/off with a single button. This will require multistate indicators since when they are "inactive", there is no transparent color. You have to make them the same color as the background to make them "invisible". I also found out over time that the "goto main menu" button is a REALLY bad idea. It gets used heavily when you have a main menu and operators are routinely jockeying around in various screens. The end result is that the button wears out prematurely and you have to pay for a replacement panelview periodically. It's also a good thing to think about as far as screen design goes anywhere with a Panelview. If you can, try to think of ways of spreading out the button usage so the same buttons don't get constantly hammered.