Pipe animation

[Oakley]

My personal opinion...

Animating flow paths in any non-trivial system is a big waste of time and money. It adds very little in terms of function or ease of use. The logic required to animate a complex piping system can quickly exceed the logic required to control that system. Expansions and modifications can put you in a situation where 80%+ of the cost of an update is rewriting the pipe animation. When you put it in those terms, who in their right mind would pay for it?

I can see where an OEM with a system that never gets changed could afford it. They get a lot of re-use out of software development. But if the guy paying the bills gets to see the costs associated with building and maintaining a system with and without pipe animations I think he's going to be a whole lot less impressed with those pretty pictures.

I agree completely.

After being on both sides of the issue, when I worked directly for a specific company, during my slow times, my supervisor had me doing much of this ... and it was tedious.

Now being the supervisor, I don't see much value in it. We have piping color standards (static), and we animate the equipment (pumps, valves, tanks, etc) :
Grey for off or closed
Green for running or open
Red for alarm condition

 

[robertmee]

I agree and disagree....I agree that it is very tedious and the value add may be minimal. HOWEVER, I would not rely on simple color animation either to show process flow. Using Red/Green indicators only are problematic for those that suffer from color blindness. Almost always, we'll supplement color with visual effects, and that usually includes showing process flow with visible lines in the piping. Tedious yes, but makes for a more fool proof system, IMHO.

 

[Oakley]

Using Red/Green indicators only are problematic for those that suffer from color blindness. Almost always, we'll supplement color with visual effects, and that usually includes showing process flow with visible lines in the piping.

I guess I should have addressed this as well, we have a variable text box that changes based on equipment status. The text is standardized as well as the colors.

Just an FYI - Archestra Object Oriented Graphics makes the standardization much easier to maintain. We can standardize and validate a specific graphic, then deploy to the entire application. We don't have to remember everywhere it is used.

 

[n_lev]

My personal opinion...

Animating flow paths in any non-trivial system is a big waste of time and money. It adds very little in terms of function or ease of use. The logic required to animate a complex piping system can quickly exceed the logic required to control that system. Expansions and modifications can put you in a situation where 80%+ of the cost of an update is rewriting the pipe animation. When you put it in those terms, who in their right mind would pay for it?

I can see where an OEM with a system that never gets changed could afford it. They get a lot of re-use out of software development. But if the guy paying the bills gets to see the costs associated with building and maintaining a system with and without pipe animations I think he's going to be a whole lot less impressed with those pretty pictures.

I'll probably have to disagree and agree with you same time
1. My opinion - pipe animation is VERY good for production guys.
2. But it is definitely too expensive and complicated when you do it in a conventional way of tags and scripts.

 

[Dua Anjing]

Do a search for a SCADA called "survalent" they are aimed predominantly at the Power market. They have in their grpahics package the ability to "inherit" upstream conditions. They demo I saw was for a power distribution network but breakers and cables arn't that different from valves and pipes in terms on animating them on a scada

 

[n_lev]

Do a search for a SCADA called "survalent" they are aimed predominantly at the Power market. They have in their grpahics package the ability to "inherit" upstream conditions. They demo I saw was for a power distribution network but breakers and cables arn't that different from valves and pipes in terms on animating them on a scada

Thanks, I'll checdk it out

 

[Dua Anjing]

Tell 'em John from Eltec Energy sent ya

 

[n_lev]

Tell 'em John from Eltec Energy sent ya

Will do

 

[surferb]

What you describe sounds pretty easy to do in FactoryPMI. I really don't see why it should be so complicated with any package. And if you're scripting, you're probably overthinking the problem.

What you should do is come up with the simplest set of inputs to determine the color of each pipe segment. Ie: upstream valve state, hot/cold, etc. This expression would then be the basis for the pipe coloring/hiding/solid colored line through the pipe/etc. In FactoryPMI, it's simply a matter of binding the appropriate property to such expressions. You can probably further simplify by creating your own variables ("dynamic properties" in FPMI) with logic prior to duplicating/mass producing these. I don't see why this approach wouldn't be valid with most SCADA/HMI packages. Am I missing something?

 

[leon.LEE]

You can use use FILL condition to change the colour of pipe.If you have flag of CIP ,Product,sterilize and so on ,use these conditions and valve open or pump running singal to fill the pipe .But i don't think it is a good idea ,The PID picture is more easier more better,i can use a arrow to stand for the pipe is running.haha,just a suggestion!

 

[robertmee]

What you describe sounds pretty easy to do in FactoryPMI. I really don't see why it should be so complicated with any package. And if you're scripting, you're probably overthinking the problem.

What you should do is come up with the simplest set of inputs to determine the color of each pipe segment. Ie: upstream valve state, hot/cold, etc. This expression would then be the basis for the pipe coloring/hiding/solid colored line through the pipe/etc.<snip>. Am I missing something?

