Why do some/most Panelview programmers do this?

[gravitar 3]

As I was adding a couple indicators to a panelview 550 last night, I wondered about something. I've seen quite a few people do this, but it seems like a real pain in the neck to me. What they do is, every tag in the panelview is a bit/word in an N file. No matter what it is.. pushbuttons, single-bit indicators, even presets and accumulators for counters and timers. In the SLC they add extra rungs to copy the actual .PRE, .ACC, or whatever to and from the N words. When I want to show a counter's accumulated value on the screen, my tag is C5:x.ACC! When I want to show the state of an input or output, the tag is the input or output address! It would be one thing if it didn't work, but it does. Trust me. I do it every day :) I know you don't have that kind of flexibility with RIO panelviews, but this is on DH485 terminals and I don't think backward compatibility is the motivation here. Do you suppose these guys just don't know any better, like making their lives more complicated, or is there a legitimate benefit to this? I've run into this on several occasions, with machines programmed by different integrators that probably aren't sharing ideas. It definitely slows me down, especially when i have no documentation to refer to..

[Ghettofreeryder 0]

Its easier to troubleshoot when you have all the information being transferred to the panel in one file. That way your not jumping round from file to file

[Eddie Willers 2]

I do that when I'm using DH-485 or DF1 networking because it allows the PanelView to read and write an array transaction instead of multiple network transactions to data table elements all over the controller. That puts the least load on the network, so you can get the best pushbutton and display performance. It's also a good practice so that somebody working on the PLC program knows which data table elements are being written to by the PanelView. I've encountered "mysterious" program behavior in which PanelView changes were being made to data table elements I expected to be static.

[Spedley 0]

It's mostly to do with efficient messaging. Memory is transfered to the panelview in blocks of upto 40 words + the message header (which says where the message is going to etc) Each file or, words more than 40 appart must be sent in seperate messages. At 19,200bps and a scan time of 25ms thats about 60 bytes of info (1 message) per scan cycle. If you have 1 panelview and 10 different address then the they will update every 1/4 of a second (worst case). If you have more panelviews then the problem becomes very significant. Edited 19 May 2005 by Spedley

[jstolaruk 9]

A couple of reasons that come to mind. It helps document the code. By cross referencing the timer or counter preset value, the address that the HMI is writing to will show. It helps facilitate code that allows the operator to set values to a default or by pressing a CANCEL button, the previous value can be restored (provided the logic is present to support it). Its often necessary in batch mode processes to keep multiple values based on the product that is running so tables can be setup and indirect/indexed addressing can be used to store/read the values and put them into the timer or counter. Edited 19 May 2005 by jstolaruk

[Guest Guest_jhopps]

I have wondered about this practice also and here is the reason I beleive it done by so many programmers. Although the Panelveiw reads timer and counter .ACC addresses the Total Control panels do not. By moving these values to Bit or Interger files they save time or make the logic compatible when using their standard subroutines in newer Jobs they are creating logic for customers that request those panels for reduced cost.

[wildswing 0]

I agreee with the others. It makes messaging more efficient. Info is in one location instead of spread out within the PLC. This can become an obvious problem in larger scada projects, slowing down your hmi io update. It also makes it searchable, making troubleshooting easier. Edited 20 May 2005 by wildswing

[kadeschs 0]

I've used this scenario in the past when wanting to save time on programming the PanelView for new but similar projects. Even though the PLC program may change quite a bit from project to project as long as the information gets sent to the proper B word/bit in the end, that's all that matters. I tend to use templates as much as possible. For example, I allocate bits and words in the PLC for common items regardless if I may use them in that particular project. I always know that "side cylinder #1 extended" ends up in b3:1/0 and b3:1/0 is a tag address for the first button on PanelView's cylinder #1 screen. The linking is already done, therefore saving me time to program it in. Also, I:1/0 may not always be side cylinder #1 extended, but b3:1/0 is. This is just an example that can be applied to Timers and Counters as well.

[OkiePC 14]

