Jason K. Firth, C.E.T.

Instrumentation, Control, and Automation

You need your own competence!

Feb 142015

Febuary 14, 2015

I'm Jason Firth.

So, now that oil has dropped dramatically, oil companies are discovering something I've always said: You need your own competent people.

The oil and gas industry has found out in a very abstract way: They've realized huge cost overruns on projects since they decided to let other companies monopolize engineering competence. When they had their own people working on the projects, they didn't have the same cost overruns.

There's a number of reasons why this is the case.

Let's start off with what I like to call institutional memory. This is the effect of having people who have worked in your facilities for years making decisions about those same facilities. You can't outsource institutional memory. It's something that either belongs to you, or is lost. When you're making decisions that affect the short-term viability of a project or the long-term viability of a facility, there's a million tiny facts which you need to know, and you won't learn in a 2-day site visit. Those folks don't know about the fifteen other solutions that were tried on a problem until the sixteenth worked. They're stuck asking why something is done a certain way. Sometimes this means they'll be going back to the failed solution 1.

Then, there's the pure question of "Who do you work for?" -- An outside company will always be looking out for their own bottom line. If a conflict arises between the interests of your company and theirs, they are going to be more likely to act in their best interests.

Along those same lines, if you're dealing with your own talent, then you can make sure you've got the best talent on the most important jobs. I've seen it in the past where an outside firm will wow a client with the A-team, then once the contract is signed, send in the Z-team.

Speaking of contracts: Of course everyone agrees that scope creep is dangerous. However; there's a certain flexibility that comes with dealing with your own people that allows economies. For example, I was working on one big project with an engineering firm, and another different project was going on at the same time. The engineering firm refused to do anything that wasn't part of the plan without negotiating a scope change and fee increase. Meanwhile, I plugged two cables in, successfully connecting the projects together, and changed a couple lines on a CAD drawing.

The formality of dealing with another company can also be a danger when you rely on other firms to have your competence. While working for a company, there's been a number of times when I've been working on some skunkworks for a company alongside the main, official jobs. Skunkworks is a term that comes from Lockheed Martin's Skunk Works development group, which developed the U-2, the SR-71 Blackbird, the F-117 Nighthawk, and the F-22 Raptor. The designation is widely used in business, engineering, and technical fields to describe a group within an organization given a high degree of autonomy and unhampered by bureaucracy, tasked with working on advanced or secret projects. The concept of that autonomy and relaxation of bureaucracy is incompatible with the formality of a business to business arrangement.

All of these problems reduce economies and prevent innovation within companies, and facilities. You can't outsource your institutional memory to another company. Your employees will always be the most aligned to your interests. You are only in full control of your own employees. Contract work can be inflexible and cause large cost increases. You can't give other companies autonomy the way you can give your employees autonomy.

Thanks for reading!

What's inside a Modbus Plus connector?

Feb 092015

February 9, 2015

I'm Jason Firth.

Eventually, I knew I would be writing at length about Modbus Plus.

Modbus Plus is the protocol that Modicon created to supersede the Modbus protocol. It has some superficial similarities, but it quite different under the hood.

Modbus is a Master/Slave protocol. One device is the master, and tells which Modbus slave to talk. By contrast, Modbus Plus is a peer-to-peer protocol. Each Modbus Plus device can request data from any other device.

Modbus doesn't have any real way to manage congestion, because there should never be congestion. The master requests data, and will not request more data until the first is sent. By contrast, Modbus Plus uses a token passing mechanism, where each node in the network gets a chance to talk, then once it has finished talking it will pass the token to the next node.

Modbus generally relies on RS-232, RS-422, or RS-485 signalling to communicate. By contrast, Modbus Plus uses a proprietary signalling protocol over a single twisted pair of wires. Modbus can be implemented using a standard UART, where Modbus Plus requires a special DSP.

Physically, Modbus Plus is a bus protocol. All devices are electrically connected to every other device on the Modbus Plus network through an electrically continuous shielded twisted pair cable.

