Update – Excuses…

So I guess its pretty obvious I haven’t posted for a while… and I really don’t have any good excuses. Of course I still travel a lot, and I am still working on a lot of projects when I’m in town, but you would think I could make time to post something here.

Part of it I guess is that I haven’t had a lot of feedback lately. I honestly can’t think of any unique topics that I haven’t written about already, or that aren’t thoroughly covered somewhere else. So if you have something you’d like me to discuss, send me a line and I’ll try to write about it.

****************************************
I’m still teaching lots of classes, both at my facility and on the road for Automation Training. I’ve still been doing work in Miami at the bottling company, upgrading some of the equipment and working in their Ignition SCADA system.

I’ve done a little more work on my PLC book, added some Siemens material to it. I still use the original PLC Hardware and Programming manual when teaching my own material, but I have several platform based printouts that I use when teaching custom stuff. Hopefully I’ll be able to finish the book next year.

I finished my first trainer for my hands on classes and will be using it next week for a custom student. Still working on the HMI, a Samkoon SK-070HS. There is a serious lack of documentation for the software, but I think I’ve got it worked out. It also integrates with the Fischertechnik demos, but I haven’t had time to work on that part much. I’ll post some pictures when I get a chance to upload them.

So yes, I’m still alive, even though the site doesn’t seem to be. Let me know if there is something specific you’d like me to cover.

Share
Posted in Life, Random Thoughts

Ladder Logic 306: Simulation

Today’s post relates to a new method I am using to teach some of my advanced classes. In a basic PLC training class, pushbuttons and pilot lights built into a trainer are used to complete exercises, usually in order to illustrate the use of different instructions on the PLC software platform. Advanced classes concentrate more on the techniques used in programming, such as Auto Sequences, Part Tracking, and other System functions.

Making all of the elements of a properly organized program operate together can be a daunting task. All of the different types of routines I have described in my previous PLC articles relate to each other, coils and Move instructions from one routine often drive contacts and comparison instructions in others. For contacts that represent the state of a machine or sequence they are easy enough to test; after all, things like Auto/Manual Mode, AutoCycle and even Faults are generally indicated by internal memory bits.

Inputs and outputs however are a different story. In a larger machine or system, they represent a lot of different types of sensors or output devices. With the trainers that are often used in training classes, you quickly run out of buttons, switches and pilot lights to substitute for your real world devices. Input devices such as buttons, switches and potentiometers also don’t react automatically in real-time to sequences and output commands.

This is where a Simulation routine can be useful. The output logic shown above is similar to those I used in my Ladder Logic 202 article from several years ago. In this illustration, notice that the inputs and outputs are “aliased” to memory bits rather than real world I/O. If you are using a platform other than Allen-Bradley, don’t worry; the point is to uses internal memory rather than real inputs and outputs.

When the Z-Axis_Lower_SV output is activated in a real machine, the Z Axis Lowered sensor would usually be activated automatically. Since this is not a real solenoid valve driving an air cylinder with a sensor on it, we need to simulate the sensor being made.

This timer circuit does the job nicely. Notice once again that a memory bit needs to be used to simulate the input. The input memory bits can then also be used in the auto sequence to step from one sequence state to the next. The EnableOut bit is used in case a Fault needs to be simulated. If the bit is disabled, it is as if the output activated but the input was never detected, the fault timer will then time out and latch a fault condition.

Also notice here that a “latch” or “set” bit is used for the input. This is especially important for solenoid valves that are turned off when the sequence proceeds to the next step. When the output goes off the simulated sensor will stay active.

It is best to put all of the simulation rungs in a separate routine. If the program is not just for training but for a real machine, the simulation routine can be removed or disabled later. Simulated I/O can also be replaced later with the real stuff.

What about analog values? Once again, a timer is used for the simulation. In this case, the tank level will increment by five every twenty milliseconds. Both the timer value and the tank level addend can be adjusted to achieve the desired result. There is more conditioning that should be done to simulate a real tank, but this shows the general idea. To drain the tank, use a subtract instruction. This can be used to test PID instructions also.

I have started using this technique in some of my advanced classes. About a month ago I taught a class where we wrote a palletizing program. Students used pushbuttons and pilot lights for some of the I/O, but for sensors that we wanted to react automatically I showed students this technique and it worked quite well. Since real I/O is pretty limited on training equipment it also allowed for writing much larger programs.

Hopefully this will inspire you to use this technique when you need to test your program. Often real equipment is not available during the design phase of a project, this allows the programmer to test some of the more critical code before deploying it on a machine. With an HMI, it even allows for visualization of the process via animated objects.

Share
Posted in PLCs, Software & Programming, Training Tagged with: , , , , ,

PLC Security

Courtesy of belden.com

This post is another guest post from MRO Electric. I thought it was an interesting topic.

************************************************************************
PLC Security In The Heating Industry: Keep Your Friends Close, and Your Enemies Closer

