Wonderware: Pumps on Drive Control Off

Sounds like you are lacking feedback link or experiencing program error....I would also check line in voltages for anomaly...

https://www.youtube.com/watch?v=jOahDrs33VI

Apparently feedback signal on status of VFD is not available to SCADA.

Reason may be one of the following:

1. Not programmed

2. Auxiliary switch feeding the signal to the SCADA not acted

3.cable of feed back signal cut.

Add to 3 items...

4 "Control off" hardware input of SCADA [or more likely, PLC input] problem.

Fault - find by using PLC programmer or SCADA direct I/O facility to confirm volts on/off give change of state correct in ladder rung or I/O & work back, including PLC to SCADA communication to "Control off" contact function OK.

Aim an Instrumentation and Control Technician at it.

That story sounds familiar.

Last week a client who had one of our Railway Power Supplies embedded with SCADA called us, giving contradictory explanations of what he was seeing (he probably did not even know there is an user manual).

One restart of the program and it worked like charm.

Maybe having that local control station in the Ready Mode assumes that you intend to control it from the drive, so the SCADA interface is locked out...

I would look for Remote, as being the opposite of Local, for a mode switch.

You don't say whether this is a new system or existing just gone bad, makes a big difference.

Exactly. It's very difficult to troubleshoot a control system issue without first knowing exactly what that system is seeing for inputs and trying to tell other things to do through its outputs.

If an output is off that shouldn't be, the first step is to account for every input that has say over its actions. If all of that adds up to say it should be on, only then start looking at the software logic.

When I first learned the basics of logic control systems, the #1 rule for troubleshooting an odd problem was to turn the d**n thing off and give it a full reset. Programs, no matter how simple, can and will occasionally get a glitch or fully lock up.

The next step was to confirm that all inputs are doing what they are supposed to do within their limits.

Just with those two steps, a vast majority of system issues can be determined and their sources ruled out.

Beyond those two, that's where looking at the fundamental program I/O logic and confirming that what the software was saying was in fact being done by an output control device came into play.

Fuses/circuit breakers can false trip/indicate their status, Relays and solid state switches on outputs wear out or can be damaged. Network communications output cards/modules can fail for numerous reasons as well.

And, above all, lack of diligent and detailed observation and confirmation of everything by the operator or technician will happen, so get a second set of eyes on the problem if the source of the problem is not showing itself after the first three things on the checklist have been gone over a few times.

It is difficult to diagnose from halfway across the world, but I place my money that the control station is not in correct mode. It sounds indeed like local ready mode (as TCMtech pointed out). See if changing the local control station to remote is better.

where I worked at last one of my peeves with the systems they used was almost everything ran off touch screen interface and most every screen was in a naturally unavoidably dirty environment plus was mounted in a desk type console as well which meant every dirty glove and sleeve and spilled or dripped whatever eventually hit the screens always leading to false icon selecting actions.

The worst part was, although the screens were easily cleaned the method to put the screens into a safe cleaning mode was of course programed as a specific touch icon to get into and out of it so that meant that while cleaning the screen it was very easy to trip the icon and have the screen and the full touch icon menu set pop back up within a fraction of a second giving the screen cleaning wipe down action the 'cat on the keyboard' effect of doing who knew what to what settings or functions before anyone realized they had done it.

Poor physical layout design plus largely having the HMI screen touch reaction times set so fast that there was only the software reaction latency time delay between selecting an icon and reaching its related sub screen and whatever beyond that was dumb.

I have never done a lot of HMI interface programing, yet, but the little I have worked with I always put 'cat on keyboard' filtering delay into icon or user input selection functions.

A .5 -.75 second delay on validating a HMI screen icon or remotely located momentary switch state change input selection cleans up a huge amount of false operator input triggering issues. An operator will not notice that short of delay on most functions but as a technician it solves a huge amount of 'fat fingering' related problems.

We use touch screen HMI in our water purification plant building, and it works OK, not the cleanest barn ever, but not the dirty one either.

The problem is with accessing some of the controls on the edges of the windows are not easy to pick up.