Posted by: Harold Ennulat | May 13, 2013

Control Panel Layout And Wiring Best Practices.

Control Panel Layout And Wiring Best Practices.


Large Control Panel Wiring Example. What are some good practices?  What could be improved? Click to enlarge

Large Control Panel Wiring Example.
What are some good practices? What could be improved?
Click to enlarge

The quality of the wiring methods used in an industrial control panel can vary quite widely.  This article summarizes what this author believes are some best practice when it comes to control panel layout and wiring.

The goal is to produce a panel that is logically arranged and easy to maintain for the life of control panel.

I leave it to the reader to use these suggested “best practices” outlined below to evaluate and improve upon the control panel designs that they encounter or are part of producing.


  1. Wire:  Use all 600V 90 Deg C rated wire.  Use stranded wire.  Use MTW type wire.  Note any exceptions so these can be added to the drawings or design notes.
  2. WiringAcrossAHingeBestExample1croppedWiring across a hinged door or panel.  U loop, as long as possible, facing down anchored on each side of the hinge with screws or bolts (no adhesive). Place sleeve or spiral wrap over the wires running over the hinge between the anchor points.
  3. Spacing between wired devices and wireway or other obstructions:  2″ minimum; 2 1/2 – 3″ preferred for 120VAC and less.  4″ for 480 volt (enough to insert a closed fist between the device and the wireway or obstruction.
  4. Minimize the use of cable/wire ties if wire duct is used.  They get cut off when troubleshooting and are rarely replaced.  A good wire management system should not require any wire ties.  Make it a goal to use no wire ties except temporarily while wiring.
  5. *  Leaving Slack:  Generally, leave only “hidden” slack.   Leave service loops as the wires leave or enter the device or terminal.  Run wires in the wireway so they enter and run to the middle or far side of the wireway or duct.  Take all corners in a wiring duct as wide as possible.   Run wires in horizontal and vertical lines.  This also adds further “slack” and improves the appearance.  Avoid looping wires in the wireway unless the wireway is designed for this.
  6. General Wire Routing:  Run wires in horizontal and vertical lines, no diagonal runs.  “Train” the wire by bending it to make neat vertical and horizontal lines.  Delicate wire will require “training” by bending and forming the bend gradually.  Wire in wire duct should be run so they do not cross each other excessively.  Wire entering or leaving a wire duct should be brought to the front of the duct before entering/exiting where possible.  Leave service loops and run wires in the wireway so they enter and run to the middle or far side of the wireway or duct and take all corners as wide as possible.  Do not run wire over other devices, including the wireway.  Elevate the duct and go under the duct with wires if needed.  Review needed exceptions.
  7. Wiring Power And Motor Wiring:   Place Pig tail loops between devices that are spaced such that it makes it easier to remove wiring if the pig tail is added.  Consider using High Flex power wires such as “Railroad Wire” or high strand count wire.  Train the wire by bending it in the direction you want it to go or lay in the duct, rather than just trying to lay it in a wire duct and hope it “stays down” in the duct.  See also “General Wire Routing”.
  8. Wiring Signal and Shielded Cables:  Use 18 AWG shielded, twisted pair (or Triad) type cables rated at 600V as the default signal wire type.  Unless specifically required strip off a generous amount of the jacket so that each conductor can be easily accessed for removal, testing, and replacement.  Also remove the jacket as it exits a wire duct, keeping the twists where the cable otherwise creates unwanted wire congestion.  Examples:  going to Analog I/O modules, or routing to elevated side terminals.  Terminate all shields.  Terminate all shields close to the signal wires.  Consider using 2, 3, or even 4 high terminal blocks with jumper slots for signal wiring depending on the wiring needed.  This allows busing the power supply voltages for a cleaner installation.  Option:  Place heat shrink tubing 1/2 over the cut end of the cable jacket and 1/2 over the exposed wires.
  9. Wiring Control Wires:  Use 14 AWG 600V MTW (stranded) wire for 120VAC wire.  Use 16 or 18 AWG 600V MTW (stranded) wire for 24VDC wire for up to 10 and 5 amps respectively.  Use “General Wire Routing” recommendations found elsewhere in this document.
  10. Terminations:  leave some bare wire showing to allow visual inspection and to avoid screwing down on the insulation.  Wires should exit the terminal straight. Do not bend the wire at the point of termination.  Instead loop or bend wires on the insulation that do not go straight to the wireway.
  11. Terminals:  Screw Terminals: Use tubular, pressure plate type screw terminals that minimize wire distortions or damage when terminating.  Position Terminals to allow visual inspection of the recessed connections.  Elevate Control Terminals to allow wiring under the terminals if needed.  Keep it stiff using a heavy-duty DIN rail or Hoffman Terminal Straps or equivalent.  Angle and elevate terminals mounted on the side panel for wiring ease and to allow visual inspection of wiring in the terminals.
  12. Grounding  Principle:  Wire all grounds to the incoming ground lug either directly or with a wire to the other ground bus bars.  Add a main ground lug and/or a ground bus bar for each grounded power supply.  A number of busbars can be utilized but should all be wired together and then to the incoming ground lug to at least 1 point if not two (2).  This is in addition to the ground established through the panel.  Use 2 ground wires from opposite ends of the bus or chain of ground bars if the ground is isolated.  Wire the ground on all doors and subpanels and the cabinet itself to a ground bar terminated at the main ground lug.  Wire all equipment and chassis grounds to the ground bar(s) which is terminated at the main ground lug.  For additional details on grounding and bonding see the Grounding And Bonding post dedicated to just this subject.


Example of good spacing between the terminals on the wireway.

Example of good spacing between the terminals and the wireway.

  1. Optimize the Space.  Place PLC I/O racks in the “bay” created by the wiring duct to allow room for the high density of wires going to them from the duct.  Don’t leave space where there is no wiring, typically the top of the I/O rack.  Place similar sized devices in their own “bay” where possible.  Consider the routing of all of the wires and how the various voltages will be kept separated.
  2. Spacing between wired devices and wireway or other obstructions:  2″ minimum; 2 1/2 – 3″ preferred for 120VAC and less.  4″ for 480 volt (enough to insert a closed fist between the device and the wireway, another device, or obstruction.


For additional information on control panel design see the list of Control Panel Design Posts on the picture panel at the top or at the link here.


 |  Created: 5/5/2013 3:30pm CST; for Publishing on 5/13/2013 at 5:00 am CST

Posted by: Harold Ennulat | April 22, 2013

Powering Up A Panel For the First Time

How to Power Up a Control Panel for the first time,

without tripping breakers or blowing things up if things are wired wrong
Small Control Panel

Small Control Panel

Powering Up an Industrial Control Panel for the first time either after fabrication or after all the field wiring is connected and ready for power up verification, has some risks.  The main risk is that there are short circuits in the wiring that will cause the breakers to trip or the fuses to blow.  However there is also a risk that voltages can be mixed up that can cause damage to the control components.  This article examines this authors recommendation for powering up control panels or other equipment for the first time after major wiring changes have been made. 

There are basically three (3) different ways to power up a panel for the first time, at least that I have seen:

  1. Method 1.  Just turn on the main breaker and begin the checkout.
  2. Method 2.  Turn on one circuit at a time and check out once circuit at a time.
  3. Method 3.  Turn off the main circuit breaker or disconnecting device, turn on all downstream circuit breakers, fuses, and disconnecting means, and ohm check each phase or the load side of the main breaker phase to phase and phase to ground.

Method 1 is quickest method but only if there are no shorts.  Method 2 is really no better since no checks are performed till after each circuit is turned on.  Also this method takes the most time to find all of the shorts.

The above 2 methods are widely practiced but rely on everything being wired reasonably correctly in the first place.  However when a control panel is first turned on, it is for the purpose of verifying that the wiring and the functionality of the controls is correct.  Therefore some checks should be performed before powering up the panel for the first time.

The method I prefer is Method 3.  In this method all the downstream circuits except the main disconnect or circuit breaker are closed.  (Verify that there are no voltages present on the load side before proceeding and follow lock out procedures as required by your facility).  In closing all the downstream fuses, breakers, and switches, any shorts in most if not all of the wiring will reveal itself when using an ohm meter on the disconnected load side of the main disconnecting means and checking phase to phase and phase (or circuit) to ground impedance.  If a short is found then open 1/2 of the switches, fuses, and breakers in repeated steps until the location of the short(s) is(are) isolated. 

CheckingForGroundFaultsWhen checking for impedance to ground, I’m looking for at least 1 Mega Ohm.  When looking for phase to phase shorts I am often only looking for more than 2 ohms typically if there are coils in the circuit such as fans, as these look like near shorts but are perfectly normal.  If the phase to phase impedance is less than 2 ohms, I’ll start to disconnect the fans or other coils from the circuit till the number comes up.  Once it’s above 2-3 ohms then I’m usually satisfied that the panel is ready to power up.  If there are no coils in the circuit then there should be a higher impedance.  However the impedance may not be much more, depending on the expected loading.  For example if the panel draws 20 amps at 120VAC, that’s just 6 ohms of impedance.  If the panel is a 200 Amp 480 VAC panel, then it could be much lower.  In this case it might be worthwhile to check sections of the load so the Phase to Phase impedance is above 2 ohms or is otherwise reasonable for the given connected load.  Most of the time motors are turned off so this does not end up being in circuit for the ground/fault test.

There is one more thing however that would be good to check prior to powering up the panel.  If there are multiple voltages in the panel, check the impedance between each of the different power sources.  The Impedance should be greater than 1 Mega Ohm between any 2 power sources such as 120VAC and 24VDC or 5VDC. Also check each power supply to ground, again making sure the impedance is high.

Once the phase to phase and ground checks are performed, then I close the door (for arch flash protection) and turn on the main breaker to turn on everything all at once.  I have never seen a reason to turn things on one at time.  If the ohm checks are good then all should be good.  Also, this method avoids putting on the Arc Flash Suit to power up the panel as this is perhaps the most likely time that such an event will occur.

This entire check takes anywhere from 15 minutes to maybe an hour to perform depending on the complexity of the panel if there are no shorts found.

Disclaimer:  While I consider this a best practice, I cannot take responsibility for things going wrong.  There is inherent risk in performing electrical work that cannot be completely eliminated.


Updated: Sunday, May 5, 5:30 pm CST |  Created:  Wednesday, April 17, 6:00 am CST;  Published: Monday, April 22, 2013 5:00 am CST

Posted by: Harold Ennulat | April 8, 2013

HMI Virtualization

Virtual Machines used in controls applications, particularly for HMI type applications are gaining acceptance.  This article reviews virtualization and this authors exploration for use in single HMI, single PLC type applications.


What Is Virtualization?


For the purpose of this article, virtualization is running one (1) or more entire computing environment(s) within another host computer and operating environment.  For example I am currently running 2 completely separate XP mode computing environments inside of my Windows 7 laptop.  Each computing environment running inside of a host computing environment is called a “Virtual Machine” or VM.

For more explanations see: and

Why Virtualize?

Virtual Machines are more portable.  They consist of one large file that can be moved to another computer or backed up for later use.

Easier Installation and Reinstallation. Installing HMI (Human Machine Interface or Operator Interface) applications on a computer takes time.  Different computers can have different driver requirements.  Porting a developed application to another computer, especially if it is dis-similar to the previous one can take considerable time.  In fact one time it took me a week to rebuild a computer and application due to Microsoft operating system update that was incompatible with the HMI software that was being used.  Had the working application been virtualized and backed up, the VM could have been restored considerably easier. To be fair, an entire computer, applications and all could also have been restored had I made a Norton Ghost image to an external drive.  This would have been easier then restoring the host OS first, installing the VM software and installing the VM itself.  However the typical image restore requires that the computer be pretty much exactly the same.  Restoring a VM does not require the hardware to be the same at all.

Virtual Machine allow older operating systems to be run using a regular desk top computer.  In fact multiple different operating systems can be run on a single computer.

Ability to handle incompatible software within a single physical computer. In Controls there are some application softwares that cannot coexist on the same computer with other software.  This can be mitigated by loading each software on its own VM. Sometimes even different version of a single companies software cannot coexist on the same host.  VM’s can address this problem quite nicely.

For more reasons to virtualize see:

 Types Of Virtualizations?

VM Types

VMWare is the product that has the largest usage, more than 50% of the market I’ve been informed.  This product is currently dominant in usage for control systems given Rockwell’s endorsement and partnership with VMWare.

VMWare Player is a downloadable free application.  I’ve used this for about a year now and have been impressed with its usefulness.  It represents the starting point for those wanting to explore this tool. However it is fully functional with great “integration features” allowing for information to be moved between virtual machines and the host.  Once the Player is installed, then virtual machines can be either created or moved from other peoples computers.  Each new VM within Player requires separate licensing for the operating system.  However Windows 7 professional users can use the XP license in their machine to create one (1) virtual machine running XP.  If the VM is being moved then the license on the VM is used and no new operating system license is needed.

VMWare Workstation.  This is the commercial version of the software and operates similar to Player.  Cost starts at around $250 for a single copy.

VMWare Server Grade Solutions is for Server or 24/7 type production environments.  At the time of this writing these solutions got expensive quite quickly however many people swear by this approach for more sophisticated HMI applications using multiple operator stations and a pair of physical server grade computers running multiple virtual servers with optional redundancy and load balancing.  This solution uses the VMWare ESXi Software as the “host operating system”.  To get started there is however a free version of this software available.

This Authors Take On Virtualization.

VirtualizationCurrently I am using VMs on my laptop computer for developing PLC and HMI software applications.  We are exploring the possibility of implementing some kind of VM for our HMI applications running in a production environment.  The dilemma is which version of VMWare to choose.  For cost reasons the desire is just use the VMWare Workstation version for production use, however we have been cautioned that the VMWare ESXi (Server Grade) Solution should be used for production.

In querying some forums it seems that opinions are mixed.  However those that have used VMWare Workstation in customer installations say it works well, at least for standalone or independent PC’s running HMI applications that connect directly to one or more PLC’s.

We are still exploring this but I’m inclined to give this a try for the stand alone type applications.  HMI applications while important are already running on Windows PC based platforsm.  These platforms are inherently prone to service interruptions and even higher then normal failure rates in industrial applications, especially when compared to PLC failure and service interruptions.  For example an HMI PC reboot, even in the middle of a production run, while sometimes inconvenient, is often not critical as the PLC is doing all of the control.  The HMI is the operators window on the process and the control station allowing the operator to make changes and adjustments.  In some applications there is data logging and communications with other computers, but these can be designed (and I would say, should be designed) to tolerate at least some level of HMI computer down time.  Even without considering virtualizing the HMI, this author would rather see a second HMI introduced to the process if the visualization and operator interaction becomes that critical.

So given all this, using VMWare Workstation in the right kind of production environment will be given some serious consideration.

For a summary of the responses I got from the LinkedIn controls related discussion groups click the link here.


  |  Created:  Saturday, April 6, 2013  6:20 pm CST;  Published: Monday, April 8, 2013 5:00 am CST

Posted by: Harold Ennulat | April 28, 2012

Grounding And Bonding: Best Practice: “Wired Star Grounding”

There is a lot that can be said about grounding and bonding and providing an “effective fault current path”.  This article describes what this author believes is a best practice when it comes to establishing a “safety ground”.  The safety ground is one that ensures enough ground fault current to quickly trip the circuit breaker connected to the faulted wire.

Typical Service Grounding/Bonding "Back to the Source". Click to enlarge.

Technically what this article is focusing on is more correctly called “bonding“.  In control panel designs this is normally established by a green or green with yellow stripped wire and is part of what is often called the grounding system.  However there is nothing we do that actually ties anything to the earth.   Instead the control panel bonding/grounding point is tied to a green wire that at some point is tied to the return path of some power source.  For this article the word grounding and bonding are used interchangeably to conform with typical usage.

The focus is also on the safety aspects of the grounding system and does not deal with the EMI and shielding aspects associated with bonding.  However in all but the most special cases this method will provide good EMI and equipment shielding unless high frequency generating devices (such as variable frequency drives) are located inside the control panel.  In this case, this method is still likely a best practice, but additional measures may need to be taken. __________________________________________________________________________________

Over the years I have almost unwittingly developed my own form of grounding and bonding best practices as it relates to grounding/bonding of control panels and components in establishing a clear ground path “back to the source”.   Recently I started becoming aware that it does not appear to be a common practice and am trying to get input on what people in the field think of this idea.   I’ll call the idea the “Wired Star Grounding Method“. The practice puts a wire on everything that needs to be grounded and does not just rely on the cabinet and/or subpanel connections to establish the ground path.  I implement this using ground bus bars (typically the kind used in panelboards to connect the neutrals together) bolted to the subpanel of each panel in a system. The main ground wire that is run with the power source wires will feed the first ground bar. From there, power fed to other external devices and panels will get their own ground wire of suitable size to each panel or device tied to the same ground bar. In each panel each device requiring a ground wire, the subpanel, the enclosure body, the door will have separate ground/bonding wires connected to the panel ground bus bar. The ground bus bars are tied together from panel to panel in a star (rather than series) connection as much as possible. In this way there will be a wired ground/bond path “back to the source” that does not count on the metal parts of the panel to provide the fault current path.

Star Grounding Example
Click To Enlarge

The reason I prefer this is that it is much easier to inspect for proper connection. Metal to metal connections sometimes are not adequate ground fault paths to trip circuit breakers in the event of a ground fault. Since we typically cannot test for this, it becomes difficult to verify that the ground/bond is solid. We typically check the ground with an ohm meter, but that draws almost no current so it is not possible to tell how “solid” the ground/bond connection is. Also over time metal to metal connections can foul. Finally they can just be installed improperly and this is not always “inspectable”. A wired connection is easier to inspect with a screwdriver or a good tug on the wire to tell if the connection is “solid”.

A couple of stories will help illuminate the problem.  3M thermionically welds the building steel together for all of its manufacturing facilities just to establish the building ground grid because they have had problems with the bolted connections in typical steel building frames providing a reliable ground/bond at all points in the building.

Another example is from my most recent project where due to a communication problem the vendor asked us to make sure the grounds are solidly connected.  During the first check everything looked good using an ohmeter and a long spool of wire to check resistance from one panel to each of the other panels on the site.  But when the problem persisted the ground/bonding at one panel was checked again and this time a 5 and then 10 ohm impedance was measure to the subpanel when it was less then 2 ohms before.  It was found that the ground wire going back to the source was connected to a conduit hub ground screw that was loose and it could not be tightened.

My belief is that wiring the grounds back to the source ground/bond via a “wired star grounding method” avoids problems, is easier to inspect and verify, and provides another path to ground, thereby increasing reliability.



General Walk Through on Grounding:

Proper Grounding of Instrument and Control Systems in Hazardous Locations (Includes a recommendation to use a single point star grounding method:

Allen Bradley’s recommendations on grounding, bonding, and electrical interference reduction:

Grounding and Bonding Hardware Examples From Panduit:

EMC concerns with grounding systems in control panels:

ANSI/ISA-RP12.06.01-2003, Recommended Practice for Wiring Methods for Hazardous (Classified) Locations

LinkedIn Comments on the Wired Start Grounding approach:


Revised Saturday, April 28, 2012 8:40 pm CST  |  Published: Saturday, April 28, 2012  8:20 pm CST

Posted by: Harold Ennulat | January 7, 2012

2011 In Review

My thanks to all the readers of this blog in 2011.  Over 7,000 views in 2011.  This is a 34% increase from 2010!  That is incredible to me for a blog site that I did not even publish much to for the last half of 2011 due primarily to work demands.  The good news is that I’ve collected a number of ideas and topics to write about over the last 6 months.  So I expect to continue my blogging activities for 2012.

What follows is the report generated by my blog host:

Here’s an excerpt:

A New York City subway train holds 1,200 people. This blog was viewed about 7,100 times in 2011. If it were a NYC subway train, it would take about 6 trips to carry that many people.

Click here to see the complete report.

Posted by: Harold Ennulat | December 31, 2011

Redundant HMI’s: What To Look For

Are redundant HMI (or any computer based) systems really fault tolerant?  The answer may likely be “No”!

This Article is an attempt to make users aware of some limitations when considering implementing redundancy in their PC based HMI/OI systems. This article suggests how redundant HMI systems can be made more fault tolerant.

Redundant Server Example

Redundancy Defined:

At the core redundancy just means that there is a duplicate that can prevent failure of the entire system upon failure of a single component.   Since we are limiting our discussion to HMI’s (“Human Machine Interfaces” for the purpose of controlling machinery or process equipment like part of an oil refinery), what we are talking about is 2 computers that can provide the operator an alternative method to control his process.

Simple HMI Redundancy:

One way of providing redundancy is to just give the operator 2 or more HMI’s to work with.  If one goes down, then another can be used while the failed computer can be rebooted, repaired, or replaced as needed.   In this scenario each HMI computer reads data from the various PLC’s, stores and retrieves the various HMI screens, processes it’s own alarms, historical information and other special services.  Also management of the changes is on a computer by computer basis.

Client/Server Relationship to Redundancy:

Most HMI software today that is capable of redundancy is split up into multiple software pieces (or applications) that talk to each other.  There is a single client software application and usually several server software applications making up the overall HMI application.  These software applications can run on the same computer or separate computers depending on various factors like the size of the system and system management needs.

Client View Node Examples

The client applications are the actual “view nodes” that the operators use to monitor and control their part of the overall machine or process.  The client PC’s get all of their data from the server software which are usually on a separate computer.  Typically there would be multiple clients accessing the same set of data for a common server application.  The server software is what actually reads the data from one or more PLC’s in the system and delivers them to the various client PC’s requesting this information.  Other server software may deliver the various screens to the client PC’s, while still others may deliver services like event and alarming notification or historical data to the various clients.  This architecture allows the client computers to be greatly simplified, simplifies changes, centralizes the database of screens, and centralizes/minimizes communications with the PLC’s and controllers.

When we talk about redundancy, it usually means providing duplicate client and server software for all of the various software applications that make up the HMI application.  The client side redundancy is provided by having multiple client PC’s available.  Typically the focus for redundancy and fault tolerance is on the server software applications.  The redundant servers are generally implemented on separate physical computers as the computer itself and the operating system that is hosting the HMI server application(s) is considered the weakest link in a modern control system.

What to Look For In A Redundant HMI System:

When one is looking for a redundant HMI solution it usually means so much more than what is included in the basic definition provided above.  Users are looking for fault tolerance with such features as:

  1. Automatic failover if the primary system fails.  This is not always automatic.  This is sometimes called “hot redundancy”.   Also the system should be able to fail over from the secondary computer or server to the primary server if the Secondary failed when it was “active”.
  2. Alert  the operator to a primary or secondary system failure.  This allows correction to the failed system while the other one is providing functionality.  Without this functionality both systems could fail before anyone would notice.  That defeats much of the purpose of providing redundancy in the first place.
  3. Accurate self diagnostics to determine actual functionality of primary and secondary systems.  I’ve now seen a system that reports no problems but fail when switched from primary to secondary or back again.  This can give a false sense of security.
  4. Allow end users to switch between primary and secondary servers.  A popular product only allows the programmer or someone with special knowledge to switch servers.  It is not an operator friendly function.  Programmatic access to redundancy objects that can be displayed on the user screens should be provided in the HMI development application.
  5. Allow automatic switchover to the “standby” system to verify standby system operation.   This should only be allowed if the operator can switch servers manually in case the test does not work.  The alarm and Event should be logged if a failure is automatically detected and switch back automatically as needed.
  6. Allow program development on either the primary or secondary server(s) while allowing operations to continue using the other server(s) until the development is tested and released to operations.  Once the newly developed system is tested, then the software updates are replicated or synchronized back to other server(s).  This means that the development client application can display the development screens while the operator screens are still viewing the older screens.  Sometimes this is only possible because the client screens are cached, so to see the new screens requires that the client applications are restarted.


Managing Redundancy (or turning redundancy into fault tolerance): from “A Conceptual Framework for System Fault Tolerance” 3/30/1995:

Example Video of how a redundant server should fail over from NEC:  The interesting thing about this video is that it shows that if one CPU fails another takes over.  However you get no sense from any diagnostic screen which computer is running the application nor any indication of health of each server.  At least none of this capability was shown.  In fact how do you even know any server had failed so you could send it back for repair.  This was not even mentioned.  This underscores that buyers of redundant solutions need to ask plenty of questions and get credible/verifiable answers.



Updated: April 28, 2012  8:59 pm CST  |  Published: Dec 31, 2011  |  Created: Dec 29, 2011

Posted by: Harold Ennulat | June 8, 2011

Blow Out Preventer Failure Reason Discovered

BOP after removal for examination. Click to Enlarge

The Gulf Oil Disaster could have been minimized had the BOP (Blow Out Preventer) succeeded in disconnecting the oil rig from the oil well and closing off the flow of oil.  The investigation and report by Det Norske Veritas (DNV), the Norwegian company hired by federal investigators to perform forensic analysis on the Deepwater Horizon’s recovered BOP, indicates that when the blowout occurred the forces were great enough to dislodge and bend the drill pipe inside the BOP sufficiently that the BSRs (Blind Shear Rams) were not capable of centering the drill pipe for a clean cut when the BOP was finally actuated by the rig crew some 7 minutes after the drilling rig exploded on the surface some 5000 feet above the BOP.

This is leading to speculation that the inherent design standards for BOPs are not adequate to protect against this violent of a blowout.


Here are some links of articles I found on the DNV report issued in March.

One gets a much better picture by reading several perspectives on this same DNV report.


BOP on sea floor "leaking" oil while robot attempts manual operations.

Posted by: Harold Ennulat | June 1, 2011


PROFIsafe has become an international standard (IEC 61784-3-3).  PROFIsafe is a safety protocol that can coexist on any network.


What is PROFIsafe:  From Wikipedia:

PROFIsafe (PROFIBUS safety or PROFINET safety) is the first open functional safety communication technology for distributed automation systems worldwide. Its specification for PROFIBUS DP and PROFIBUS PA was published first back in spring 1999. It incorporates the knowledge of more than 25 renowned safety companies. Extensions for the Ethernet based PROFINET IO followed in fall 2005. More than 100,000 automation systems with more than 1 Million PROFIsafe nodes are currently in use worldwide (spring 2011).

In the past, safety automation had to be “hard-wired” and based on “relay” technology due to existing international standards. This changed with the advent of a new standard – IEC 61508 – specifying how microcontrollers and software can be used in safety automation. This triggered the development of PROFIsafe, which was to integrate safety into the existing standard PROFIBUS fieldbus technologies. PROFIsafe is designed as a separate layer on top of the fieldbus application layer and reduces the error probability of the data transmission to the level required by or better than the relevant standards. PROFIsafe messages are using the existing standard fieldbus cables in coexistence with the standard messages (“Single Channel”). PROFIsafe does not benefit from any error detection mechanisms of underlying transmission channels and thus supports the securing of whole communication paths, even backplanes inside controllers or remote I/O. PROFIsafe coined the term “Black Channel” for this concept, which now is adopted by most of the other safety fieldbusses. PROFIsafe can be used in safety applications up to Safety Integrity Level 3 (SIL) according to IEC 61508, Performance Level “e” (PL) according to ISO 13849, or Category 4 according to EN 954-1.

PROFIsafe is using expanded fault (errors and failures) detection mechanisms such as

  • Consecutive numbering
  • Timeout monitoring
  • Source/destination authentication
  • Cyclic redundancy checking (CRC)

PROFIsafe is standardized in IEC 61784-3-3. It also is a Chinese standard (GB/Z 20830-2007).

PROFIsafe runs its own web portal on (see Web Links) with more details on the technology and hints for device developers, integrators and end users.

The PROFIsafe standard is maintained, updated and marketed by PROFIBUS International, a non-profit organisation administered from Karlsruhe in Germany. PROFIBUS International is also responsible for the development of PROFIBUS and PROFINET, an Ethernet based fieldnetwork.


Here are some quick links:

For a good general overview:

From Profibus International (PI):  Be sure to checkout the related links in the left side bar.

Vendors supporting it include:


Phoenix Contact:


My thanks to Chad Tverberg at Control Assemblies for making me aware of this.




For another openSAFETY standard protocol that can coexist on other networks including ProfiNet or ProfiBus apparently see:


Updated: June 2, 2011  8:55pm  |  Created May 31, 2011

Posted by: Harold Ennulat | April 17, 2011

Learning PLC Programming

A number of people have commented and made suggestions on how to learn PLC programming in the LinkedIn “Automation and Control Engineering” group.  The group is now an open group, so the link should work for anyone without being a member of the group.

For my comments follow this link.

I also found a several additional resources by doing a google search for “PLC programming“.  A featured site that offers online and on site PLC program training is here.

PLCs.Net offers this syllabus for their video training course.  It appears to cover most all of the basic PLC programming concepts.

The basics include such things as the history of the PLC, how the PLC works, the basic functions, PLC programming languages, the numbering systems, addressing/tagging, various kinds of logic used in the PLC and how to put them together to build functional circuits or functions, subroutines, and program execution sequencing, shift registers, discrete and analog control, data manipulations, doing math, handling fast I/O (input and output events), and a few things about wiring up the I/O the right way.

Posted by: Harold Ennulat | March 7, 2011

OPC Classic Security

Eric Byres notes that Stuxnet (a virus that has attacked automation hardware) uses the same underlying protocols as OPC (a standard automation communications protocol) namely RPC and its P2P network.  He posts links on “Securing Your OPC Classic Control Systems”.  See below for the links in the context of a recent post in the LinkedIn “Automation & Control” discussion group.  OPC has emerged as the standard “device driver” for communicating between automation devices such as PLCs and HMIs over a variety of media including ethernet.


Eric Byres

Eric Byres • As a person who has studied both OPC and Stuxnet in some depth, OPC Classic is a potential security issue IF handled poorly.

Unfortunately many companies do just that, leaving large numbers of ports open in order to make OPC work out of the box. This is easily addressed with modern OPC security technologies – for example, see “Securing Your OPC Classic Control Systems” on the OPC Foundation White Paper Downloads Area (

Stuxnet complicates the problem by making extensive use of the same underlying protocols as OPC, namely RPC, for its infection exploits and its P2P network. To make matters worse, the Siemens PCS 7 system also replies heavily on RPC to function. You can’t just take an IT firewall and say block all RPC and expect your plant to run.

I could go on for pages on the RPC problem, but more details are available in the white paper “How Stuxnet Spreads” (available at

(FD: I was a co-author in both papers)


« Newer Posts - Older Posts »