Iacdrive|Automation Solution

Self Excited Induction Generator (SEIG)

The output voltage and frequency of a self excited induction generator (SEIG) are totally dependent on the system to which it is attached.

The fact that it is self-excited means that there is no field control and therefore no voltage control, instead the residual magnetism in the rotor is used in conjunction with carefully chosen capacitors at its terminal to form a resonant condition that mutually assists the buildup of voltage limited by the saturation characteristics of the stator. Once this balance point is reached any normal load will cause the terminal voltage to drop.

The frequency is totally reliant upon the speed of the rotor, so unless there is a fixed speed or governor controlled prime mover the load will see a frequency that changes with the prime mover and drops off as the load increases.

The above characteristics are what make SEIGs less than desirable for isolated/standalone operation IF steady well regulated AC power is required. On the other hand if the output is going to be rectified into DC then it can be used. Many of these undesirable “features” go away if the generator is attached to the grid which supplies steady voltage and frequency signals.

The way around all the disadvantages is to use a doubly fed induction generator (DFIG). In addition to the stator connection to the load, the wound rotor is provided with a varying AC field whose frequency is tightly controlled through smart electronics so that a relatively fixed controllable output voltage and frequency can be achieved despite the varying speed of the prime mover and the load, however the costs for the wound rotor induction motor plus the sophisticated control/power electronics are much higher than other forms of variable speed/voltage generation.

Differences of Grounding, Bonding and Ground Fault Protection?

Grounding (or Earthing) – intentionally connecting something to the ground. This is typically done to assist in dissipating static charge and lightning energy since the earth is a poor conductor of electricity unless you get a high voltage and high current.

Bonding is the intentional interconnection of conductive items in order to tie them to the same potential plane — and this is where folks get the confusion to grounding/earthing. The intent of the bonding is to ensure that if a power circuit faults to the enclosure or device, there will be a low-impedance path back to the source so that the upstream overcurrent device(s) will operate quickly and clear the fault before either a person is seriously injured/killed or a fire originates.

Ground Fault Protection is multi-purpose, and I will stay in the Low Voltage (<600 volts) arena. One version, that ends up being seen in most locations where there is low voltage (220 or 120 volts to ground) utilization, is a typically 5-7 mA device that’s looking to ensure that current flow out the hot line comes back on the neutral/grounded conductor; this is to again protect personnel from being electrocuted when in a compromised lower resistance condition. Another version is the Equipment Ground Fault Protection, and this is used for resistive heat tracing or items like irrigation equipment; the trip levels here are around 30 mA and are more for prevention of fires. The final version of Ground Fault Protection is on larger commercial/industrial power systems operating with over 150 volts to ground/neutral (so 380Y/220, 480Y/277 are a couple typical examples) and — at least in the US and Canada — where the incoming main circuit interrupting device is at least 1000 amps (though it’s not a bad idea at lower, it’s just not mandated); here it’s used to ensure that a downstream fault is cleared to avoid fire conditions or the event of ‘Burn Down’ since there’s sufficient residual voltage present that the arc can be kept going and does not just self-extinguish.

In the Medium and High Voltage areas, the Ground Fault Protection is really just protective relaying that’s monitoring the phase currents and operating for an imbalance over a certain level that’s normally up to the system designer to determine.

Hazardous area classification

Hazardous area classification has three basic components:
Class (1,2) : Type of combustible material (Gas or Dust)
Div (I, II) : Probability of combustible material being present
Gas Group (A,B,C,D): most combustible to least combustible (amount of energy required to ignite the gas)

Hazardous Area Protection Techniques: There are many, but most commonly used for Instrumentation are listed below:
1) Instrinsic Safety : Limits the amount of energy going to the field instrument (by use of Instrinsic Safety Barrier in the safe area). Live maintenance is possible. Limited for low energy instruments.
2) Explosion proof: Special enclosure of field instrument that contains the explosion (if it occurs). Used for relatively high energy instruments; Instrument should be powered off before opening the enclosure.
3) Pressurized or Purged: Isolates the instrument from combustible gas by pressurizing the enclosure with an inert gas.

Then there are encapsulation, increased safety, oil immersion, sand filling etc.

Weather protection: Every field instrument needs protection from dust and water.
IP-xy as per IEC 60529, where
x- protection against solids
y- protection against liquids
Usually IP-65 protection is specified for field instruments i onshore applications (which is equivalent of NEMA 4X); IP-66 for offshore application and IP-67 for submersible service.

SCADA & HMI

SCADA will have a set of KPI’s that are used by the PLCs/PACs/RTUs as standards to compare to the readings coming from the intelligent devices they are connected to such as flowmeters, sensors, pressure guages, etc.