No one understood or more succinctly described strategies and philosophies of war than the great Chinese general, Sun Tzu. Despite living and penning these words of wisdom almost 2700 years ago, leaders of today still apply the tactics described in the Art of War in in the technology-driven world we live in today.

Sun Tzu also said, “To know your Enemy, you must become your Enemy.” Now as a control engineer working for a reputable organization no one is advocating that you become a dark web hacker to understand the challenge you are facing when creating security for PLCs, but there is value at understanding who the enemy is and what their motivation and techniques may be.

When PLC’s developed in the early 1970’s replaced relays in control systems for automotive assembly lines and rapidly adopted and integrated across the industrial landscape security was entirely physical as there was no access to these systems outside a given facility. Times have obviously changed dramatically.

Advances in technologies involving M2M communications has given organizations access to massive amounts of data that can be translated into actionable information leading to better and more timely decision making. The rise of IoT has quickly brought access to this volume of valuable data over the internet. Machines can now be connected anywhere on the planet. This increased connectivity and access has also greatly increased the vulnerability of networks and the machines and PLCs utilizing them.

Whether it be the heating or manufacturing industry, security has come to the forefront and must be a top concern and consideration during all phases of design and implementation. So, who and what constitutes the primary threats in the machine builder environment for those in the heating industry utilizing PLCs? Here are some considerations:

New Threats
Malware has been the primary cause of most disruptive and destructive attacks over the last decade. Hacktivist would target an organization or industry based on their own beliefs with a goal of causing massive disruption and destruction. An often-cited example is the 2010 Stuxnet malware attack on the Natanz nuclear facility in Iran that resulted in the destruction of 1000 centrifuges. Over the past few years we have seen a rise in the number of attacks utilizing Ransomware to hold organizations as well as individuals sensitive or proprietary data hostage. Unless exorbitant payments were made the victim’s information or digital assets would be destroyed or leaked to the public.

In sports, the cheaters and dopers always seem to be one step ahead of the regulatory agencies trying to maintain a level playing field. The Academy Award winning documentary Icarus illustrates just how far individuals and states will go to cheat the system and stay ahead of doping controls. The same is true of hackers. It is much easier for any hacker to take advantage of the cracks in a new emerging technology than it is for an organization or industry to create impenetrable security measures.

These threats used to emanate mainly from small groups of hackers hiding in the shadows. Today organized crime groups and even state-sponsored action constitute the greatest threats. Syndicates have the money and the muscle to employ the most accomplished hackers on the planet, who are all available for a price. The proliferation of nation-grade malware has put these powerful weapons in the hands of individuals who can inflict as much harm as a rogue nation.

Change is Constant

Today, attacks tend to happen quickly and are relatively short in duration. Even though a breach can usually be eliminated swiftly, the fallout and damage can be more far-reaching and lasting. While attacks against infrastructure such as the electrical grid or water supplies could pose an imminent threat to human lives, those targeting consumer data can be equally as devastating. A company or industry’s reputation may never recover in the wake of such an event.

Markets and Industries are moving quickly. Companies are seeking to be innovators or disruptors and are racing to be first to market and are under intense pressure to perform. We are now in the midst of the rapidly emerging 4th Industrial Revolution and continue to see Moore’s Law on display as technology and innovation continue to accelerate at a dizzying pace. What constituted state-of the-art security in any industry 12-18 months ago can be woefully obsolete today.

Even though it may be impossible to eliminate all security breaches in systems and devices, machine builders can never rest on their laurels and have to remain proactively vigilant to maintain the best PLC security that can be incorporated into a design. These are the new battle lines in 21st century digital warfare. Sun Tzu said, “Invincibility lies in the defense.” How strong is your defense?

Security Factors:

  • Although it may not actually connect to the internet, a control system is unsafe. Contrary to popular belief, a modem connection could also experience intrusion and a hack.
  • Wireless networks, laptop computers, and trusted vendor connections could be other sources of connections in which people may be likely to overlook.
  • Keep in mind that the majority of IT departments are unaware of factory automation equipment, including CNCs, CPUs, PCBs, robotics parts and, last but not least, PLCs.
  • Piggybacking off of the last point, IT departments’ lack of experience with the aforementioned equipment, along with their lack of experience with industrial standards and scalable processes indicate that they should not be in-charge and responsible for a company’s PLC security. Nobody wants an annoyed employee to make inappropriate changes to a PLC’s communication highway.
  • Hackers do not necessarily need to understand PLC or SCADA to block PC-to-PLC communication. They absolutely do not need to understand a PLC or SCADA system to cause operational or programming issues.
  •  Often times, control systems, including ones that many PLCs integrate with, use Microsoft Windows, which is very popular amongst hackers.
  • Some PLCs crash simply by pinging an IP address, like what happened at the Brown’s Ferry Nuclear Plant, which is located in upstate Alabama. Since the incident in 2006, the plant has undergone numerous security, operational, and management improvements.

