Software development platforms and the controllers that run the software have taken many steps forward over the years, and sometimes they take a step back

My life as a controls guy for a food co-packer is spent maintaining existing machines and processes with far less of it on my favorite part, software development. Software is my Mount Everest—the peak of my career aspirations. For me, there is nothing finer than getting an opportunity to start with a blank sheet and design software for a packaging machine.

Much in the way that a machine builder would start with a concept and break it down into smaller, more manageable bits, the design of the software is about identifying the functions that make up the bigger “machine” and sorting them into smaller groups to provide better focus. Nearer to the end of the process, we bring all those bundles of code together and make them work with each other.

Over the years, I’ve figured out some techniques that seem to work well, and, naturally, a library of code soon piled up so that I can pull it out whenever I get the opportunity to develop a new application. Periodically, I go back through that library and identify blocks of code that should either be scrapped or could benefit from a do-over.

It’s easy to want to stick with what works, but the risk in that is creating an archaic program that doesn’t allow for flexibility because the designer is so focused on making it all work together that they fail to allow for new ideas and thought processes to enter the picture.

The first hiccough I encountered in my software journey was the transition necessitated by the change in technology from fixed memory-based to tag-based PLCs. Let’s admit it, most programmers might be a tad bit OCD, in that we liked the idea of a bank of memory addresses of a particular type—binary, integer, real—that we could then break down into groups to use for particular parts of the programming process.

For example, I used to program palletizers, and I had multiple infeeds bringing product into the palletizing unit. I quickly developed a pattern for these infeeds where Infeed 1 might use B11, N21 and R31—Bits, iNtergers and Real data types—while Infeed 2 might use B12, N22 and R32, and Infeed 3 would use B13, N23 and R33 for registers during the programming process.

At a glance, the second digit in each would immediately tell me which infeed I was looking at in the program. With the advent of tag-based memory structures, the memory table is completely defined by the programmer. Now, all my tags would appear as Infeed_1.xxx or Infeed_2.xxx and so on.

Most PLC software has a conversion program that allows the designer to quickly convert older programs into the newer tag-based memory allocations. Once converted, the program still appears to be fixed memory mapping but is really just an array of its former self. For example, B13:0/12 might be converted to B13[0].12.

The nice thing about the newer software is the program developer can then rename B13 to be whatever the developer wants it to be, so the final structure might be Inf01_Bits[0].12 to reflect the binary nature of the bits from the original structure.

Once past the tag structure, it quickly becomes apparent that modern programs should be written in object-oriented format. This likens back to Visual Basic, Visual C, Pascal and such programming languages. The modern PLC has much more in common with these languages than the PLC of old does. There are tasks and programs and routines used to break down the code into like areas for both function and organizational purposes.

Function blocks follow, and now the library of old takes on an entirely new use where tried and true code can be used over and over again in a program by mapping internal bits to external bits.

Perhaps I have over-explained some of this, but I am trying to get to a point of understanding—that the software application of today bears little in common with those of even 20 years ago.

As a natural progression of the profession, a programmer must always be reworking code and techniques to keep up with the advances in the hardware platform that the application will run on. The same holds true for the developers of the software application that we use to develop our application on.

It seems hard to imagine any more, but, at one time, a PLC programming software platform might have comprised a core, module-loading program with 6-10 submodules that gave us the programming interface, memory tables and force tables that permitted us to develop our software applications. All of it fit on a 5-1/4-inch floppy disk, or maybe two.

Well, don’t look now, but even my favorite “smart relay” software programming tool now downloads at a massive 2.3 gigabytes. Now, isn’t that a jaw dropper?

I never really paid too much attention, but have a look the next time you are installing a programming software application update. The number of associated files is simply staggering.

One might wonder: How could software development get so complicated? Some of us older folks might remember when you could develop an application in Visual Basic or Visual C, and, while you developed multiple software modules, the finished product compiled into a single executable file.

Elaborate programs might require the use of a technique that swapped modules into and out of temporary memory to handle the physical memory needs of the modules, but even that sounds simple compared to the software environment of today.

