Contact and Coil | Nearly In Control

CAT | Automation

Mar/17

26

PLC Programming goes Imperative

Decades ago, computer science emerged from the dark ages of assembly language programming and created two new languages: Lisp and Fortran. These are two very important computer languages because they exist at opposite ends of an imagined spectrum in the eyes of computer scientists: functional languages vs. imperative languages.

Fortran “won” the first battle, not least because imperative languages are closer to how the CPU actually does things, so back in the day when every little CPU cycle mattered it was easier to understand the performance implications of a Fortran program than a Lisp program. Plus, if you were already programming in assembly, then you were already thinking about how the computer was executing your code. In fact, the next big imperative language, C, is often referred to as “portable assembly language.” Fast forward to now, and modern languages like C#, Java, Python and Ruby have all grafted a lot of functional programming features onto their imperative programming basic syntax. In C#, for instance, Linq is a direct rip-off of Lisp’s S-Expressions and it now has Closures and lambda functions. Functional languages provide ways to think at a higher level than imperative languages. In a functional program you describe what you want and in an imperative program you describe how to do it.

Here’s an example in C#, using imperative programming:

var data = new int[] { 1, 2, 3, 4, 5 };
var sumOfSquares = 0;
for(var i = 0; i < data.Length; i++)
{
    sumOfSquares += data[i] * data[i];
}

…and the same thing done functionally:

var data = new int[] { 1, 2, 3, 4, 5 };
var sumOfSquares = data.Select(x => x * x).Sum();

In the second case, I’m taking the list of numbers, using Select to translate that into a list of their squares (also known as a Map operation) and then using Sum on the resulting list to compute an aggregate sum (also known as a Reduce operation). It has some interesting advantages. For instance, the original code can’t be split across multiple cores, but the latter can. Also, if you know both syntaxes, the latter is easier to read and understand.

Now take ladder logic. I’ve made the claim before that basic ladder logic (with contacts and coils) is actually a functional language. A simple example might be ANDing two inputs to get an output, which in C# would look like this:

var output = inputA && inputB;

That’s actually functional. If I wanted to write it imperatively I’d have to do something like:

var output = false;
if(inputA && inputB)
{
  output = true;
}

In ladder logic, that would be the equivalent of using an unlatch (or reset) instruction to turn off an output and then using a latch (or set) instruction to turn on the output if the A and B contacts were true. Clearly that’s not considered “good” ladder logic.

Similarly, a start/stop circuit goes like this:

var run = (start || run) && !stop;

Now historically, mathematicians and physicists preferred functional languages because they just wanted to describe what they wanted, not how to do it. It’s worth noting that electricians, looking at ladder logic, prefer to see functional logic (with contacts and coils) rather than imperative logic (with sets, resets, and move instructions).

In recent years we’ve seen all major PLC brands start to include the full set of IEC-61131-3 languages, and the most popular alternative to ladder logic is structured text. Now that it’s available, there are a lot of newer automation programmers who only ever knew imperative programming and never took the time to learn ladder logic properly, and they just start writing all of their logic in structured text. That’s why we’re seeing automation programming slowly shift away from the functional language (ladder) towards the imperative language (structured text).

Now I’m not suggesting that structured text is bad. I prefer to have more tools at my disposal, and there are definitely times when structured text is the correct choice for automation programming. However, I’d like to point out that the history of computer science has been a progressive shift away from Fortran-like imperative languages towards Lisp-like functional languages. At the same time, we’re seeing automation programming move in the opposite direction, and I think alarm bells should be going off.

It’s up to each of us to make an intelligent decision about what language to choose. In that respect, I want everyone to think about how your brain is working when you program in an imperative style vs. a functional style.

When you’re doing imperative programming, you’re holding a model of the computer in your mind, with its memory locations and CPU and you’re “playing computer” in your head, simulating the effect of each instruction on the overall state of the CPU and memory. It’s only your intimate knowledge of how computers work that actually allows you to do this, and it’s the average electrician’s inability to do this which makes them dislike structured text, sets, resets, and move instruction. They know how relays work, and they don’t know how CPUs work.

If you know how CPUs work, then I understand why you want to use structured text for everything. However, if you want electricians to read your logic, then you can’t wish-away the fact that they aren’t going to “get” it.

As always, be honest with yourself about who will read your logic, and choose your implementation appropriately.

·