In conclusion, when a security breach occurs, regardless of the specifics, understanding that time is of the essence will help smooth over most incidents. Trusting who has access to a control systems environment and thumb drive is crucial. If someone has access to the control system environment and thumb drive, ensure they’re well-qualified and up-to-speed with their team and/or company.

Joseph D Zulick is a manager, writer, and editor at MRO Electric and Supply.

Share
Posted in Guest Posts, PLCs Tagged with: ,

Manufacturing Terms, Buzzwords and Acronyms

As part of a consulting project I am involved in, I have created a list of acronyms and terms that are used in manufacturing and industrial automation. These are terms and acronyms from Lean/Six-Sigma, controls, electronics, business software and general corporate use. Part of the reason I did this is to ensure that everybody is on the same page when discussing different topics; everyone’s background is different and especially with acronyms, some are duplicated.

I plan to update this list regularly since it seems like a good resource. Please throw any of your own ideas in!

*******************************************************

5S – Sort, Set in Order, Shine, Standardize, Sustain. (Seiri, Seiton, Seiso, Seiketsu and Shitsuke).
Andon – System to notify management, maintenance, other workers of a quality or process problem via signal lights or audio.
ANSI – American National Standards Institute
API – Application Programming Interface (System specific program interface, MS Windows)
ASCII – American Standard Code for Information Interchange (represents text in computers)
ASME – American Society of Mechanical Engineers
Best Practices – Method or technique that has been generally accepted as superior to any alternative because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things, e.g., a standard way of complying with legal or ethical requirements.
BI – Business Intelligence
CE Marking – A certification mark that indicates conformity with health, safety and environmental protection standards for products sold within the European Economic Area.
CRM – Customer Relationship Management
DBMS – Database Management System
DCS – Distributed Control Systems
DQL – Data Query Language
EATM – Enterprise Appliance Transaction Modules
ECO – Engineering Change Order
ECR – Engineering Change Request
ERP – Enterprise Resource Planning, automating back office functions.
ERP II – Expanded ERP, goes beyond corporate walls to interact with other systems. Web based software that provides real-time access to ERP systems for employees and partners.
FIFO – First In First Out
FMEA – Failure Mode Effects Analysis. A step by step approach for identifying all possible failures in a design, a manufacturing or assembly process, or a product or service. “Failure mode” means the ways or modes in which something might fail.
GRP – Government Resource Planning (ERP for public sector)
GUI – Graphical User Interface
Heijunka – Smoothing of production, production leveling
Heijunka Box – Visual scheduling tool
HMI – Human Machine Interface
HTML – Hyper Text Markup Language
IEC – International Electrotechnical Commission
IEEE – Institute of Electrical and Electronics Engineers
IP (as in IP67) – Ingress Protection. An electrical rating for resistance to water
ISA – International Society of Automation
Jidoka – A quality control method
Jishu Hozen – Autonomous maintenance, a pillar of TPM
JIT – Just In Time
Kaizen – Improvement, continuous improvement
Kanban – Pull Systems
Kohai – Junior
KPI – Key Performance Indicator
Lean Enterprise – A practice focused on value creation for the end customer with minimal waste and practices.
Lean Manufacturing, “Lean” – Systematic method for waste minimization (Muda) without sacrificing productivity.
Lean Six Sigma – Six Sigma applied with the principles of Lean Manufacturing
LIFO – Last In First Out
MES – Manufacturing Execution Systems
MMI – Man-Machine Interface
MOM – Manufacturing Operations Management
MOS – Manufacturing Operating System
MRP – Material Requirements Planning
MRP II – Manufacturing Resource Planning
MTM – Methods Time Measurement
Muda – Waste Minimization
Mura – Waste though unevenness in work loads
Muri – Waste created through overburden NEC – National Electrical Code. A US design standard on electrical wiring and equipment.
NEMA – National Electrical Manufacturers Association
NFPA – National Fire Protection Association
NPN – Type of transistor used for sensors, “Sinking”.
NUMMI – Toyota GM joint venture
NVA – Non Value Adding operations.
OEE – Overall Equipment Effectiveness
OIT – Operator Interface Terminal
OSHA – Occupational Health and Safety Administration
P&ID – Piping and Instrumentation Diagram
PID – Proportional Integral Derivative. A method of process control.
PLC – Programmable Logic Controller
PLM – Plant Lifecycle Management (Process of managing an industrial facility’s data and information throughout its lifetime)
PLM – Product Lifecycle Management (Process of managing the entire lifecycle of a product)
PMTS – Predetermined Motion Time System
PNP – Type of transistor used for sensors, “Sourcing”.
Poka-Yoke – Error Proofing
PPM – Planned Predictive Maintenance
PPM – Parts Per Million
Prox – Proximity switch, usually inductive (detects metal)
PWM – Pulse Width Modulation
QC – Quality Control
QD – Quick Disconnect (cable)
RPN – Risk Priority Number (used in FMEA)
SCADA – Supervisory Control and Data Acquisition
SCARA – Selective Compliance Assembly Robot Arm, a form of robot
SCM – Supply Chain Management
Senpai – Senior
Sensei – Teacher
Sinking Sensor – An NPN solid state sensor
Six Sigma – SQC applied to business strategy
SMED – Single Minute Exchange of Die
Sourcing Sensor – A PNP solid state sensor
SQC – Statistical Quality Control
SQE – Software Quality Engineering
SQL – Structured Query Language
Takt Time – Average time between the start of production of one unit and the start of production of the next unit
TEEP – Total Effective Equipment Performance (OEE vs. Calendar Hours)
Time and Motion Study – evaluation of personnel/human activities.
Timing Chart – used for machine design
TMU – Time Measurement Units (0.00001 hours, 0.036 seconds)
TPM – Total Productive Maintenance
TPS – Toyota Production System, flexible mass production.
TQC – Total Quality Control
TQM – Total Quality Management (US Department of Defense (DOD))
UL – Underwriters Laboratories. An American safety, consulting and certification company.
Value Stream Mapping – Lean management method for analyzing the current state and designing a future state for a product. Charts a series of events that takes a product or service from its beginning through to the customer. Focuses on areas of a firm that adds value to the product or service. Also known as material and information flow mapping.
VFD – Variable Frequency Drive
XML – Extensible Markup Language

