How I Work

I've recently been doing a lot of factory tours and explaining what I'm looking for in hiring somebody to join me as a team.

In explaining my work, I'm finding that it helps me process some of the software development goals I have.

Knowing that the visitors have little familiarity with the type of work I do helps me stay at a more abstract and easier to understand level. I find that reflecting on recent tours helps me reason about my own work through fresh eyes.

A recent twitter musing from GeePaw Hill got my attention:
https://twitter.com/GeePawHill/status/1198354786049019905?s=20

This was especially timely as I'm preparing to head out this afternoon to help a customer with a machine being controlled by another programmer. I'm not familiar with how he solves problems and I'm not familiar with this older version of machinery. But in preparing, I have to map out a plan of attack as I'd rather not have this turn into a holiday ruining trip.

This is also a good example of how I take on a new machine control project. My process is similar for both.

In the case of helping to troubleshoot a machine being controlled by unfamiliar code, it's best to have that code available. There are two parts to most machine controls. There is the part that connects to the machine through sensors, drives, and actuators and there is the part that humans can interact with (Human to Machine Interface or HMI). The HMI can be screens, keyboards, mice, operator control buttons and switches. These are ways for the operator to tell the program what they are trying to do and a way for the program to communicate back to the operator with screens or lighted buttons.

When reasoning about a new machine control problem set, I tend to go outside in. All I know for sure is that things need to be told to move and moving things need to be sensed or measured. I can see these things and wires can be traced (hopefully they are labeled). I tend to pick one area of the machine that I find interesting. Sometimes it's the simplest thing and sometimes it's the most critical operation but I pick one.

I then look to the physical outputs. That thing can't do what it does without being connected to something. Once I find out what that something is, I can move on to identify wire numbers or relays or I/O (input/output) modules that are involved. I then find these on the the wiring diagram (hopefully there is one). I'm looking for some nomenclature that identifies what this thing is and how the things it connects to are known to the system.

Is this a "shear", a "clamp", a "beam", a "pusher", or something else? If it connects to a relay, what else connects to that relay? I follow the wires until they get to something the computer can control directly. I then focus on the labels of that device. I look at any indicator lights and see how those are labeled. I look at the brand of hardware and model numbers. Anything I can search for to find more information.

If there is a computer screen, I will look at that to see what names were provided for these things. If there is an I/O monitoring screen, I will pay special attention to that and focus on the hardware that interested me.

If the machine is operational, I'll want to see it run. Even if it's not working correctly, I'd like to see how it does work if that's possible. I'll want to have a sense for sequences of operations. I want to know the order in which things happen.

With all of that noted and in mind, I can take a look at the code. I have to first make sure that I can preserve the initial state of the code. This particular project wasn't under version control. I fixed that first. I need to be able to always see how it looked before I touched it. These days I use git through posh-git, and GitKraken.

The next thing I do is explore evidence of IDE (Integrated Development Environment) version numbers. I was familiar with both of the IDE's being used in this project so that helped. I could sniff around a few files to find version numbers. Once was Visual Studio 2013. I'm not reloading that unless I have to. I don't have it on a virtual machine and I don't want to take the time. I'm reasonably confident that my Visual Studio 2019 will work just fine with it.

The other project is with B&R Automation Studio. I'm not as confident with that and because of that I have virtual machines for several major versions. I'm on 4.5 and this project was done with 4.2. I'll start with opening that in 4.2 through the virtual machine. I don't want to introduce upgrade problems while I'm exploring.

Now that:

• I know what I'm focused on (that interesting thing and the devices that it connects to the computer through)  
• I have a way to get back to square one  
• I have a plan for how to explore these things

I can begin to crack open the code and look for things that look like they might have something to do with what I'm interested in.

Again, I will start with the outside in. I start with the PLC (Programmable Logic Controller) project and look for ways to identify the I/O modules (or drives) that correspond to my notes. Once I find those, I can look for the way variables are mapped to those hardware devices. Some programmers bring the hardware addresses all the way into the program. Some map a variable to the device. I prefer separation and so I map variables. I won't know what this other programmer prefers until I get to that point.

The HMI code might be a mix between the PLC project and the Visual Studio Project. The fact that both of these are involved (a fact that I was aware of already... which helps) tells me that there must be some sort of communication between the screens and the PLC. The PLC will know about operator controls (physical buttons, switches, and lights).

I happen to know that this developer is using OPC (Open Platform Communications). This gives me a clue as to where to find the correlation between the two systems. The PLC will assign variables to the OPC system and the PC will do the same. There will be a common point of communication for each variable. In this type of system, outside in is in two contexts as there are two computers. The PLC has an outside edge that is shared by the PC. That touching point is OPC in this case.

Once I find all of these outside points where the software comes into contact with the human or the hardware, I can begin to look for code that use these variables or hardware addresses in logic or code that assigns value to them. This can generally be done with IDE search tools in order to get a sense for how prolific these points of interest are. If they are too common and return too many results, I may lose interest and focus on something more unique about this machine (if that applies). I don't want to wade through too many false positives if I can avoid it.

Having identified what the computer can "see" (sense from machinery or operator) and what the computer can "do" (cause motion or change indicators/screen information), I can then begin to read code in the context of those points of interest. I tend to start without outputs over inputs. I'm not sure why. I guess in my mind the outputs are what the machinery is an extension of. I want to know what logic leads to the something moving.

That feels like enough for now. I'll leave this at that. I might get back to this later if there is any interest in it.