HMI is a graphical representation of your process system that is provided both the KPI data and receives the readings from the various devices through the PLC/PAC/RTUs. For example you may be using a PLC that has 24 i/o blocks that are connected to various intelligent devices that covers part of your water treatment plant. The HMI software provides the operator with a graphical view of the treatment plant that you customize so that your virtual devices and actual devices are synchronized with the correct i/o blocks in your PLC. So, when an alarm is triggered, instead of the operator receiving a message that the 15th i/o block on PLC 7 failed, you could see that the pressure guage in a boiler reached maximum safety level, triggering a shutdown and awaiting operator approval for restart.

Here is some more info I got from my colleague who is the expert in the HMI market, this is a summary from the scope of his last market study which is about a year old.

HMI software’s complexity ranges from a simple PLC/PAC operating interface but as plant systems have evolved, HMI functionality and importance has as well. HMI is an integral component of a Collaborative Production Management (CPM) system; simply you can define that as the integration of Enterprise, Operations, and Automation software into a single system. Collaborative Production Systems (CPS) require a common HMI software solution that can visualize the data and information required at this converged point of operations and production management. HMI software is the bridge between your Automation Systems and Operations Management systems.

An HMI software package typically performs functions such as process visualization and animation, data acquisition and management, process monitoring and alarming, management reporting, and database serving to other enterprise applications. In many cases, HMI software package can also perform control functions such as basic regulatory control, batch control, supervisory control, and statistical process control.

“Ergonometrics,” where increased ergonomics help increase KPI and metric results, requires deploying the latest HMI software packages. These offer the best resolution to support 3D solutions and visualization based on technologies such as Microsoft Silverlight. Integrating real-time live video into HMI software tools provide another excellent opportunity to maximize operator effectiveness. Live video provides a “fourth dimension” for intelligent visualization and control solutions. Finally, the need for open and secure access to data across the entire enterprise drives the creation of a single environment where these applications can coexist and share information. This environment requires the latest HMI software capable of providing visualization and intelligence solutions for automation, energy management, and production management systems.

Automation engineering

Automation generally involves taking a manufacturing, processing, or mining process that was previously done with human labor and creating equipment/machinery that does it without human labor. Often, in automation, engineers will use a PLC or DCS with standard I/O, valves, VFDs, RTDs, etc to accomplish this task. Control engineering falls under the same umbrella in that you are automating a process such as controlling the focus on a camera or maintaining the speed of a car with a gas pedal, but often you are designing something like the autofocus on a camera or cruise control on an automobile and oftentimes have to design the controls using FPGA’s or circuits and components completely fabricated by the engineering team’s own design.

When I first started, I started in the DCS side. Many of the large continuous process industries only let chemical engineers like myself anywhere near the DCS. EE landed the instruments and were done. It was all about you had to be process engineer before your became a controls engineer. In the PLC world it was the opposite, the EE dominated. Now it doesn’t line up along such sharp lines anymore. But there are lots people doing control/automation work that are clueless when comes to understanding process. When this happens it is crucial they are given firm oversight by someone who does.

On operators, I always tell young budding engineers to learn to talk to operators with a little advice, do not discount their observations because their analysis as to the cause is unbelievable, their observations are generally spot on. For someone designing a control system, they must be able to think like an operator and understand how operators behave and anticipate how they will use the control system. This is key to a successful project. If the operators do not like or understand the control system, they will kill a project. This is different than understanding how a process works which is also important.

Electronic industry standards

You know standards for the electronic industry have been around for decades, so each of the interfaces we have discussed does have a standard. Those standards may be revised but will still be used by all segments of our respective engineering disciplines.

Note for example back in the early 1990s many big companies HP, Boeing, Honeywell … formed a standards board and developed the Software standards( basic recommendations) for software practices for programming of flight systems. It was not the government it was the industry that took on the effort. The recommendations are still used. So an effort is first needed by a meeting of the minds in the industry.

Now we have plenty of standards on the books for the industry, RS-422, RS-232, 802.1 … and the list goes on and on. The point is most of the companies are conforming to standards that may have been the preferred method when that product was developed.

In the discussion I have not seen what the top preferred interfaces are. I know in many of the developments I have been involved in we ended up using protocol converters, Rs-232 to 802.3, 422 to 485 … that’s the way it’s been in control systems, monitoring systems, Launch systems and factory automation. And in a few projects no technology existed for the interface layer, had to build from scratch. Note the evolution of ARPA net to Ethernet to the many variations that are available today.

So for the short hall if I wanted to be more comparative I would use multiple interfaces on my hardware say usb, wireless, and 422. Note for new developments. With the advancement in PSOCS and other forms of program logic interface solutions are available to the engineer.