Modbus basically doesn't have network capability by itself. However, Modbus Plus has basic networking capability. Using a device called a "Bridge Plus", you can connect different Modbus Plus networks together. The address you use to connect to a device is actually the path of devices you follow to get to the other device. If you were connecting to device 1 on the local Modbus Plus network, then you'd connect to 1.0.0.0.0. If you were connecting through a bridge multiplexer at address 2, then you'd connect to 2.1.0.0.0. If you went a step further and connected to 1 through yet another bridge multiplexer across the network at address 3, then you'd use address 2.3.1.0.0.

The data transferred using Modbus and Modbus Plus is roughly equivalent. You can send and receive inputs and coils, inputs and registers. There are also other operation codes in the protocol for diagnostics, or programming PLCs, or a number of other functions.

There are 3 types of connector routinely used for Modbus Plus. The AS-MBKT-085 inline connector takes a Modbus Plus cable and stabs the wires, to establish continuity. The 990NAD23000 Tap takes that cable and stabs the wire into a "tap", which connects to a moulded cable which connects to the device. The 990NAD23020 or 990NAD23021 Supertap doesn't stab the wire, instead using screw terminals to connect the Modbus Plus cable and the moulded drop cable.

Today I want to look at the AS-MBKT-085 inline Modbus Plus connector. We're going to look inside one.

The first thing you need to realize about these connectors is, they're not cheap. This store is selling one for 35 USD, and that's about what you can expect to pay. I've seen some online stores asking for twice that.

So, what are you getting for your money? Well, first, let's look at what this thing does.

Here, you can see a Modbus Plus connector with wires already crimped into it.

Normally, the shield grounds to the middle pad, and the wires are held in place by the plastic back, which is itself held to the connector with a screw.

The stabs which hold the wires are fastened to the connector with screws, so we'll pull them out.

I expected the connector to be welded shut, but it's actually held in place with 3 pegs which push into 3 holes. Once I had a point I could leverage, I could pry the connector apart.

So here's what we have: 3 metal block with a threaded hole, connected to a regular D9 connector.

Taking apart the connector further, I found that the ground is coupled to the chassis ground using a capacitor. That's all there is to it!

And how about those light grey plugs? The difference is that there's a 120 Ohm resistor across the data pairs. That's the difference.

Thanks for reading!

Connected

Jan 292015

January 29, 2015

I'm Jason Firth.

Today, when people use the word "Connected", they're usually talking about ethernet networks. That's not what I'm talking about today.

Quite often as an instrument technician or technologist, I get asked to help participate in jobs that don't immediately appear to be related to my trade. In one case, I was asked to participate in the Reliability Centred Maintenance initiative. In another, I was asked to help set up a site's maintenance management system. A lot of people heard this, and immediately went "That's not in your job description!"

As much as that might be true (depending on how the job description is worded), I belive that everything we do is connected.

Let's look at the workflow for RCM. The very first task is to get a complete list of equipment at your site. Occasionally you already have that list, but often you do not. At one site I worked at, gathering a list of equipment was a massive undertaking, requiring cross-referencing of every single piece of information available, from the existing maintenance management system, to maintenance records, to data from the PLC and SCADA, to some good old fashioned leg work. This might not be part of the job description, but it certainly makes life easier having that information. Suddenly we know exactly what we have, where we didn't before.

The next task is to sit down with operations personnel, and get them to help define the function of every piece of equipment. You record that definition for later. Let's look at the incredible value you get here: Not only do you personally get to sit down and learn one at a time exactly what operations believes each piece of equipment does, but you're recording it so anyone can look it up. You can gather this information together later to improve operations documentation, or to add invaluable context to the PLC or DCS program, or to produce complete disaster planning.

Next, you determine the dominant failure modes; the scenario for each failure mode; criticality of each failure; what the consequences are of failure; and what maintenance will be done to address each failure. This might seem incredibly specific to preventative maintenance, but imagine the value in having this available on a minute-to-minute basis. Imagine getting a trouble call and knowing immediately how it can be prioritized in a situation where multiple breakdowns are occurring. Having that information closely at hand could mean the difference between a plant facing safety hazards, environmental impact, capital damage, or productive loss, and not.