*******************************************************************

Part of the purpose of this list is to illustrate that words and acronyms can mean different things to different people, especially from different disciplines in the workplace. Make sure that you and the person you are communicating with are “on the same page”!

Share
Posted in Business, Lean Manufacturing Tagged with: , ,

MRO – Moving HMI Designs

Today’s post is a guest post on HMI programming from MRO Electric, an automation product supplier.

Designing HMIs for Mobile Devices

Well-designed human-machine interfaces (HMI) reduce operator error, saving companies millions of dollars by reducing down-time and increasing worker safety. HTML5 programming enables the transfer of HMI designs to mobile devices, but programming is just the enabler. Let’s learn some best practices for HMI design elements that are specific to mobile devices due to size and interface considerations.

Blend In to Stand Out

A well-designed HMI reduces user error from misunderstandings or not having all relevant information available when they need to make critical decisions. The key to designing a successful HMI on a mobile interface is building one that is functional and, at the same time, delights the user. Most users are going to be running either Apple’s iOS or Google’s Android. Design your interface to blend in to the native platform that the user is comfortable with. Make heavy use of the native UI features for each platform wherever possible. This will make your life easier as the platforms evolve and the users update their operating system; ultimately making your users feel immediately at home when they open your application.

Navigation and Layout

The users of your HMI will need to be able to do two things: view content and navigate to content they want to find. On a large screen HMI best practice is to minimize the number of physical screens to simplify navigation. An example of a well-designed HMI on a large screen might looks like this. The content is well organized and all of the summary information is immediately visible. Each of these views can be further expanded following a hierarchical navigation structure.

Source: The High Performance HMI Handbook

On a mobile device, however, having this amount of visual information on a single screen would be incredibly difficult for a user to interpret. Best practices instead are to prioritize user actions and the number of paths to reach the information they need vs minimizing the number of screens. Start by presenting a system level view which has the minimal level of information then provide navigation paths connecting different views for the users to follow. At each view, the content should fill the entire screen, while translucency and blurring can hint at more information. Avoid the use of bezels, gradients, and drop shadows as they introduce noise which takes the focus from the views content.

Navigation through your app should be intuitive and predictable. A good choice for a navigation pattern is a slide navigation drawer which displays many navigation targets at once, yet remains hidden until invoked by the user. This allows you use the entire screen for content while still maintaining a rich navigation model between parent, children and sibling views. This navigation model will also allow a user to quickly switch between unrelated views, while maintaining the ability present a deep hierarchical structure. It will also help your users learn about alternative views or features while building a mental model of how to interact with the system through your HMI.

System Control and User Actions

An HMI designer must consider the developer model and the user model as they create and HMI to interact with the system. On a mobile device, we can state these more clearly as what visual controls are we presenting to a user and how are they going to interact with these controls. A general rule of thumb is whenever the number of possible actions exceeds the number of controls, you are likely going to confuse your users or obscure valuable features of your HMI. For example, you wouldn’t want to hide critical information behind a long press because the user may never find. Instead, you might add an info button in the top corner of the screen as an overlay. This design will subtly guide the user to discover the information without being intrusive or vague.

