Pipe animation

[Oakley]

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.

And what I was eluding to before, as soon as that valve fails, then they are going to blame automation rather than searching for the failure. I just believe that there is a fine line between doing enough animation to sufficiently depict the process and doing too much and the process getting lost in the animation.

Basically it comes down to user requirements, automation standards, and money. Personally I am not willing to pay for the level of detail that, once again in my opinion, the process gets lost in the animation. Our screens have static piping colors (defined per process) with animation on pumps, valves, etc. They are clear and consise - easy to read and understand process flow.

 

[surferb]

Of course this problem can get as gnarly as you make it. However, I think you're overcomplicating the hell out of the implementation. Assuming that your system travels in the same direction, you simply go "1 layer deep" and base your expression on the condition of the upstream pipe segement and relevant valves, diverters, etc. Sure, you could expand a single segment to "5 layers" how you described them, but it may only be 2 or could be 10. This sort of kinda-recursive definition greatly simplifies your expressions, plus allows you to make changes/corrections without screwing up everything downstream (or as many layers of accuracy as you've chosen). This approach ends up evaluating the same expressions, but without needing to keep track of and re-write the same ones over and over.

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....

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

I was very careful to not use the term 'scripting' - I opted for expressions. I specifically mentioned that accomplishing this in script is a mistake.

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.

 

[surferb]

Big user education issue! I don't see how animating pipes has any impact versus just using an automated system.

And what I was eluding to before, as soon as that valve fails, then they are going to blame automation rather than searching for the failure.

Great point! That acceptable 'gray zone' varies from user to user. Also, a well written application will tend to shift that point for users - in other words, animation can be used to convey more info without being too distracting if done properly.

I just believe that there is a fine line between doing enough animation to sufficiently depict the process and doing too much and the process getting lost in the animation.

Again you nailed it! Keeping standardized is usually more important that what conventions you've chosen - as long as everyone is in the loop. Ultimately the "easy to read and understand process flow" is the only important detail. If your operators can, with a short learning curve, understand/visualize the process with a glance at the HMI then you did your job right!

Basically it comes down to user requirements, automation standards, and money. Personally I am not willing to pay for the level of detail that, once again in my opinion, the process gets lost in the animation. Our screens have static piping colors (defined per process) with animation on pumps, valves, etc. They are clear and consise - easy to read and understand process flow.

 

[MikeB]

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.

How about spending the time taken to write this animation logic and instead write some proper AUTOMATION code that continually checks selected path which will halt the process and alarm when a incorrect valve position is detected.

Pipe animation is total fluff.

 

[robertmee]

How about spending the time taken to write this animation logic and instead write some proper AUTOMATION code that continually checks selected path which will halt the process and alarm when a incorrect valve position is detected.

Pipe animation is total fluff.

That goes without saying as any seasoned integrator includes all the appropriate alarms and checks for process flow. My reference was to current STATUS of a complex system, not that the current system is operating properly. When you have a complex system of several sources and several destinations with branches in between, pipe animation goes a long way towards aiding in visualization of the current STATUS. There are deficiencies in common alternate methods:

Color (color blind operators)
Text (illiterate operators)

As for your comment of fluff, that my friend is not your decision to make, but the customer's. To most of my customers, pipe animation is a supplement to the above and makes process flow understanding intuitive for an operator, supervisor, technician or even a floor visit by the plant manager. Sure it is tedious to implement, but to call it 'fluff' is fairly harsh and insulting, IMHO.

 

[CowDung]

I've seen a couple of ways that make the scripting a bit easier. The first method paints the pipe when the valve upstream and the valve downstream are open. They didn't bother with the various combinations that might occur upstream. It is quick and easy, but the disadvantage is that the lines will still show flow if the supply pump fails.

The other method uses the upstream flow visibility as the first condition of the visibility rather than duplicate all the conditions that would make the upstream line visible. Basically the scripting goes as: If FlowPipeA = visible and ValveB = open then FlowPipeB = visible. If FlowPipeB = visible and ValveC = open then FlowPipeC = visible. I believe that this method is what surferB was describing above.

We would use a separate color animation that would determine the color of the flow line--CIP, product, water, etc. depending on what process was currently active.

 

[kdcui]

As I mentioned in an earlier post, I just got done animating a rather large SCADA in iFix (about 40+ screens at 1280*1024).

The pipe animation was rather simple, and everything was driven entirely from the PLC in a pipe animation routine.

We made constants for different media ( water = 2, CPI =1, steam = 6, etc...) and used this constant at the "source." Then this value was progressively passed to subsequent pipes, depending on a valve being open or closed, a tank being filled, etc..

Each pipe was given a tag, in two parts which indicated the device/intsrument it was going to, and what "direction" it was coming from. Our pipe array looked like:

PIPE[100 ,2] where the first index (100) is the device number of the destination valve, VFD, etc.. , and the 2nd index (2) in the "direction" on screen it was incoming (1=left, 2=top, 3=right, 4=bottom).

Of course, when you have a large system, this means that you need to have a tag in the database for every single pipe, which can get cumbersome. But logic was simple, and was a matter of copy and pasting, and simply changing the device number.

I wonder if there is a way to use some SFC to accomplish animation in a more efficient manner.

 

[n_lev]

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.

You are talking about ideal world, aren't you?

 

[Dua Anjing]