Finally, by having an instrument guy in the room, sometimes new solutions to failures can be found. Systematically discussing everything with operations personnel and other maintenance personnel can be a great catalyst for innovative solutions to problems that have plagued a site for ages.

As for helping to improve a maintenance management system, that's something you don't realize you needed until you have it. A properly set up system will have all your different pieces of equipment, so you can build a history of things you've done to that equipment. History is a key information source in Reliability Centred Maintenance. A really well done MMS will fundamentally change how reactive maintenance gets done. When a tradesman recognise that a piece of equipment needs to be changed out, instead of immediately hunting for some indication of what the part they need is, they can immediately head to stores with the tag number and recieve the exact part they need from the asset Bill of Materials.

These are just two examples of how things that don't seem to be at all connected to what we do can nonetheless make our day to day work easier. "That's not in your job description!" is a great way to make that job harder.

Thanks for reading!

Really Disappointing

Jan 182015

January 18, 2015

I'm Jason Firth.

I want to talk a bit about a trend I've been seeing.

First, some background to understand where I'm coming from.

Downloading a piece of software on the Internet is a real gamble.

Of course, some software contains viruses meant to destroy your PC, but that's a relatively small amount. To really understand where the software that will really harm you comes from, you need to follow the money. Some people make money stealing proprietary secrets from companies, or credit card numbers, or passwords for paid accounts on services like netflix. Other people make money selling advertising displayed through unscrupulous means. Still other people make their money controlling "botnets", which are large numbers of computers (computers owned by normal people) infected with worms that take control which allow buyers to send specially crafted packets to servers intended to tie up resources like bandwidth and memory in order to prevent that server from operating, in an attack called a "Distributed Denial of Service", or DDoS.

There are a few ways you can be infected (called 'vectors'). In 1999, my first website was hosted on a free web host, and I visited my own website to learn it was trying to install a spyware program on my PC (I soon after started paying for ad-free hosting). In 2000, the ILOVEYOU worm moved through e-mail, and the e-mail program outlook at the time would automatically run the infection script when the e-mail was viewed. 2004, the sasser worm could infect a PC that was simply connected to the Internet, without the owner of the computer doing anything wrong. Along the way, programs that were (or appeared to be) useful eventually started being bundled with a new kind of worm, that served advertising content even when the program wasn't running. Some applications installed this software without any indication that it was doing anything. Others would try to hide their request to install behind deceptive wording or deceptive button placement. Either way, once installed, the new program would display advertising on your PC even when you weren't using the application that installed the ad program -- in fact, sometimes even after the original program was uninstalled.

My first job was as a registered apprentice helpdesk support analyst for a school board. One of the challenges they faced at the time was removing the programs installed by peer to peer file sharing programs (it was a more innocent time before such computers were completely locked down). These programs would cause web advertisements to appear, and used resources that the old Pentium 133MHz machines with 32MB of RAM couldn't really afford to give up.