A number of control models have been developed for mobile interfaces to help minimize confusion for the user. Some common control models are: when something can only be on or off use a Toggle Button. If the user can only select one option, but this option has a range of possible values, such as screen brightness, use a slider. If the user can only select one option with a range of values, but they need fine control use a stepper button. If a user needs to select one of many categorical values use dropdowns or scroll wheels. As a last resort use text entry, as that is the slowest and most error prone way to interact with a mobile device. You can also combine tactile feedback through a vibration or sound with any of these control functions, however tactile feedback should be used carefully and only to bring visibility to interactions where visual cues are not enough.

You should design your controls with the thought that if that an error is possible, someone will make it. Therefore, design to minimize the chance of the error in the first place, or its effect once it is made. Maintain enough spacing for controls so that the users are able easily access them without making unintended touches. Also, make use of full screen pop ups to confirm actions that can have effects that are difficult to reverse.

For mobile devices gestures, such as tapping and swiping, are the ideal paradigm for users to interact with your HMI. Reusing common gestures will ensure your app behaves in a predictable manner. Some common gestures that you should make use of when bringing your HMI to a mobile screen are shown below:

Design with Scale in Mind

Traditionally, HMI have fixed screens and physical controls that you can design towards. When creating an HMIs for mobile devices you are no longer guaranteed a common screen resolution. As a result, UI elements (such as a button) appear physically larger on low-density screens and smaller on high-density screens. Because of this, you need to ensure that your visuals such as text, icons and graphical images are clear at every screen size you expect your users have. To help you create a HMI that can fit a variety of different resolutions, follow these ratios so that your images, controls and text will look the same when displayed across multiple screen sizes.

Wrap up!

We have laid out some best practices for moving an HMI to a smaller screen. We have talked about how the basic rules of good design still hold; provide a good conceptual model and make things visible. However, there are certain unique challenges that must be designed around such as only being able to show limited visual information and a different user interaction paradigm.. What are some design rules that you have found useful when building HMI on mobile devices?

Joseph Zulick is a writer and editor at MRO Electric.

Share
Posted in Guest Posts, HMIs, Software & Programming Tagged with: , , , ,

How To Design And Build A Small Controls Project

Today’s post is a response to frustration. Some times when dealing with potential customers you waste a lot of time trying to save them money. They may want you to cut corners, spend a lot of your time (for free) chasing down cheaper parts or resources, all the while not realizing that they are only hurting their own cause. A consultant I know has been working with such a customer for the past year or so, and has been asking me for methods of getting their projects done cheaper. This is the same consultant and his customer that I wrote this post about last September.

Anyway, I wrote an article about what it takes to put together a small controls project and sent it to him. This is why I rarely do project work anymore; he had asked if it was something I could knock out “in a few afternoons”, cheaply of course. He also asked if I knew of anyone else who might. My question to him: why would they want to?

*****************************************************************

Building a Small Controls Project

This document is intended to describe some of the requirements and skills for a small project. It helps explain why these kinds of projects can seem very expensive; it takes more time to do a properly executed controls project than you would think, and often the skills required to do even a small project are not found in the same person. CAD, wiring, design and programming are entirely different skill sets. Of course controls components aren’t exactly cheap either! Hopefully you will find this article useful whether you are doing a project for someone else or in your own plant.

1. Specifying Parts

Describe the project on paper with as much detail as possible. Identify requirements – and potential future/expansion possibilities – in the document. Determine availability of utilities such as pneumatics, 480v/120v power, CFM and amperage. This should provide you with enough information to determine whether you will need a PLC, individual discrete control components such as temperature controllers, timers, counters or an HMI. Remember, you may need a 24vdc power supply.

This is also where you create an I/O list if specifying a PLC. This can be a temporary document, but starting a spreadsheet for the project at this point is a good idea. Handwritten notes should be kept in a folder or binder.

Catalogs and online resources are useful for selecting parts. A lot of detail goes into building a control system and there are a lot of small components such as terminal blocks, labels, jumpers, different gauges and colors of wire, etc. If this is to create a proposal rather than for the actual project, these small components can be estimated for cost and selection can wait until later. Use your local vendors to help if you don’t understand the specifications.

2.Designing the System

This part requires some knowledge of electrical and mechanical design. Again, for a small project items can be sketched by hand to determine sizes, one-line diagrams can be created for determining electrical requirements. Graph paper can be useful for determining sizing of the enclosure. The Excel spreadsheet used in specifying the system can be modified as part of the documentation process. If possible, AutoCAD or an equivalent design software package should be used for electrical and mechanical drawings. Dimensions will be very important here and any work done in this preliminary step may end up being used in the final documentation.

3. Ordering parts

Procurement of parts may involve some shopping around. Of course price is important, but don’t spend too much time trying to save a few pennies. Remember, time is money! Lead time is also an important consideration.

It is important here to keep all documents and paperwork for received components. Some of this may end up in the project binder, and packing lists can be used to reference purchase orders and possible returns later. Open boxes carefully and keep all packing materials for the same reason; some vendors won’t take components back unless it is in the original packaging.