Start the interface standards with the system engineers and a little research on the characteristic of the many automation components and select the ones that comply with the goals and the ones that don’t will eventually become obsolete. If anything, work on some system standards. If the customer is defining the system loan him a systems engineer, and make the case for the devises your system or box can support, if you find your product falls short build a new version. Team with other automation companies on projects and learn from each other. It’s easy to find issues as to why you can’t succeed because of product differences, so break down the issues into manageable objectives and solve one issue at a time. As they say divide and concur.

Industrial automation process

My statement “the time it takes to start or stop a process is immaterial’ is somewhat out of context. The complete thought is” the time it takes to start or stop a process is immaterial to the categorization of that process into either the continuous type or the discrete type” which is how this whole discussion got started.

I have the entirely opposite view of automation. “A fundamental practice when designing a process is to identify bottlenecks in order to avoid unplanned shutdowns”.

Don’t forget that the analysis should include the automatic control system. This word of advice is pertinent to whichever “camp” you chose to join.

Just as you have recognized the strong analogies and similarities between “controlling health care systems” and “controlling industrial systems”, there are strong analogies between so-called dissimilar industries as well between the camp which calls itself “discrete” and the camp which waves the “continuous” flag.

You may concern about the time it takes to evaluate changes in parameter settings for your cement kiln is a topic involving economic risks which could include discussions of how mitigate these risks, such as methods of modeling the virtual process for testing and evaluation rather than playing with a real world process. This is applicable to both “camps”.

The same challenge of starting up/shutting down your cement kiln is the same challenge of starting up/shutting down a silicon crystal reactor or wafer processing line in the semiconductor industry. The time scales may be different, but the economic risks may be the same — if not more — for the electronics industry.

I am continuously amazed at how I can borrow methods from one industry and apply them to another. For example, I had a project controlling a conveyor belt at a coal mine which was 2.5 miles long – several millions of pounds of belting, not to mention the coal itself! The techniques I developed for tracking the inventory of coal on this belt laid the basis for the techniques I used to track the leading and trailing edge of bread dough on a conveyor belt 4 feet long. We used four huge 5KV motors and VFDs at the coal mine compared to a single 0.75 HP 480 VAC VFD at the bakery, and startups/shutdowns were order of magnitudes different, but the time frame was immaterial to what the controls had to do and the techniques I applied to do the job.

I once believed that I needed to be in a particular industry in order to feel satisfied in my career. What I found out is that I have a passion for automation which transcends the particular industry I am in at the moment and this has led to a greater appreciation of the various industrial cultures which exist and greater enjoyment practicing my craft.

So these debates about discrete vs. continuous don’t affect me in the least. My concern is that the debates may impair other more impressionable engineers from realizing a more fulfilling career by causing them to embrace one artificial camp over the other. Therefore, my only goal of engaging in this debate is to challenge any effort at erecting artificial walls which unnecessarily drive a damaging wedge between us.

Home automation concept

The concept of home automation on a global scale is a good concept. How to implement such a technology on a global scale is an interesting problem, or I should say issues to be resolved. Before global approval can be accomplished the product of home automation may need a strategy that starts with a look at companies that have succeeded in getting global approval of their products.

If we look at what companies that have the most products distributed around the world we see that Intel is one of these companies. What’s interesting is that this company has used automation in their Fabs for decades. This automation has allowed them to produce their products faster and cheaper than the rest of the industry. The company continues to invest in automation and the ability to evolve with technology and management. We have many companies that compete on the world stage; I don’t think many of these companies distribute as much product. So to compete at a level to make home automation accepted and to accomplish global acceptance the industry and the factories have to evolve to compete. That mission by the automation can be accomplished by adapting a strategy that updates their automation in their factories, stop using products that were used and developed in the 1970s (another way of saying COTS) and progress to current and new systems. A ten years old Factory may be considered obsolete if the equipment inside is as old as the factory.

Now for cost, when I thank of PLC or commercial controllers I see a COTS product that may be using obsolete parts that are not in production any more or old boards. So I see higher cost for manufacturing, a reduction in reliability. Now many procurement people evaluate risk in such a way that may rate older boards lower in risk for the short term, not a good evaluation for the long term. The cost is a function of how much product can be produced at the lowest cost and how efficient and competitive the company that produces the product. So time is money. The responsibility for cost is the company and the ability to produce a competitive product, not the government.

Now into control systems and safety, if the automation system is used in the house safety has to be a major consideration. I know at Intel Fabs if you violate any safety rule you won’t be working at that company long. To address safety the product must conform to the appropriate standards. Safety should be a selling point for home automation. Automation engineers should get and remember safety is one of the main considerations for an engineer. If someone gets hurt or killed because of a safety issue the first person looked at is the engineer.