When traditional PC programmers see ladder logic, they think ladder logic programmers are terrible programmers. Being both a .NET developer and a ladder logic programmer, this has caused me a lot of frustration and confusion over the years. I have one foot in each world, and yet I choose to write C# programs one way and ladder logic programs another. Why?

Let’s ignore the fact that most traditional programmers just don’t grok ladder logic at all, because their minds think about programs sequentially rather than in parallel. The real reason they hate ladder logic is because ladder logic programmers avoid things like loops, indexed addressing and subroutines. To them, this means you’re programming at the level of an 8 year old.

The thing is, I know how to use loops, arrays, and subroutines, not to mention object oriented programming and functional programming constructs like s-expressions, closures and delegates. Still, I choose to write simple and straightforward ladder logic. Why would I, an experienced programmer, choose to write programs like an 8 year old? Do I know something they don’t?

I spend a lot of time trying to get people to think about why they do things a certain way. Everyone wants that simple rule of thumb, but it’s far more valuable to understand the first principles so you can apply that rule intelligently. Decades of computer science has given us some amazing tools. Unfortunately, a carpenter with twice as many tools in her tool box is simply twice as likely to pick the wrong tool for the job if she doesn’t understand the problem the person who invented that tool was trying to solve.

The first time you show a new programmer a “for” loop, they think, “Amazing! Instead of typing the same line out a hundred times, I can just type 3 lines and the computer does the same thing! I can save so much typing!” They think this because they’re still an idiot. Don’t get me wrong, I was an idiot about this too, and I’m still an idiot about most things. What I do know, however, is that for loops solve a much more important problem than saving you keystrokes. For loops are one of many tools for following the Once and Only Once (OAOO) Principle of software development.

The OAOO principle focuses on removing duplication from software. This is one of the most fundamental principles of software development, to the point where it’s followed religiously. This principle is why PC programmers look at ladder logic and instantly feel disgust. Ladder logic is full of duplication. I mean, insanely full of duplication. So how can you blame them? God said, “let there not be duplication in software,” and ladder logic is full of duplication, thus ladder logic is the spawn of Satan.

That’s because programmers who believe the OAOO principle is about removing duplication are idiots too. Don’t they ever wonder, “why is it so important to remove duplication from our code?” Should we really worry about saving a few bytes or keystrokes? NO! We focus on:

  1. Making it do what it’s supposed to do
  2. Making it obvious to the reader what the program does
  3. Making it easy to make changes when the requirements change

… in that order.

In fact, #3 is the real kicker. First of all, satisfying #3 implies you must have satisfied #2, so ease of understanding is doubly important, and secondly, satisfying #3 implies you can predict what will change.

Imagine if you have to print the numbers from 1 to 5. If I asked a C# programmer to write this, they’d likely write something like this:

for(var i = 1; i <= 5; i++)
{
    Console.WriteLine("{0}", i);
}

… of course I could write this:

Console.WriteLine("1");
Console.WriteLine("2");
Console.WriteLine("3");
Console.WriteLine("4");
Console.WriteLine("5");

Why is the first way better? Is it because it uses fewer keystrokes? No. To answer this question, you need to know how the requirements of this piece of code might change in the future. The for loop is better because many things that might change are only expressed once. For instance:

  • The starting number (1)
  • The ending number (5)
  • What to repeat (write something to the screen)
  • What number to print
  • How to format the number it prints

If the requirements of any of these things change, it’s easy to change the software to meet the new requirements in the first case. If you wanted to change the code so it prints every number with one decimal place, the second way clearly requires 5 changes, where the first way only requires one change.

However, what if the requirements changed like this: print the numbers from 1 to 5, but for the number 2, spell out the number instead of printing the digit.

Okay, so here’s the first way:

for(var i = 1; i <= 5; i++)
{
    if(i == 2)
    {
        Console.WriteLine("two");
    }
    else
    {
        Console.WriteLine("{0}", i);
    }
}

… or if you wanted to be more concise (but not much more readable):

for(var i = 1; i <= 5; i++)
{
    Console.WriteLine(i == 2 ? "two" : i.ToString());
}

Here’s the change using the second way:

Console.WriteLine("1");
Console.WriteLine("two");
Console.WriteLine("3");
Console.WriteLine("4");
Console.WriteLine("5");

Here’s the thing… given the new requirements, the second way is actually more readable and more clearly highlights the “weirdness”. Does the code do what it’s supposed to do? Yes. Can you understand what it does? Yes. Would you be able to easily make changes to it in the future? Well, that depends what the changes are…