4. Building the System

There are a lot of skills and tools required for wiring, panel fabrication and bracketry. Among these are panel layout (drilling, tapping, “pinging” drill points), panel prep (cutting of din-rail, wireway and component cutouts), wiring (Ferrule crimping, wire stripping and labeling), possible millwork and painting. There are also legal requirements that must be met for wire sizing, grounding and cabling/conduit outside the enclosure (field wiring). It is also often not economical to purchase some of the tools and components needed for proper panel fabrication, especially if you are doing a “one-off” project. It is often best to use an outside panel shop or electrician for this step. If the panel must be UL listed you may have to do this anyway. Also, without experience in this field, your system may not look very good; if it is going to a customer they may judge you by your work.

5. Programming and Software Design

For systems involving a PLC or HMI, knowledge of the platform’s software is required here. This software can often be quite expensive also, this should be taken into account during the specification design phase. Will your customer have the software? Is there an additional yearly licensing fee involved? Is there local support for troubleshooting or modification, or can the customer do it themselves?

Also, just because someone has done some PLC maintenance work does not mean they are a programmer. Even with years of experience, there are a lot of considerations that should be taken into account for maintenance and operator usage. HMI design is a bit of an art, as is PLC programming. As always, documentation is also critical. There should be LOTS of diagnostics, messages and faults programmed into a properly designed and programmed system, downtime costs money.

6. Startup and Debug

Most experienced programmers know not to worry too much about small mistakes during the programming and software phase, they will be discovered and fixed easily after the system is powered up. This is where the system gets fully tested before going into production. For larger systems, there is often a testing phase at the factory (FAT or Factory Acceptance Test, your shop) and another at the customer’s location after it is installed (SAT or Site Acceptance Test, final location). These events take up to two weeks each in some cases.

-Frank Lamb, April 16, 2018

Automation Consulting, LLC

Share
Posted in Applications, Consulting, Controls Design, Machine Design, Techniques, Thoughts Tagged with: , , , ,

Hands On Training Equipment

This post is both an update on the status of “My Little Factory” and an article on some new fun trainers that I am working on.

As you can see in the above picture, all of the hardware for the machine side of the factory is pretty much done. Everything is operable in Manual Mode and mostly there in Auto. The infeed conveyor indexes, escapements work (though sometimes the balls bounce out of the boxes…), the dial rotates, and both pick and places operate correctly. All wiring and pneumatic plumbing is complete, and the system runs in “semi-Automatic”.

This is a layout of the operation of the system. A box is placed in the first pocket of the indexing conveyor and the “cycle” button is pressed on the HMI. As boxes make their way down the conveyor, balls are dropped into them at stations 2, 4 and 6 from the escapements, based on the selected recipe. The filled box is picked up at station 10 and placed on the dial table. They are inspected at station 13, where the results are compared to the recipe for ball color and number. The box is then picked from station 14 and placed on the outfeed conveyor, where boxes can be moved either left or right based on the inspection results.

As you can see, the escapements can be loaded with balls of a lot of different colors and materials. I have done some preliminary machine vision work with my Keyence camera system, and some of the balls can be quite challenging to differentiate. I have also purchased a Cognex color camera and will probably use that in the actual application.

So what is the idea behind this training machine? There are a lot of different techniques that can be taught. The program has been completely written, but there is still some debug left to do. The most complex part of the program is the recipe management and part tracking. This will be for very advanced students only.

The program is organised into lots of different routines, which can be disabled so that students can put their own code in while still using the rest of the program. Listed below are some of the techniques that students will be able to learn and program themselves:

Mode and Cycle Control (Basic)
Indexing Conveyor Sequence (Basic)
Escapement Sequence based on count (Basic)
Pick and Place Sequence (Intermediate)
Dial Sequence/Servo (Intermediate)
Outfeed reversing conveyor control (Basic)
Recipes and Part Tracking (Advanced)
Faults and Alarms (Basic)
HMI Interfacing (Intermediate)

This is all nearly ready using the Allen-Bradley ControlLogix/CompactLogix platform. Siemens will be next, the hardware is already there (S7-300) but the program needs to be written.

I have also made some progress on the process control side as shown above. The load cells for weighing the tanks have been wired and are ready to be tested. I now have a good idea of how I plan to wire the pumps and valves, but the interconnect manifold and its associated sensors are the next big challenge. I will be using the Siemens controller to start with.

Now for some other fun stuff: I mentioned in a previous post that I was looking for a lower cost way to build – and sell – trainers. In particular I wanted to use small conveyors with various attachments so that students could easily program them using different platforms. Enter Fischertechnik…

Fischertechnik Color Sorting application

This is a conveyor with color sensor and several bins to eject different colored pucks into. The sensor is analog 0-10v, there is actually a tiny compressor to actuate the pushers. I would call most of the programming associated with this “Intermediate” level.