A couple of weeks ago, I decided to do my twice-a-year task of updating my application development packages to the latest versions. In many cases, the differences are minor and more often contain fixes for anomalies in previous releases, so the impact is not really noticeable to the end user.

Software releases seem to come along continuously from most hardware/software vendors, but I like to limit my unwilling adventure to twice a year to limit the distraction from my normal work functions. This particular exercise moved along at a comfortable pace, and I was so happy with the results that I took the time to update my protégé's laptop, as well, to save him some time in what for him is a far busier schedule than my own.

He is a primary support for our maintenance department, while my role is to support the same group if he is unable to successfully resolve issues. I’m sort of the backup to the backup.

As you have now guessed, the successful conclusion of my biannual software updates exercise wasn’t quite as successful as I originally thought. There I was, gearing up to make a quick change to a mini-PLC to add an additional output function when, out of nowhere, my off-line version of the program won’t open up on my laptop.

Sure, it loaded the name and showed it on the correct spot on the screen, but there wasn’t anything in the navigation pane. I am at a total loss to understand what happened, and my colleague was waiting for me to make that simple little change, so we could set a line up for operation the following morning.

I will save you the longer version and a few words I might have uttered under my breath, but I ended up having to ask my ever-faithful creator of magic—my electrician extraordinaire—to rig up a couple of wires to parallel another function in the control cabinet to mimic what my software change was to accomplish.

After a lot of digging, I found a note in an online forum about a recent Microsoft security update that might be messing up my programming software. The note read, “Applications that use a Microsoft Jet database with the Microsoft Access 97 file format may fail to open if the database has column names greater than 32 characters. The database will fail to open with the error, ‘Unrecognized Database Format’”.

The result was that certain programming software applications may not open user programs. Well, as it turns out, a recent operating system “security” update changed something that interacts with my programming application. I didn’t even know what Microsoft Jet was, but apparently it is a new database that might use an older format database that was being used by my new, latest version of the application development software.

The suggested fix—a newer Microsoft update—didn’t fix my issue, and I ended up uninstalling the latest version of my development software and reinstalling the previous version. Once done, my software application would open as expected, and I was able to make the programming changes and download the new version into my micro-PLC.

When I finally caught my breath, I started to think about how this all came about. At first I was mad at Microsoft for providing a security update. Then I realized that they’re doing their best to protect our computers and servers from those out there in cyberspace who would want to do us harm.

Then I was mad at the creator of my application development software for using a third-party program module inside the code. It was at that point that it suddenly dawned on me that this unseen person who had just suffered my wrath and a stream of muttered expletives, was really just doing what I do every time I sit down to develop some software code. I don’t have time to reinvent the wheel every time I set out to write an application, so I do only what comes naturally. I look to my library of code and pull out something that already does what I want to do and incorporate it into my application.

If you watch more closely the next time you install some software on your computer, you might notice that some of those files that are getting added to your hard drive are the files that link the software application to some industry-standard base modules that make all this happen.

While not every circumstance can be anticipated, the interdependence between software applications and the base operating system files through the use of dynamic link libraries (DLLs) is susceptible, from time to time, to the need to keep updating our computers’ systems to defend against the bad folks out there who want to disrupt our ability to perform our jobs through our dependency on our computers and laptops.

Lots of people spend the entire day writing and reviewing code, all in an attempt to keep our world moving along at this breakneck pace where everything is at our fingertips. Every once in a while, a ripple happens where the need to protect doesn’t take into account the impact due to dependency of software modules on other software modules.

Should this happen to you, take a breath, have a coffee, do whatever you need to do to calm down, and then remember that we all have a job to do and sometimes things just happen.

Rest assured that, if it is happening to you, then it is likely happening to someone else, and, for sure, at least one of those people is going to complain and start the ball rolling on a resolution to your issue.

Had I not had the need to update that mini-PLC, the ripple and the resolution might have happened without me even knowing it existed. I wonder how many times that happens every day of my life.