Now think about some real-life ladder logic examples. Let’s say you have a machine with some pumps… maybe a coolant pump and an oil pump. Your programmer mind immediately starts listing off the things that these pumps have in common… both have motor starters with an overload, and both likely have a pressure switch, and we might have filters with sensors to detect if the filters need changing, etc. Clearly we should just make a generic “pump” function block that can control both and use it twice, right?

NO!

Look, I admit that there might be some advantage to this approach during the design phase if you had a system with 25 identical coolant pumps and your purchasing guy says, “Hey, they don’t have the MCP-1250 model in stock so it’s going to be 8 weeks lead time, but they have the newer model 2100 in stock and he can give them to us for the same price.” Maybe it turns out the 2100 model has two extra sensors you have to monitor so having a common function block means it takes you… 20 minutes to make this change instead of an hour. We all know how much you hate repetitive typing and clicking.

On the other hand, when this system goes live, making an identical change to every single pump at exactly the same time is very rare. In fact, it’s so rare that it’s effectively never. And even if that were to ever actually happen, the amount of programming time it actually saves you is so tiny compared to the labor cost of actually physically modifying all those pumps that it’s effectively zero.

However, since these are physically different pumps, you’re very likely to have a problem with one pump. When your machine is down and you’re trying to troubleshoot that pump, do you want to be reading through some generic function block that’s got complicated conditional code in it for controlling all 50 different types of pumps you’ve ever used in your facility, or do you want to look at code that’s specific to that pump? And maybe the motor overload on that pump is acting up and you need to put a temporary bypass in to override that fault. Do you really want to modify a common function block that affects all the other pumps, or do you want to modify the logic that only deals with this one pump? What’s more likely to cause unintended consequences?

So this is why ladder logic written by experienced automation programmers looks like it was written by an 8 year old who just started learning Visual Basic .NET last week. Because it’s better and we actually know why.

·

Feb/17

12

How Automation is Shaping our Society

Try this on for size:

We’ve been automating for hundreds of years now. The industrial revolution caused a migration of workers from agriculture into the cities to work at factory jobs, and workers that are displaced by new technologies will find new work that didn’t even exist a few years ago.

I assume if you’re reading this article that you’re involved in automation in some way, so you’d actually want to believe that statement, and arguing against what someone wanted to believe would be pointless. I’m going to do it anyway. That statement is wrong. This time it really is different.

To explain this I need you to consider what motivates people here in the “west”. Basically we have some form of regulated capitalism. To boil that down, it means you can own things, and you are allowed to keep some fraction of the proceeds that are generated from those things. This actually applies to almost all of us, even if most people don’t think of it that way. It’s obvious to a farmer: you own land, buildings, and equipment, you grow things and sell them, and after tax you hope to end up with some kind of a profit. Ok, perhaps farming isn’t a great example because there are so many government subsidies involved, but the principle is the same with small business owners, and even employees.

Employees? Most employees don’t think of themselves as capitalists because they can’t see the capital they’re using to generate a profit, but it’s right there in the mirror. You are your own capital. Ever since abolition, this is capital that nobody could take away from you. It’s the first and primary social safety net. No matter how penniless you were, barring illness or infirmity, you had this basic nest egg of capital you could always draw from to bootstrap your life. Most people mistake capital for money, and that’s why they don’t see themselves as capital. After all, you can’t “spend yourself”, can you? Actually, going back hundreds of years, you could. Most slaves around the Mediterranean hundreds of years ago were slaves because they incurred debts that they couldn’t pay off, so they became the property of whoever they owed the debt to, until they could work off their debt.

If it helps, think of the human body as a machine that turns food into… various useful things more valuable than food. Farmers turn small amounts of food into larger amounts of food. Carpenters turn food and wood into houses or furniture. Quantum physicists turn food into transistors and lasers, and you, dear reader, perhaps you’re a machine that turns food into PLC programs. In turn, we trade these things for various useful things that other people have created. Capitalism.

Now I’m a fan of regulated capitalism because it’s an efficient way to organize lots of machines (us) into producing lots of valuable things like cars, houses and episodes of Game of Thrones.