Fischertechnik Machining Line

This is a series of conveyors and motor-driven actuators. Again I would consider this to be intermediate level programming. I’m not exactly sure what the small machining center and drill are actually supposed to do other than turn, but it should be fun.

Fischertechnik High Bay Warehouse

This bad boy is an X-Y-Z application to store and retrieve items from 9 different locations. I would consider this to be an advanced topic, especially when linked with the part tracking and recipe topics I mentioned previously.

Fischertechnik Conveyor

This little conveyor will need to have some technique added to it to be useful, but it also shows the interface board that is common to all of these “toys”.

I also bought an obsolete system that I will probably use for spare parts as much as anything. It is all 9 volt stuff, so it will be harder to use the parts than the more typical 24v that everything else runs on.

There is quite a bit that needs to be done before this can be used or made into marketable trainers. I need to be able to plug different trainer PLCs into it, I’m hoping to use AB CompactLogix and Micrologix, as well as Siemens S7-300 and S7-1200 platforms. I also want to incorporate an E-Stop, Power On/Reset, light stack indicators and maybe a small HMI as an option. I may use remote Ethernet/IP or Profi modules to interface with my equipment. Automation Direct or EZ Automation platforms would also be a possibility, but I would need to be convinced that there is a market for it.

Another very useful interface would also be troubleshooting blocks where signals can be disconnected/cross-connected so that technicians can use a meter and their new PLC training to troubleshoot. This is something that a lot of my students have requested.

Anyway, this is where I’m currently at in my venture. It’s hard to make quick progress on all of these ideas since I’m still spending a lot of my time traveling and teaching, but I feel like its all getting there. Hopefully some of my partners in training will be able to help me with some of this. I am always looking for new partnerships in some of these ideas also, hit me up if you want to be involved.

Share
Posted in Material Handling, My Little Factory, Process, Software & Programming, Trainers, vision Tagged with: , , , , , ,

Ladder Logic 403: Message Scrolling and Multiple Faults

Sample Fault Logic

Today’s post is in answer to a question from Bruno on my last post on Faults and Messages. Bruno asks “If two faults happen at the same time, will this procedure work?”

This is a more complex question than it might appear to be, so I have created my third advanced topic in my Ladder Logic series.

First off, we need to address whether two faults can happen at the same time. Often one fault may cause another; an example might be a fault causes an “air dump”, which prevents another cylinder from reaching end of stroke. The logic at the top of this page shows that if a normally closed System Fault bit is placed in series with the fault logic for an individual fault, it prevents multiple faults from occurring. Even if somehow two faults happen during the same scan (highly unlikely, scans are typically on the order of 30-50ms max), the first fault would prevent the second from happening. So proper programming can isolate the initial cause quite easily.

Still, on larger “zoned” machines which have multiple fault registers, sections of a machine or system may operate independently of each other. Yet if you only have one HMI, all of the faults still need to be recorded and enunciated. In this case there needs to be a fault register for each cell or station. On the “Fault History” screen of a typical HMI, each register would have a separate trigger, so multiple faults would appear on the list.

But what about if you have a single information banner and want to put multiple messages on the screen? This requires code that will search your fault and information registers and then scroll them across your banner or message display. The following logic shows a method of doing this.




This code is from a template I used to use when working at Wright. There is a lot more explanation that goes with this, some of which can be found in my other ladder logic posts. This template used a spreadsheet to generate “cells” which were populated with standard code that would serve as a starting point for a program. Look at my posts on program organization and PLC templates for more info.

Each cell generates its own Faults, Info and Warnings, three separate message categories that are searched and scrolled on three different banners on each screen of the HMI. There are typically 20-40 cells on a large machine or system, so the search for messages covers 60-120 different registers, each of which may contain 10 or more messages, categorized by bits of a double integer. This allows for thousands of possible messages to be searched and displayed on just three banners.

This template is for Allen-Bradley ControlLogix, but is quite easy to reproduce on most major PLC platforms. It is even easier on a Siemens platform using STL (Statement List) or by using any of the Structured Text languages. Do-While and For-Next loops are common in these languages, a bit more difficult in ladder logic. Another method of doing this uses Allen-Bradley’s FSC (File Search and Compare) instruction.

This topic can get pretty complex, and as I mentioned involves a lot of other concepts listed in my series on PLCs. I teach automation and programming topics like this for a living and also consult with companies, so if you need help with a program or want to learn more on the topic, hit me up on my company site or Linked In.

Share
Posted in PLCs, Software & Programming Tagged with: , , , , , ,

Ladder Logic 209: Faults and Messages

This post is another in my series on Ladder Logic. As with the other posts in this series, I am using generic logic and addressing so that it can apply to various PLCs.