If you want to be assured that software from the Internet is safe, you have only a few options. You can download only from trusted proprietary sources like Microsoft. You can just not download anything at all. A third option for a long time was Free and Open Source software. This software is written by hobbyists or by companies who want to build an open platform, and is licensed so that everyone who wants to use it can use it, and anyone can access the source code and use it, but only if they release any modifications for use by others. (There are other free licenses which are broader, but we'll discuss this one for now). These programs didn't usually come with problem software, because anyone could check the code, and compile a clean version from scratch.

Unfortunately, something has changed. The largest distributor of open source software, called Sourceforge, changed owners a few years back, and now they encourage top projects to try to install this problem software on their users computers.

I've contributed to open source projects over the years. I've written documentation, I've written code, I've even started projects. I believe in the idea. To see big projects that people like me have put their heart and soul into and to have it used to try to unscrupulously infect other people's computers, I consider that criminal, and I consider it a tragedy.

I consider it criminal because any consent could only be possibly be gained through deception, because no reasonable person would allow such software to be installed on their computer. "Hey, want me to put advertising on every webpage you visit, even the ones without advertising? Want me to randomly pop up advertising all the time? Want all this to happen even when you're not using my program?" -- of course the answer is 'No'. I've seen them get an "I agree" click by using deceptive language ("Click if you don't want to unagree that we won't not install the software"), or by using deceptive button placement ("next next next next next I agree to be infected with a virus"). I don't consider this access to one's computer legitimately authorized, and thus taking over people's computer is a cyber-crime. Governments around the world appear to agree with me, because laws are being passed all the time to make it perfectly clear for the courts that this sort of behaviour isn't acceptable.

As for why I consider it a tragedy, imagine the passion of people contributing to their favourite open source projects, working for no compensation. Their reward? To have the project maintainer try to take over their computer for monetary gain. That's tragic. It really is the tragedy of the commons here, where someone realized they could burn it all to the ground to make a buck. That's very sad.

Anyway, back to instrumentation next time. I just had to vent about the end of an era: The era where you could at least trust an open source project.

Thanks for reading!

ProComSol DevCom2000 first impressions

Jan 142015

January 14, 2015

I'm Jason Firth.

Modern electronic instruments are almost never purely analog devices anymore.

The reason is really simple: When you're dealing with analog signals, you're constantly worrying about introducing error. Every trace on a circuit board, every op-amp, every transistor has the chance to introduce non-linearity, noise, or to mess up your scaling. By contrast, once you digitize your signal, that's it -- your signal is what your signal is, and from there you can process it or analyze it however you like without degrading the signal, until you spit out your signal, either through a fieldbus or through an analog signalling standard like 4-20mA.

If you have an instrument with a processor that communicates using a 4-20mA analog signal, then you're sort of out of luck with respect to advanced configuration and diagnostics over that line, right?

Not exactly. Since a 4-20mA signal is very slow, and most analog input devices have filtering built-in to read only that fairly slow signal, you can overlay a very fast signal on top of the 4-20mA. A communications protocol called HART overlays a 300 baud analog modem signal (Remember modems?) on top of the 4-20mA, allowing the instrument and a user interface to communicate digital data.

There are 2 main standards for device drivers for communicating with HART devices: DTMs(Device Type Managers), and DDs(Device Descriptions). DTMs function primarily with a piece of software called "PactWARE", whereas DDs are used on Rosemount HART communicators such as the 475.

HART communicators are nice because they are single purpose devices: They do one thing, and presumably they do it well. However; there are benefits to using a PC for communicating with instruments. PCs have virtually unlimited storage space, memory, and CPU power compared to a HART communicator. They have full network capabilities. They also have a much larger screen and keyboard.

I'm a fan of instrument techs having their own fully powered laptop. Windows allows file shares to be automatically synchronized and made available off-line, so a technician can make a change in the field and save it to their file share, then that change will be available for any other technician who works on that instrument, and it's available for archival use by engineering groups, and it can be backed up to redundant drives to ensure its future availability.

Now, two well-known options are called PactWARE and Emerson AMS. There are some problems with each.

Both share the problem that they really want to take over your plant. They're not designed for a technician's PC, they're designed to be run on a server handling your entire plant using a HART enabled analog input card or a HART multiplexer, so they're a bit unweildly. AMS is far too expensive to be practical as a simple tool for a laptop. PactWARE is free, but it takes a dozen clicks to connect to an instrument.

Another problem is drivers. The most common standard interface for HART devices is has standardized on the “dd” standard, which is platform agnostic, but PactWARE uses the DTM standard, which is a Windows program designed to fit into the software.

One possible solution is ProComSol DevCom2000. ProComSol puts this hardware out for $800, so it's still fairly expensive, but it's far less expensive than an Emerson 475 field communicator.

I recently acquired a copy, and figured I'd show give first impressions, out of the box. I'm going to go into a bit of ostensibly trivial detail, just to give a full idea of what you can expect.

The software is available as a digital download.

Opening the installer package starts initialization.

Then you see a standard "Let's get started"

Next, accept the license agreement.

Select your installation folder

Confirm your settings

The installation will start working.

After it is done, it will prompt you to finish.

DevCom2000 will ask you what you'd like to do on the first install. We're going to activate it.

Activation can be done over the phone with a representative, or online. We're going to activate online.

Enter your code and password.

It will take a moment to connect to the server.

After connecting, activation will be complete.

When you start DevCom2000, the program immediately tries to connect to a HART device.

You can purchase a USB, RS-232, or Bluetooth dongle from ProComSol to connect to a HART device, or you can use a standard dongle like the Mactek Viator.

In addition, you can connect to a wireless HART gateway like that Emerson Smart Wireless Gateway.

The configuration is set to COM99, so it won't connect the first time.

So we open the basic options to configure our communication device.

Here's the second tab of the settings, regarding search.

This is the final tab of settings, advanced settings.

If you configured an IP HART gateway, upon connection you'll be asked to select which of the instruments you'd like to use.

Once you're connected, there's a navigation tree on the left, and the relevant values and methods are shown on the right.

dd drivers include variables and methods. Variables are single points of data that can be read, and some can be written. Methods are simple programs which allow the automation of certain tasks. This is an example of a method running.

This is an example of some read-only variables.

Besides what I've shown, DevCom2000 has the ability to export the full configuration of a device as a pdf file. This pdf file can be printed to provide a hard copy of device configurations.

Remarkably, it also seems to have the ability to read back that file, and write the values into an instrument.

This was just a quick look, but it covers a lot of the main elements of the program. If I see any requests for more, I may write more on this topic later.

Thanks for reading!

Troubleshooting tools for Wonderware DAServers

Jan 102015

January 10, 2015

I'm Jason Firth.

When troubleshooting Wonderware software, most people know about the system management console's log, but today I'm going to talk about some of the lesser known diagnostic tools available for troubleshooting DAServers while you're using Wonderware. There's a huge amount of literature included with Wonderware, but it can be a bit overwhelming. These are some tricks I picked up that may not be immediately obvious.

To start off, you're going to have to open the system management console.

Under the diagnostics, there's a tree filled with diagnostic tools.

Let's look at what each one does.

The Client Groups tree displays all the communications methods in service, in each one, it lists all the communications that are in service.

The structures tree shows all the different topic names that are communicating at the moment. You can click each device on the list for a more detailed view of what is or is not communicating correctly.

The transactions tab ostensibly shows transactions, but on all my servers it is empty, so I can't say what it does.

The statistics tree shows statistics for the currently selected DAServer.

The device groups tree lists the tags active in each device group, extremely similar to the structure tree.

The messages tree displays information about messages currently being processed. It updates fairly quickly.

Moving on from these diagnostic tools, there are ways to show additional debugging information in your system log.

Head to your local log viewer in the system management console, and right click "local". Click "Log Flags".

You're going to see a list of services on the left, and a list of options on the right. Every global log flag you check will cause that set of debugging and status messages to be shown in the log file. Note that there's a reason these aren't all selected by default: If you select all log flags, then your log will be inundated by a deluge of minutae.

Here's some options relating to DASMBTCP, a common DAServer used for communication over Ethernet using Modbus TCP.

This quick rundown isn't fancy, but hopefully this helps other people who are trying to figure out what the DAServers are thinking when communication isn't working.

Thanks for reading!

Don't give them what they ask for

Jan 082015

January 8, 2015

I'm Jason Firth.

This June will mark the 9th year that I've been working in heavy industry.

I started my career and spent four years in design and maintenance planning and another 5 years as a technician. Of all the pieces of advice I wish that I'd been given this one is probably the most important: don't give the people what they ask for; give them what they need.

Something to remember is that as an instrument technician or an engineering technologist or an engineer you have depth of knowledge regarding instrumentation, control, and automation that regular operations and maintenance personnel don't have. Sometimes they're asking for one very specific piece of equipment, but if you give them that piece of equipment you're going to get in trouble because it's not going to work.

One very specific example came from my time in the pulp & paper industry. Creating pulp and paper takes an incredible amount of power. One of the ways that paper mills get this power without excessive costs is by burning the bark has been removed from trees before their used in the paper process. This removed bark is called hog. This hog is then send to a hog bin which is attached to a power boiler which burns the hog to produce steam, which is in used throughout the process. I was asked to put one of two extremely specific level switches on one of these hog bins. Instead I started looking at the history of the unit, and discovered that that level transmitter has already been tried and has been removed because it didn't work. I looked at all the different environmental concerns within the bin, and decided on a completely different level measurement than what they asked for. However, this level measurement worked. By giving them what they wanted instead of what they were asking for, my internal customers were far happier with the result.

As a technician, I end up with many extremely similar circumstances. The difference is that whereas they wanted me to design a level measurement before here they would ask me to do the same maintenance task over and over and over again. The company was wasting money on me, the Operations Group wasn't getting the control that they needed, there was no reason to keep on giving them what they were asking for. Instead, I focused on what the real problem was. In many of these cases, I was able to find a problem that no one ever knew existed. By giving them what they needed instead of what they asked for everybody won.

Let me be clear: I'm not suggesting insubordination. There is a chain of command in workplaces, and it isn't a good career move to violate it. However; in most cases, you have some latitude to make decisions that you think will work best. If you don't have that latitude, you are still a voice within your team, and you may be able to change minds if you provide a good reason for people to listen.

If you get this right, and manage to give people what they need and want instead of exactly what they ask for, you're going to look like a miracle worker.

Thanks for reading!

sqlcmd- A means to doing SQL commands from the command line

Jan 032015

January 3, 2015

I'm Jason Firth.

 

Last time, I posted about openness. One of the ways openness can help everyone is by providing flexibility to do things that may not have otherwise been possible.

At this point, many software packages use Microsoft SQL server as a front-end. Pi Historian and Wonderware Historian, for example, both use SQL Server as a front-end.

This provides some really neat opportunities. You can automate the retrieval or analysis of data from the historian, for example. Visual Studio Express is available for free, and includes all the APIs for communicating with an SQL server.

Let's say you don't want to do anything that complicated. What if you just want to run a simple query and spit out a simple table?

If you're running a computer with SQL Server or the free to download and use SQL Server express, you can use the sqlcmd command from the command line.

You can use the command line "sqlcmd -S [protocol:]server[\instance_name][,port] -U [userid] -p [password]" to connect to a command line instance, but the really interesting part is that you can use "-i input_file[,input_file2...]" or "-o output_file" to automate the running of certain queries.

The input file is a script written in TRANSACT-SQL, (that "Select * where" stuff).

Knowing this, you can pull data and manipulate data from the command line, or from batch files. That isn't something you may want to use for everything on a regular basis, but it's a great little tool to have in your back pocket for those times when you have to get a little script going quickly.

 

Thanks for reading!

On Openness

Dec 292014

December 29, 2014

I'm Jason Firth.

 

Merry Christmas, and happy new year!

On my "About me" page, I wrote: "With this blog, I have a few goals: I'm hoping to get some of that information together so control professionals from all over can use it. I'm hoping to take some of the extremely cryptic academic work out there and simplify it for industry."

Recently, I was speaking with someone from the aaOpenSource project, which was started in part by the guy at the Archestranaut blog over at Avid Solutions. I definitely recommend the blog. It isn't always updated, but when it is, there's some great information there.

One thing we both agreed on was that this industry needs more openness and sharing.

I started my "programming career" such as it is in open source. I started off by learning GWBasic, then progressed to QBASIC, then learned Visual Basic and C++ and a bunch of other programming languages afterwards. It might be a bit sacreligious for the hardcore programmers out there, but I always enjoyed BASIC, because compared to many other programming environments, you don't need to micromanage as much. The runtime library contains most things you'd need for simple programs, so you don't need to manage library binaries or header files. Eventually, I ended up using the FreeBASIC project. It's very much like a C++ compiler with a very comprehensive runtime library built in. I ended up contributing a small amount of code, and working as much as I could to improve the documentation for new users.

No matter what programming lanugage I was learning, whether it was gwbasic or C++ or assembly or php, open code was a crucial piece of my learning experience. It was much easier saying "What does correct code look like?", than trying to decipher sometimes archaic documentation. Having a library of code snippets to call upon means you can focus on solving the novel parts of your solution, rather than reinventing the wheel.

Two pieces of code in particular were things I was particularly proud of improving upon when I was back in high school were a graphics routine, and a keyboard handler.

In DOS programming, and particularly real-mode DOS programing, you end up having to manually handle your graphics to a large degree. I found some code demonstrating a simple pixel set routine for 320x240, a video mode called "ModeX". It has some really cool features, such as allowing you to draw to an off-screen part of the video memory while showing a different part of the video memory. This is called "Double buffering" when there is an onscreen page and an offscreen page, but ModeX supports two offscreen pages and one onscreen page, called "Triple Buffering". The most difficult part of programming this to run quickly is that there's all sorts of insanity in how you write pixels properly. You have four "planes" which you have to write to, and each plane has the graphic laid out in an odd way. The original code showed me how to initialize the video mode, but the code for placing a dot on the screen involved calculating the memory location (involving a multiply and a divide), and setting the plane. After months of staring at the code, I came up with a clever way of writing an entire plane's pixels in one step consisting only of additions, then I could write an entire screen with only 4 plane shifts. Without the original code showing how ModeX worked, I would have had nothing to start from, and I probably wouldn't have gone with the arcane video mode without some sample code to start from. Without open documentation, the person who wrote that code probably never would have had a place to start.

Another challenge is key detection. For multikey applications, you have to capture each button press and unpress to determine the keyboard state. To accomplish this, you must create an interrupt handler to replace the existing DOS keyhandler, which only captures one key at a time. Then, you must continuously poll the port. I found some novel tweaks to the code to allow more accurate polling of the port and recording (and retrieval of) multikey values. Without the original code showing how raw keyboard polling worked, I would have had nothing to start from, and I probably wouldn't have gone with any sort of continuous multikey detection without some sample code to start from. Without open documentation, the person who wrote that code probably never would have had a place to start.

These are small programming problems, but they're how I started to learn. Without the documentation and open code, I never would have had a place to start, and never would have learned the fundamentals I use to solve problems on a regular basis today, a decade later.

However, our industry is built upon certain open standards. The PID, for example, or Zeigler Nichols tuning, or 4-20mA, or 3-15 PSI. Everyone who learns about the trade needs to learn these things, and by learning them, doesn't need to reinvent the wheel later.

One thing that should be immediately obvious is that all those standards are from 40 years ago. In some ways, it's like our trade hit a time warp, and although we're seeing more and more new technology, it's all a black box. Some specialized experts understand them, but they're in the minority.

I come from a few industries where people believe that if you hoard information, and ration it out in little bits, that's how you stay valuable. I don't believe that. I believe that the way we stay relevant is by proving to the world all the interesting ways we can provide value to their organizations. We're tube benders, but we're not just tube benders. We're cable pullers, but we're not just cable pullers. We're calibrators, but we're not just calibrators. We're documenters, but we're not just documenters. We're programmers, but we're not just programmers. We're electronics techs, but we're not just electronics techs. I could go on all day, because our trade and profession is so broad, we end up with a view that is equally broad. Instead of being jealous and trying to protect this information, we should be teachers, trying to help each other, and also the other disciplines become better. If we try to go alone, to fend for ourselves, then we're going to be swept away by the tide of all the new stuff we need to keep on top of.

That's one big reason why I wanted to start writing this blog, because I was able to build upon the work of others, and I'd like to continue to do that. Together, we can build the future.

 

Thanks for reading!