Now here’s the weird part. There’s a huge incentive to use your capital to acquire more capital, which you can then use to acquire more capital, and so on, but very few people do this. You would think that someone who finished 13 years of schooling at the age of 18, worked 47 years and retired at the age of 65, making, let’s say, an average modest wage of $30,000 per year in present-day dollars would have had the foresight to save some of that $1.4 million for their retirement, but it’s clear that many don’t. In fact there are many people with an income far higher than that who not only don’t save any, but go into significant debt and either declare bankruptcy or become virtual slaves to credit card companies. It’s so incredibly common and has such a negative cost to society that governments actually force workers to save portions of their paycheque every week into a government pension program and then pay them a stipend when they retire. I’m not familiar with the way this works in the United States, but in Canada this is referred to as the Canada Pension Plan, and it’s supplemented by something called Old Age Security that kicks in a few years later. This is despite the fact that anyone who bothered to squirrel away 18% of their net paycheque for their entire career into a tax sheltered retirement savings plan and invested it in mutual funds would have a very comfortable retirement – much more comfortable than living on a government pension.

Now part of me thinks this is fine: you made your bed, now lie in it. But this affects everyone, even the wealthiest capitalists. The most basic of government services are the ones that wealthy people need most: military, police (criminal law) and the enforcement of contracts (civil law). These three services of government are what give people the ability to own things. The military protects it from external threats, the police protect it from people inside the country (thieves and vandals), and civil law settles disputes about who owns what.

We keep hearing that wealth inequality is a bad thing, but that can’t be absolutely true. If our system is working, it has to reward the people doing more valuable things with more money, so the only way there could be income equality is if everyone was doing something equally valuable, and we’re not. There should be a way for me to make more money by working harder, smarter, or differently than I am now. That’s the incentive to be more productive.

In fact, that’s what really matters: does the average person believe they can improve their standing? Because if they don’t, they get unruly and do wild and crazy things. Things that make wealthy people uneasy because in the west those unruly people can really mess with the government that’s providing all those military, police, and civil services they depend on.

Imagine you work in a factory in the Midwest U.S. that makes air conditioners. Chances are, you don’t think of yourself as a machine that turns food into air conditioners. You’re not thinking about how to make that machine more efficient, or more valuable. You’re already working 6 days a week, and your family never sees you. All you know is that sooner or later the guy who drives the fancy BMW is going to move your job to another country, or replace you with a robot, and since all the other plants around here have closed, you might not be able to send your kid to college. How would you feel? Maybe you’d be inclined to vote for a politician that promised to punish companies that moved their factories to Mexico.

I think the crux of the matter is that this worker no idea what to do. The incentives are still there: learn a new skill, invest in yourself, be more productive. But few people do it, for the same reason that few people save for their own retirement.

I’ve spent a few years around people who’ve been running small businesses, and I’ve tried to pay attention. It took me years to really understand that there was nothing magical about running a business. That’s because, like almost everyone else, I was brought up with the idea that innovative geniuses come up with brilliant new ideas and start companies that make billions of dollars. Outside of a few small cases, that’s simply not true. Look hard enough and you can find an industry that’s in demand and growing. If the demand is high, there will always be companies in that industry that are poorly run but still make a profit. You can make money simply by doing the same thing as everyone else and simply not being the worst at it. That’s how capitalism works – it gives you incentives to provide products and services that are in demand.

I have a relative that got laid off many years ago. There was a jobs program where they gave him classes on how to start a small business. He learned how to keep books, write an invoice, and how to do his taxes. They hooked him up with a small business loan. A few months later he’s running his own business and a couple years after that he’s hired an employee. Now he has the opportunity to invest in himself, like buying better equipment and improving his skills.

Let’s say you’re a PLC programmer. Your company likely pays you upwards of $50,000 a year. How much did they spend on your computer? Did they cheap out? Does it make any sense to handicap a $50,000 a year resource with a cheap laptop? If you were in business for yourself, you’d quickly realize there aren’t many things you could invest in that would make you a more efficient or valuable PLC programmer, but a faster computer is a no-brainer.

Automation is increasing productivity and with self-driving trucks and expert systems being developed, the rate of productivity increase is set to explode. However, these are expensive investments and there’s no way for displaced workers to take advantage of this automation. If I gave a truck driver a bigger truck, they produce more value per mile driven, but if I replace the driver with a computer, they have no value at all.

Increased productivity stopped producing higher wages back in the early 70’s. A bank teller makes the same now as they did back then (adjusted for inflation) even though most of the drudgery has been offloaded to ATMs. In fact, ATMs allowed banks to open more smaller branches and the demand for tellers to staff those branches has actually increased the number of tellers total, but despite automating the simple tasks and increasing demand for tellers, they’re not making any more in wages.