I agree with all the reasons given. In addition, 1. It's not considered a safe practice to control outputs directly with an HMI. The HMI will fail a lot more often than a PLC. 2. If the data written from the HMI is out of range to a timer or counter, it can cause major errors in the plc which will shut down a process. I always filter input from the HMI even though it may be programmed with entry limits, just for this reason. I've seen RSView, and PanelViews do weird things. If the value is out of range, it's limited or ignored in the PLC before being copied to the PREset or ACCumulator. 3. It's easier to track flow of data from the HMI to the ultimate target device if there is some copying being done in the PLC. I have seen systems where data was written from the HMI to a data table and then block transferred to a motion controller. A search in the PLC code will not find any usage unless there is some sort of copying being done from one interface to the other. These comments apply to A/B products...I have little experience with others. Paul C. Edited 20 May 2005 by OkiePC

[k.dougherty 0]

All of the above; efficient messaging, easy troubleshooting, the ability to restore default values, easy recipe processing and the ability to create templates. As for using the HMI to directly control outputs not being safe; provided the logic is written correctly I see no problem. Am I missing something? Is there a standard practice code (like OSHA or other safety/engineering organizations) that object to this practice?

[OkiePC 14]

I say it's not safe to directly control outputs with an HMI because I've seen too many of them freeze with a bit in a particular state. Most of the time I will use ladder logic to detect and correct this for critical applications. I've seen RSView32 get "confused" and leave a momentary button in the on state. I've seen a PanelView 550 do the same thing. In ten years on this job, I've only seen two SLC50x processors die, but the I/O always went to a safe state. I've only seen one PLC5 failure (the panel was filled with water!) and again the I/O went to a safe state. I've seen dozens of HMI failures, though. Just my opinion, I don't know of any governing body requirement that prohibits HMI controlled outputs.

[pseudoquas 1]

A great question, which is near and dear to my heart. My philosophy of programming follows the following truisms: 1. At some point in the future, some unnamed PLC service guy will be rousted out of bed with an urgent call from the graveyard shift machine operator that a PLC based control system is “not working”. Any attempt to clarify this analysis over the phone is futile. 2. The field service tech rarely has the proper OIT or HMI application software loaded on his laptop. Thus, he is limited to observing the PLC program. 3. QUICKLY scrolling through the program, as thousands of dollars of production time vanishes per minute, the service tech through sleep-deprived eyes sees that the programmer should either be praised to heaven or damned to hell. PRAISED: All elements that are controlled or overwritten by the HMI /OIT are elements of one file and have the form N20:X or N20X/X. This is apparent VERY quickly and should be noted in the descriptor. It is Very clear what is controlled from the field and what is controlled from the HMI. Why is a timer preset at 1 second instead of 300 seconds? A beautiful “MOV” statement clearly shows that there is register in the HMI that overwrites the timer.ACC register. Day shift engineer simply playing with his password protected presets, you explain. DAMNED: B3 bits everywhere driving the logic. Some from internal coils, some apparently from the HMI. Getting a Headache trying to differentiate. What does the operator mean by ‘the cylinder is moving too fast’. Is it a timer issue? Looking at the ladder, there seems to be a timer event before the cylinder. Nothing unusual. Wait, the descriptor for the .ACC register doesn’t typically show up on ladder view. Drill down the Descriptor Database. dang, it is something in the HMI. GRR…sleepy! PRAISED: All elements sent to the HMI / OIT are of the same file type, say N21. Again, VERY apparent in a first glance and reinforced by the descriptor. A persistant alarm, you say? I can just see the Descriptor Database listing of N20:X/X bits to quickly see the list of all possible alarms, even if the operator cannot describe it clearly. DAMNED: Easy job becomes job from Hell: Found that the problem was simply a malfunctioning real I/O point. Easy fix, since there are many spares. Just move the wire to the new point and change all address instances to the new address. Next day, a new call: There is an object on the screen that did not change color like it used to before changing the I/O point. What? There was noting in the ladder that suggested that real I/O is directly associated with some Screen element. Now we have to change the Panelview application software just because of a burned point. Oh…also the Wonderware SCADA system as well. dang that programmer.