In previous posts in this series I have explained how numbers can be used in a fault register to determine which fault is present. Ladder Logic 203: Faults shows how a specific fault moves a number into the register, then a reset pushbutton is used to move a zero after the fault is cleared. This logic uses the same technique, however the fault message register is cleared automatically when the fault has been eliminated.

There are several ways to display fault messages on an HMI, I will cover one of the most common first. Most HMI software allows you to make a list of faults and then call them by number to display in a banner or other type of text display.

Another option is to configure the trigger to display the message by bit number as shown above. This also allows multiple messages to be displayed on a timed cycle, unlike if the message were to be displayed by value or placing a number into the message register.

The background color of the message can also be configured so that fault messages and warnings or other informational text can be displayed in the same banner. This is especially helpful if the HMI is small and doesn’t have room for more than one message display.

Besides faults and messages, these displays can be used as multi-state indicators to show the mode of a machine or station status. Other properties of the message display can also be configured such as its visibility.

As with my article on Auto Sequences, there are advantages and disadvantages to using bits versus values. Using bits allows several “states” or messages to exist at the same time, whereas a value allows only one message to be called. If your HMI does not have the ability to cycle through messages with several bit triggers active at the same time, it will be necessary to write code in the PLC that cycles through the messages.

Another method that is sometime used for message displays is to simply place a String Display on the screen. While this is simple on the HMI end, it requires the PLC program to cycle through the strings and place them into the message register, which of course must be of the STRING data type. This technique again has advantages and disadvantages.

On the plus side, string messages can be changed dynamically by the PLC programmer. As a matter of fact, the programmer can give access to the user of the touchscreen by placing links to the locations of the string registers on a screen! This allows the messages to be configured without using the HMI software.

On the minus side, it is difficult to manage background or text colors using strings. The background would have to have a color register assigned to it which would be managed separately.

In my next post I will explain some of the more advanced techniques that can be used to cycle through messages. Stay tuned!

Share
Posted in HMIs, PLCs, Software & Programming Tagged with: , , , , ,

Application: Sensor Choices 103

Courtesy of Misumi via Omron

Today’s post concerns how sensor choices are made in real applications. I have written various posts on sensors in the past, and even participated in a Control Engineering webcast and forum last year on the topic. While I have covered a variety of technical aspects of sensing, I thought I’d explain a bit about how I chose some of the sensors in my own application.

Last Summer I showed some of the fibers I had selected for my tabletop factory, explaining that some sensors were a bit more complex than needed for certain applications. The fiber optics I had installed are now used on a more delicate application as shown in the following pictures:

Escapement Ball Detection

These fibers are positioned to detect small balls as they are ejected through the hole into these plastic boxes.


There are three of these escapements along the indexing conveyor. Each escapement drops a number of different colored balls into each box and the boxes are then examined later with a machine vision system to ensure that the correct balls are in each box.

In this case the balls don’t block the fiber optics for very long and it was important to ensure that the fiber amplifier could switch quickly, so I selected these Banner amplifiers that are used for high speed, small object detection.

Banner Fiber Amplifiers

The threshold can be set remotely using a “teach” signal, but there are also controls on the amp itself to accomplish this.

********************************************

Another special purpose sensor I chose were the ones that are used to detect the plastic boxes themselves.

In this case I was constrained by both space and the fact that other objects were in the way. I want to detect the box, but not the rail on the other side of the conveyor. The sensing range of these sensors is less than two inches.

Diffuse photoeye with box

Diffuse photoeye with no box present

Notice the large cutaway. The sensor would actually detect the rail even though it wasn’t directly in front of the sensor. It’s a bit of a hack job when viewed close up like this, but I can clean it up later.

These diffuse sensors from Automation direct are pretty cool. They are very small, fairly inexpensive, and easy to mount. I have four more of these I need to mount and this application will be complete! Unfortunately two of them are on the back side of the machine and are hard to access.

Close-up of diffuse sensor shooting over rail of conveyor


Another place where there are sensors on this application is on the air cylinders. In this case though there is very little to choose from, since the sensor has to fit in the slot of the cylinder. The only real choices were NPN vs. PNP, or quick disconnect vs. pigtail wiring. These sensors are actually hall effects rather than proxes; they detect the magnetic piston inside the cylinder. Since they have to fit in the slot, the only choices are from SMC.

This is a little insight into some of the decisions that are made in machine design. Often a mechanical designer will draw all of the sensors and brackets into the design before the sensors are purchased, but in my case I just “wing it”. This machine’s entire purpose is to use as a training tool, so a but of imperfection is o.k. After all, troubleshooting and changes will be a big part of what I will be teaching.

Most of this machine is operational now via the touchscreen, at least as far as manual functions. There are indicators for all of the sensors which makes it easy to debug the operation of the system. This is going to be a lot of fun for programmers!

Share
Posted in Applications, Machine Assembly and Fabrication, Photoeyes, Sensing, Sensors Tagged with: , , ,