The same people who are currently blaming immigration and outsourcing for their problems are soon going to realize that automation is what’s really eating their lunch. Unlike in the industrial revolution where displaced workers could participate in this new economy by switching from farming to factory work, during this transition workers will either lose their jobs and have to completely re-skill, or at best they’ll keep their jobs but not see a penny more for their increased productivity.

That’s because old automation made people more valuable, but new automation seems to make them less valuable. That means it’s devaluing the one bit of capital they have.

This is where someone usually suggests a universal basic income so everyone can share in the increased productivity without everyone contributing to it. I’m not convinced the numbers add up. What we really need is to encourage this idea of viewing yourself as capital, not as an employee. An incentive and a safety net for people starting a small business should be less expensive and more effective than paying people to sit at home. How about teaching this stuff in school (I figure teachers are pretty clueless about starting a business). How about making it easier to start a business than going on social assistance? How about making in-demand skills training free?

I’m glad we’re talking about this because it does matter. A lot of this is tied in with what’s going on in the world right now. There’s a general sense that the next generation won’t be as well off as their parents’ generation, and that’s pretty much unprecedented. That promise that anyone could make something of themselves is slipping away, and we need that back.

·

I’m not a lawyer and what follows is not legal advice. What I’d like to do here is point out some minimum things that you need to be aware of if you’re doing control system integration when it comes to intellectual property. I hope you can appreciate that there are subtle details that can affect the reality of your situation and you should consult a lawyer depending on your situation, geographic location, and product.

If you do control system integration for a living then you deal every day with intellectual property. Ladder logic (or structured text, etc.) is code, and code is automatically copyrighted. Electrical designs are also intellectual property. The important thing to realize is that somebody owns that intellectual property, and people are sometimes surprised by who owns it.

Here’s a typical situation: you work for a control system integrator and they’re doing a fixed price (or “turn-key”) project for a customer. In this case the ownership of the copyright should be spelled out in the contract, and most control system integrators will specify that the copyright belongs to the integrator, but part of the purchase price of the project covers a license to use that software in their facility. There are very good reasons for this. The integrator works on many different projects for many different customers and over time you’re going to see the same problem over and over so you want the ability to maintain an internal library of tested code that you can re-use on future projects. Not only does this make you more efficient, but it’s almost impossible to avoid writing the same code again when you see a problem that you’ve solved before.

In this case the customer, to protect themselves, needs to insist on a license that will cover all of their needs, including the ability to see and modify the code, including having someone else come in and modify it, though only for use in that facility or on that machine, as the case may be.

Now consider a very different situation. You’re a control system integrator doing a time-and-material project for a customer. They have their own internal PLC ladder logic standard, including a library of function blocks, and they know how they want everything written. They give you a sample program and tell you to start with that and modify it to suit the machine you’re building. This is a completely different case. The copyright of the finished PLC program is almost certainly owned by the customer, not the integrator. The integrator and the customer should both be making sure that the contract specifies this in writing. This creates some interesting differences for the integrator.

The integrator cannot (and should not) be using their own internal library of code on this project, or the customer could end up claiming copyright on the integrator’s code. Even more importantly, the integrator should definitely NOT take code they see in the customer’s standard library and put it in their own internal library. Here’s what could happen: you take code from customer A and put it in your library. You use that code on a project for customer B, and it happens that customer B is a competitor to customer A. Customer A’s lawyers can now use the legal system to prevent customer B from using that machine without paying royalties to customer A.

You may be wondering, “how would customer A even find out that this happened?” There are several ways… for one, people in the control system industry move around. A lot. Trust me, it’s a small group of people and everybody knows each other. It’s not a big stretch for someone who worked at customer B to end up at customer A. For another, sometimes employees just talk. I’m writing this because just the other day I witnessed an employee from a local integrator say out loud that they’d done just this… took some function blocks from their customer and used it on other projects for other customers… and they said this in front of the customer they took them from! Now, the representative from the customer seemed to think this was OK, but I doubt their corporate lawyer would agree, and I doubt this agreement was in writing. If some future customer of the integrator ever got in trouble legally, what do you think would happen to that integrator?

I realize it’s sometimes hard to adjust from a university environment with the free flow of ideas, where everyone’s downloading copyrighted movies and songs from peer-to-peer networks all day long, and then work in a corporate environment where the stakes are much higher, where lawyers and executives on both sides would love to find some leverage over their competition. Seriously, it’s not worth your career. Take a moment to school yourself on intellectual property law and how it affects your profession. This can be a big deal. Be careful.