I would have thought that the part of the purpose of automation was to assist production and to make their job simpler to allow them to improve process/profitabilty.

 

[mellis]

I would have thought that the part of the purpose of automation was to assist production and to make their job simpler to allow them to improve process/profitabilty.

That's exactly what I am saying...

And I don't think anyone is suggesting different. The discussion is about the cost/benefit ratio and if the technique delivers the value for the cost. I believe there are situations where it can. OEM systems where you get to benefit from multiple reuse of the same software and relatively simple systems.

Something that is very important to my belief that it is not cost effective in non-trivial systems is the cost of maintaining the system. If I could implement the pipe animation once and be done with it, I would be able to consider it more often. However, in the real world projects I'm involved in, that simply isn't the case. Change is never ending. I have seen systems that started out with pipe animation that were simply overwhelmed by changes. Once the animation no longer reflects reality, it is of no benefit. I can achieve the same goals, this isn't the only tool to communicate status.

 

[cjd1965]

This thread has been quite interesting with lots of opinions.

Ultimatley, provided the HMI package delivers the goods in terms of displaying the process and alarming when required, that is what is needed.
I worked for a customer where a single batch of product was £50,000 (approx $100,000 US) so they were happy to pay for 'the ultimate' in graphic display so they could fully observe the process on the HMI.

At the end of the day it is upto the end user to specify what they require, and how much they wish to pay for it.

Cheers

 

[Oakley]

You are talking about ideal world, aren't you?

In the industry I am currently working, we are regulated and we have qualified employees for all tasks. This qualification is per job description, so I have a high confidence that our operators can discern process flow.

If you have operations and maintenance that is not qualified, then that is a safety issue.

An ideal world would be great - too many times do companies throw the low cost element into the equation.

 

[MikeB]

That goes without saying as any seasoned integrator includes all the appropriate alarms and checks for process flow. My reference was to current STATUS of a complex system, not that the current system is operating properly. When you have a complex system of several sources and several destinations with branches in between, pipe animation goes a long way towards aiding in visualization of the current STATUS. There are deficiencies in common alternate methods:

Color (color blind operators)
Text (illiterate operators)

As for your comment of fluff, that my friend is not your decision to make, but the customer's. To most of my customers, pipe animation is a supplement to the above and makes process flow understanding intuitive for an operator, supervisor, technician or even a floor visit by the plant manager. Sure it is tedious to implement, but to call it 'fluff' is fairly harsh and insulting, IMHO.

Well sorry if i was a bit harsh...but I stand by my opinion. Clearly 2 very distinct views on this type of animation and I believe all our minds are very much made up. If I have a customer who thinks they want "supplemental animation" I always seem to be able to convince them to drop the idea. edit: i had started listing my reasons but no point all have been covered by my like minded friends..Mellis and Oakely.

Who thanks you when you've left site for this animation...

The operator - 2 days looking at colored pies, spinning fans or boxes moving along a conveyor and they are over it.
The tecnician - it not going to find a blocked pipe or a broken valve actuator. And when time comes for him to add a small plant expansion he going to love sorting thru the PLC logic and scripting buried in the HMI.
The plant manager and VIP's - on handover day the all say look at those great graphics...while the smart ones are thinking what did this cost and the rest are just wanting to get up to the boardroom for lunch.

 

[n_lev]

Who thanks you when you've left site for this animation...

The operator - 2 days looking at colored pies, spinning fans or boxes moving along a conveyor and they are over it.
The tecnician - it not going to find a blocked pipe or a broken valve actuator. And when time comes for him to add a small plant expansion he going to love sorting thru the PLC logic and scripting buried in the HMI.
The plant manager and VIP's - on handover day the all say look at those great graphics...while the smart ones are thinking what did this cost and the rest are just wanting to get up to the boardroom for lunch.

Tha goes directly to my humor mail list

 

[robertmee]

Well sorry if i was a bit harsh...but I stand by my opinion. Clearly 2 very distinct views on this type of animation and I believe all our minds are very much made up. If I have a customer who thinks they want "supplemental animation" I always seem to be able to convince them to drop the idea. edit: i had started listing my reasons but no point all have been covered by my like minded friends..Mellis and Oakely.

Who thanks you when you've left site for this animation...

The operator - 2 days looking at colored pies, spinning fans or boxes moving along a conveyor and they are over it.
The tecnician - it not going to find a blocked pipe or a broken valve actuator. And when time comes for him to add a small plant expansion he going to love sorting thru the PLC logic and scripting buried in the HMI.
The plant manager and VIP's - on handover day the all say look at those great graphics...while the smart ones are thinking what did this cost and the rest are just wanting to get up to the boardroom for lunch.

You're probably right that no-one's opinion will be changed. However, I don't think spinning pies and boxes moving along a conveyor are equivalent comparisons. I can visually look at a plant floor and see boxes moving down a conveyor. I don't need animation to show me that. The same goes for a moving fan. However, unless you are using transparent pipes, then you cannot look in the ceiling and see process flow through the pipe or easily see the position of a valve. So your comparisons are weak and not applicable. I am certainly in agreement that over abundance of animation and pretty pictures are not usually worth the time and effort when processes may be visualized in much simpler formats. However, I'm of the opinion that process flow in a pipe is a simpler format and conveys alot of information with a brief glance at the HMI screen.