Perhaps....In a complex system the logic becomes more involved the further downstream you migrate in the process. You can't simply rely on the state of the upstream valve. As a simple example, you may have valve A which diverts flow to B and C. Therefore, the output of B's pipe does not depend on the state of upstream valve B, but on the state of A AND B. Now suppose, there's another valve D that feeds B. At this point the output flow of B depends on the state of (A OR D) AND B. When you have four or five of these diversions plus pumps in the mix, then the logic becomes progressively more complex and the scripting IS tedious. Although, 'scripting' is a misnomer as it is really a condition of the fill, visibility, motion or whatever attribute de jour you choose to animate your piping.

If the process was simple and only progressed through on/off (flow/no flow) then you could come up with a single script that applied to all your animations. If you determine that the process is at most 5 deep, then you could have a script that is COND1 AND COND2 AND COND3 AND COND4 AND COND5 and simply substitute the appropriate tags for the conditions. In the case of a single valve, COND2 through COND5 you would assign an ALWAYS_TRUE type tag. As you progressed, then you change more of the COND tags to true I/O tags. The problem arrises with a complex system of diverter valves that add ORs into the mix. It's likely not practical to anticipate a single AND/OR equation to cover all the scenarios and you are back to hand coding each.

In the case of AND/OR I suppose you could anticipate again the deepest level and arrise at (COND1A OR COND1B) AND (COND2A OR COND2B) .... (COND5A OR COND5B). In the case of diverter valves, substitute the approprate A or B I/O tag. In the case of an on/off valve, substitute the OPEN condition for both A and B. I don't know if that would actually save any time or not as you would be simply cut/paste the same animation and doing tag substitution. It might however cause the next person to come behind you to look at it cross-eyed and wonder WTF

 

[Oakley]

1. My opinion - pipe animation is VERY good for production guys.

I have a fundamental problem with automation going to a great extent to make it easy for production guys. The production guys should be qualified on the systems they are working on. They should be able to look at a screen and observe the pump stats, the valve stats, etc. and know what is happening.

When something goes bad, and the pipe animation stops working because of a up stream valve, then it is "Automation's fault". When this occurs, then they become too reliant on Automation to do their troubleshooting.

Just my 2 cents worth.

 

[MartB]

In almost every installation I am dealing with people that are under qualified to work on the equipment, have little or no knowledge of the process they are working with and rely totally on a system that is self correcting (where possible), and able to communicate problems or errors with ease to somebody the first time they use it. It should also be able to indicate the best course of action to correct the fault.

Over time, operators will learn the system well enough to be able to operate it without the use of a graphical display, but depending on the system, this can take months or years in some cases.

In my experience, there is no such thing as a qualified operator, simply some that are more experienced than others and I feel that it is in my best interest to program my equipment accordingly (I don't like phone calls).

If it takes an extra week to make the system as self correcting as possible (I try to avoid the term "idiot proof"), then I consider it time well spent.

Just my 2c worth.

 

[cjd1965]

In almost every installation I am dealing with people that are under qualified to work on the equipment, have little or no knowledge of the process they are working with and rely totally on a system that is self correcting (where possible), and able to communicate problems or errors with ease to somebody the first time they use it. It should also be able to indicate the best course of action to correct the fault.

Over time, operators will learn the system well enough to be able to operate it without the use of a graphical display, but depending on the system, this can take months or years in some cases.

In my experience, there is no such thing as a qualified operator, simply some that are more experienced than others and I feel that it is in my best interest to program my equipment accordingly (I don't like phone calls).

If it takes an extra week to make the system as self correcting as possible (I try to avoid the term "idiot proof"), then I consider it time well spent.

Just my 2c worth.

I agree with this.In my experience more companies are employing cheap labour (and usually dumb labour) to operate the equipment so it is neccesary to provide suffiecient interlocking and HMI screen information so that ANYONE can make reasonable assumptions about the process. Yes, I agree it takes a while to do but there is pay backs with uptime /productivity. / reduced scrap. Animating every pipe maybe overkill but I always try and animate enough of the process mimic displays so it is fairly obvious.

 

[robertmee]

I have a fundamental problem with automation going to a great extent to make it easy for production guys. The production guys should be qualified on the systems they are working on. They should be able to look at a screen and observe the pump stats, the valve stats, etc. and know what is happening.

When something goes bad, and the pipe animation stops working because of a up stream valve, then it is "Automation's fault". When this occurs, then they become too reliant on Automation to do their troubleshooting.

Just my 2 cents worth.

I have to respectfully disagree...

The nature of the beast is that manufacturing is running lean, with minimal operators and support staff and management expects quick learning curves on new systems implemented. To that end, to expect an operator to be 'qualified' and know a new system (whether a new install or new to them) in/out without troubleshooting aids is not very proactive. An HMI should be intuitive and pipe animation, IMHO, greatly helps that. If I have a process flow of 12 valves that dump into tank Z, I shouldn't have to scan the status of 12 valves to determine if in fact my flow path is correct. I should be able to look at tank Z, see the pipe animated indicating flow, and know that all the valves are in the correct position.