·

Apr/16

3

TwinCAT 3 Tutorial Complete

Over the past year I’ve been working on a TwinCAT 3 Tutorial, and with the posting of the 13th chapter about the TwinCAT 3 Scope View, I’m considering it “complete.” I’ve covered all the major topics that I wanted to cover.

Writing a tutorial like this was actually a learning experience for myself. Before I made any statement about the software I tried to validate my assumptions first, and many times I learned that I had preconceived notions about how it worked which may not have been completely accurate. If you’re a TwinCAT 3 programmer, then you need to know your tool set inside and out. If you’re not sure how something works, it’s best to setup a quick test and try it out. That’s one of the advantages of PC-based software: if you want to run a test, your office PC is a laboratory environment. Write some code and run it.

Thank you to everyone who offered feedback on the existing sections, and to those of you who kept pushing me to continue writing more. I sincerely hope this can be that missing link to take people from the world of traditional PLCs into the more interesting and ultimately more powerful world of PC-based control.

It looks like TwinCAT 3 has a viable future ahead of it. Interest seems to be growing over time (according to Google Trends, anyway):

That makes TwinCAT 3 a valuable skill to learn if you’re an integrator, and an interesting technology to investigate for existing plants.

· ·

Feb/16

20

How to Write a Big PLC Program

Staring down the barrel of a big automation programming project is intimidating. It’s hard to even know where to start. Even when you’ve done a few before, you’re only marginally more confident the next time.

I have quite a few big automation programming projects under my belt, so I think I can generalize the process a bit. Here goes:

1. Get the Prints

There’s almost no point in starting to program unless you have an almost final set of electrical drawings. If you don’t have them yet, push for them, and go do something else productive until you get them.

2. Create a Functional Specification

You don’t always have to write out a functional specification, but it at least needs to exist very clearly in your head. If at any point, you don’t know exactly how the machine is supposed to work in excruciating detail, stop writing code and go figure it out. Ask stakeholders, talk to operators, whatever it takes. Functional specifications are best written as a list of “user stories”. If you’re not sure what a functional spec should look like, check out Painless Functional Specifications by Joel Spolsky.

3. Shamelessly Copy

Identify what other projects you can find with logic that you can steal. Any code that works in another machine has the advantage of already being debugged. Don’t re-invent the wheel. (At the same time, never blindly copy logic without understanding it. Copying the code by re-typing it one rung at a time is still faster than writing it from scratch, and it’s a form of software review.)

4. Structure Your Project

Now you break open the ladder logic programming software and start creating your project. Pick your CPU type, setup the I/O cards based on the electrical drawings. Map your inputs. Plan out your program by creating programs or routines for each functional unit of the machine. Setup your fault summary rungs and your alarm logic.

5. Write the Manual Mode Logic

PLC logic is typically written “bottom up.” Manual mode logic is the lowest level of logic because it deals directly with individual functions in the machine. Advance cylinder. Retract cylinder. Home axis. Jog axis. While you’re writing the manual mode, this is when you take extreme care making sure that actions are interlocked so the machine can’t crash. If you’re using the Five Rung Pattern, this means paying attention to what goes in the Safe rung. Does cylinder A always have to advance before cylinder B can advance? The Safe rungs should reflect that. Make sure that even in manual mode, the operator (or you) can’t break the machine. Make sure to hook your faults and alarms into the applicable fault summary rungs and alarm logic.

6. Write Part Tracking Logic

Now that manual mode is complete, write the logic that tracks parts (and their state) through the machine. Remember, you should be able to run the machine in manual mode, and the part tracking should (ideally) work correctly. I know this isn’t always the case but surprisingly part tracking in manual mode can work 95% of the time. That means part tracking works based on the state of the machine. Closing the gripper with the robot in the pick position and the part present in fixture sensor on should latch a bit “remembering” that the gripper has a part in it.

Once you’ve written your part tracking logic, go back and use the part tracking and state bits to condition your Safe rungs. Don’t let the operator (or you) mistakenly open the gripper if the gripper has a part and isn’t in a safe position to let go of the part. Of course, you may need to add a way to manually override this (that’s what output forcing was created for), but in most cases you want to prevent improper operation.

Part of writing the part tracking logic is adding “ghost buster” screens. Operators often need to remove parts from a cell, and if the machine can’t detect their removal, then you have to provide the operator with a way to clear these “ghosts.”