Now 30% energy saving in my book is not enough, 35 to 40 percent should be a goal. Now solar cells have improved but the most efficient in the south west US. The Sterling engines are 1960 designs and use rare gases such as helium which may not be a renewable resource, Wind generators need space and are electromechanical so reliability and maintenance needs improving.

Now on to the interface standards, most modern factories that produce processors use the Generic equipment Manufacture standard, good deal works. As far as what and when to uses a standard interface, on BOX produced by one company may use RE-422 where another company may use RS 485 so the system engineer should resolve these issues before detailed design starts. Check with IEEE. Or you may be able to find the spec at every spec.com this is a good place to look for some of the specs needed.

So I conclude, many issues exist, and when broken down home automation is viable and needs a concerted effort and commitment from at least the companies and management that produce products for automation and a different model for manufacturing and growing the home systems.
Home automation with a focus on energy savings as a goal is a good thing. We have a lot of work to ma

PPE (Personal Protective Equipment)

When I think of using PPE as a controls engineer, I think
about electrical shock and arc-flash safety in working with electrical devices.

The PPE (Personal Protective Equipment) requirements to work on live electrical
equipment is making doing commissioning, startup, and tuning of electrical
control systems awkward and cumbersome. We are at a stage where the use of PPE
is now required but practice has not caught up with the requirements. While
many are resisting this change, it seems inevitable that we will need to wear
proper PPE equipment when working on any control panel with exposed voltages of
50 volts or more.

With many electrical panels not labeled for shock and arc-flash hazard levels,
the default PPE requires a full (Category 2+) suit in most cases, which is very
awkward indeed. What can we do to allow us to work on live equipment in a safe
manner that meets the now not so new requirements for shock and arc-flash
safety?

Increasingly the thinking is to design our systems for shock and arc-flash
safety. Typically low voltage (less than 50 volts), 120VAC, and 480 VAC power
were often placed in the same control enclosure. While this is cost effective,
it is now problematic when wanting to do work on even the low voltage area of
the panel. The rules do not appear to allow distinguishing areas of a panel as
safe, while another is unsafe. The entire panel is either one or the other. One
could attempt to argue this point, but wouldn’t it be better to just design our
systems so that we are clearly on the side of compliance?

Here are my thoughts to improve electrical shock and arc flash safety by
designing this safety into electrical control panels.

1. Keep the power components separate from the signal level components so that
maintenance and other engineers can work on the equipment without such hazards
being present. That’s the principle. What are some ideas for putting this into
practice?

2. Run as much as possible on 24VDC as possible. This would include the PLC’s
and most other panel devices. A separate panel would then house only these shock
and arc-flash safe electrical components.

3. Power Supplies could be placed in a separate enclosure or included in the
main (low voltage) panel but grouped together and protected separately so that
there are no exposed conductors or terminals that can be reached with even a
tool when the control panel door is opened.

4. Motor Controls running at anything over 50 volts should be contained in a
separate enclosure. Try remoting the motor controls away from the power devices
where possible. This includes putting the HIM (keypad) modules for a VFD
(Variable Frequency Drive) for example on the outside of the control panel, so
the panel does not have to be opened. Also, using the traditional MCC (Motor
Control Centers) enclosures is looking increasing attractive to minimize the
need for PPE equipment.

For example “finger safe” design does not meet the requirements for arc-flash
safety. Also making voltage measurements to check for power is considered one
of, if not the most hazardous activity as far as arc-flash goes.

OPC drivers advantage

A few years back, I had a devil of time getting some OPC Modbus TCP drivers to work with Modbus RTU to TCP converts. The OPC drivers could not handle the 5 digit RTU addressing. You need to make sure your OPC driver that you try actually works with your equipment. Try before you buy is definite here. Along with some of the complications, like dropping connections due minor network cliches, a real headache and worth a topic all its own, is the ability us tag pickers and the like. The best thing to happen to I/O addressing is the use of Data Objects in the PLC and HMI/SCADA. The other advantage OPC can give you the ability to get more Quality Information on your I/O. Again, check before you buy. In my experience, the only protocol worse than Modbus in the Quality Info department is DDE and that pretty well gone. This still does not help when the Modbus slave still reports stale data like its fresh. No I/O driver can sort that out, you need a heartbeat.

A shout out to all you Equipment manufactures that putting Modbus RTU into equipment because its easy, PLEASE BUILD IN A HEATBEAT us integrators can monitor so we can be sure the data is alive and well.

Also, while you try before you buy, you want your HMI/SCADA to be able to tell the difference between, Good Read, No Read and Bad Read, particularly with a RTU network.