At this point you’re actually ready to dump the program in and start testing out the machine electrically and mechanically. While it’s ideal to have a fairly complete program when you go onsite, we all know that’s not always entirely possible. At the very least you want to get to this point before startup begins.

7. Write the Auto Mode Logic

The complexity of your auto mode logic depends on what type of machine you’re programming. You’ll always need a cycle start and a cycle stop feature. Even if you’re in auto mode, you usually don’t want the machine to start until the operator specifically tells it to start. Once it’s running, we call this “in auto cycle.”

In simple machines, you can write the auto logic by filling in the Trigger rungs in your Five Rung logic. Start by putting the In Cycle contact at the beginning of the rung, and then writing logic after that which expresses when the action should take place. For instance, an advance reject part cylinder’s Trigger rung could be as simple as In Cycle, Part Present, and Part Rejected. As long as the Part Present tracking bit gets cleared once the cylinder is in the advanced position, then this is all the auto mode logic you need for this motion. Have the retract Trigger rung be In Cycle, No Part Present and Not Retracted.

More complicated machines need more complicated auto mode logic. If your machine has to perform a series of steps (even if some of them are in parallel) then consider using the Step Pattern. If your machine needs to choose between several possible courses of action (commonly seen in a storage and retrieval system) then consider using the Mission Pattern.

8. Review

It’s hard to write correct logic. Review your functional specification, point by point, and make sure your logic meets all of the requirements. Check your logic for errors. A fresh look often uncovers incorrect assumptions, typos, and outright mistakes. The earlier you find and fix problems, the easier they are to fix.

Make a list of everything you have to do during startup. Starting up a machine is time consuming and therefore expensive. Anything you can do to prepare saves you time and money.

Good luck, and keep your fingers out of the pinch points!


· ·

The recent drop in the world price of oil has caused a similar drop in the value of the Canadian dollar. Much of that has to do with the huge oil production in Alberta, so that province is being hit particularly hard right now. The “oil sands” in Alberta are particularly expensive to exploit, as oil sources go, so companies there are quick to make cuts when the price drops below their break-even point.

The previous run-up in oil prices saw a lot of migration out of manufacturing-heavy Ontario westward to Alberta, and control system specialists were a big part of that. It’s difficult to see them facing these challenges, and none of us want to be in that position.

Back here in Ontario, the pendulum looks like it’s swinging the other way. When rising oil prices drive up the Canadian dollar, it makes it a lot harder for Canadian manufacturers to compete in the export market, because their products are automatically more expensive. The recent drop in the Canadian dollar, if it persists, is going to mean growth in the manufacturing sector, especially along the 401 corridor in Ontario. Personally I’m looking forward to seeing some growth in what has been a relatively stagnant market over the past 10+ years.

Automation is poised to be a big part of the new growth in Ontario. At first companies are likely to be cautious about adding new capacity, likely adding temporary labour, but if the trend holds, I think we’re going to see lots of interest in automation projects throughout the area. Companies are still a bit leery of the economy, so they’ll be looking for flexible automation that can adapt to changes in demand and re-tool quickly. Technologies that can support flexibility are going to be winners.

While disappointing for Alberta, I’m excited to see what the future holds for Ontario.

If you do happen to be out in Alberta and you have discrete automation programming experience, and you’re interested in moving back to Ontario, make sure you drop me a line. We’ve experienced lots of growth ourselves in recent years, so we’re interested in hiring an experienced automation programmer for our Electrical Engineer position. We use TwinCAT 3 and C# and mentoring is available to get you up to speed with these technologies. Even if you’re local and you’re tired of the endless travel or 2 am service calls, then maybe this family-friendly company is right for you.

·

Jan/16

17

Start your own Automation Blog!

One thing I’ve discovered about automation blogging is that it’s a pretty lonely place. Don’t get me wrong, there are a couple gems out there, but I don’t find many people writing about what it’s like in the trenches wading through rungs of ladder logic. In the .NET world there are tons of programming blogs with posts about every issue you could ever come across. Why such a dearth of information in the automation space?

It occurs to me that blogging seems difficult to a lot of people, as if you need to be a web programmer. That’s totally untrue (I’m absolutely not a web programmer). In fact there are a ton of inexpensive and simple options out there.

Maybe people wonder what to write about. That’s easy. At first I worried about writing something people didn’t already know, but it turns out there’s no shortage of shiny new graduates looking for any toe-hold they can get in this industry. Try to think back to when you didn’t know anything. How did you figure out how to get online with a PLC the first time? Did you have to call the office to ask someone, and feel foolish because you didn’t know what a Null Modem cable was? We were used to asking our peers for help, but the new generation grew up looking up how to do things on the web.

Maybe you’re worried about the cost. Shared hosting plans are very inexpensive. I use DreamHost, specifically because they’re inexpensive (starts at $9 per month including domain name, unlimited storage and bandwidth), the hosting is rock solid, they offer one-click installs of blogging software (such as WordPress), and their technical support is excellent.

It would really be great if I didn’t feel like the only voice in this cloud. Grab a blogging account and chime in. Write about a hard problem and how you solved it. Disagree with me! Help me learn something new!

·

Nov/15

1

Offline Changes to a PLC Program

As a PLC programmer, you’ll often be asked to do a change to an existing system. If there’s a significant amount of functionality to be added, you generally get your changes ready “offline” and then do all the changes during a short window of time to minimize disruption to the production schedule.

If you’re using an Allen-Bradley PLC, the procedure is typically this:

  1. Get a copy of the latest program from the PLC (a.k.a. an “upload”)
  2. Make your changes to the offline copy, and write down every change you had to make
  3. Go online with the PLC and apply your changes as online changes

Step 3 is much safer than just taking your modified program and doing a “download”. That’s mainly because when you download, you’re not just downloading the program, but the memory state of the PLC as well. The PLC typically has to track things in memory (like recipe data, part tracking, data collection, sequence numbers, machine counters, etc.). If you do a download, you’re going to overwrite all those values with previous values, and that can cause a lot of problems. The other thing step 3 saves you from is simultaneous changes that were done online while you were busy making offline changes.

The only other option you have is upload-change-download, but you really have to shut the machine down for the duration to make sure that the internal state doesn’t change.

When I did a lot of Allen-Bradley programming, I didn’t question that. It’s just how it was. I remember visiting a plant one time for a service call, and the local maintenance person was a bit suspicious of what I was going to do (after all, I was a young kid who had never seen this machine before). He decided to quiz me a bit, and one of the things he asked was, “when you go online, do you download or upload?” I said “it depends,” but his answer was, “you never download.” I agreed that someone in a maintenance role should never need to do a download unless they’re replacing a CPU, or recovering from a corrupted PLC program.

Now that I mostly do Beckhoff TwinCAT 3 programming, I realized one of the benefits are that offline changes are a breeze. It’s due to the fact that TwinCAT 3 completely separates the program from the memory data. The program is stored in local files on your hard drive and compiled into a TMC file. The persistent data is stored in a different place on your hard drive.

When I want to do offline changes to a TwinCAT 3 project, here’s the procedure:

  1. Get a copy of the latest program
  2. Make your changes to the offline copy
  3. Copy changes back to the machine (keeping a backup, of course), rebuild, and activate configuration

This makes offline changes go a lot more smoothly, of course. I don’t have to copy and paste my changes in while online, so it takes less time and eliminates the possibility of a copy/paste error.

Since we also use Mercurial for version control, getting a copy of the latest program is a matter of pulling the latest from the source control, and copying it to the machine is a matter of pulling the offline changes to the machine. Any changes that were done in parallel can be merged with Mercurial’s built-in diff and merge utilities. (Note: I/O changes can’t be merged nicely, so if someone changed the I/O while you were doing your offline changes, you have to copy those changes in manually, but that’s rare and at least it tells you that it can’t merge them.)

This got me thinking that Allen-Bradley probably has a better way of doing offline changes that most of us just don’t know about. I know that you can do an upload without uploading the memory. However, it seems like it requires you to download both the program and data at the same time. I wonder if anyone out there knows how to do better offline changes to a ControlLogix. If so, I would be interested to know that.

· · · ·

Oct/15

18

Announcing: the TwinCAT 3 Tutorial

Some of you may have noticed the new section on this site: TwinCAT 3 Tutorial.

I’ll be building this over the next several weeks or months. I’m working on making it more detailed than the RSLogix 5000 Tutorial.

Rather than being an introduction to PLCs, I assume most readers are coming to the new tutorial with some automation experience and they really want to know what this new technology can do for them. I won’t be touching on every single feature of TwinCAT 3, but I certainly want to touch on most of the common ones, and particularly some advanced features that really set TwinCAT 3 apart from traditional PLCs.

As always I greatly appreciate any comments you have. Please send them to my email address (which you can find on the About page).

·

Older posts >>

Theme Design by devolux.nh2.me