How the LDAR Datalogger changed LDAR

The first LDAR dataloggers were (are you ready for this?) 3/5 cards connected by brass rings. Seriously. How far have we come, since those ancient days? The first innovation was Lotus and then Excel Spreadsheets. Followed by printouts from computer programs that displayed tag numbers, identifying characteristics and location descriptions and provided a place to record the readings. Some technicians even used pencils (hence the horrifying term “pencil whipping.”)

Then came the first, bulky, cumbersome, unreliable LDAR dataloggers that ran a primitive monitoring interface program called MARS. We had an LDAR datalogger but not a very robust LDAR datalogging process. This was so because the MARS software was really nothing more than an automated rolodex of 3×5 card type data files on which all you could record was the reading: you “flipped” to the next component, found it, monitored it, recorded the reading on your datalogger and then “flipped” to the next component record.

But LDAR monitoring isn’t that easy now and it wasn’t that easy then. So whenever anything else happened (and lots of stuff happened) your LDAR datalogger became pretty much useless. If you couldn’t find the component, you just left the monitoring reading blank. The consequence of that was that, later, somebody else would have figured out what to do next: send another technician to try again, maybe?

Of if the tag had fallen off or you thought the ½ inch size should be 2 inches, or you could tell to a certainty that the component had been removed from service, or an operator told you that the valve was temporarily out of service and would be back in service in 3 days. What did you do? There are at least xx things that a technician can experience at a component other than simply monitor it. The old LDAR datalogging methodology was completely unresponsive to any of those events. The technician had to pull out a legal pad, pocket notebook and record the event for later reference or he simply ignored it and went to the next component.

(For a list of those non-monitoring events and to evaluate how effectively your program is managing them, click the image below.)

Human nature being what it was (and still is!) all too often the most reasonable thing to do was just ignore just about everything.

When we achieved the ability to electronically interface the analyzer with the datalogger via the famous AIMS cable, we were able to capture specific time and data stamps for each monitoring event. This represented a dramatic improvement in LDAR dataloggers. This increased reliability and simplified the process by removing the task of physically recording the reading. It increased accountability, presumably, by capturing the time and data stamp when the reading occurred and associating it with the reading.

But it did nothing else to facilitate the full scope of the technician’s responsibilities. The LDAR datalogger was not designed to routinize the capturing and management of all of the non-monitoring specific data. With the advent of the LDAR Bluetooth adapters, the industry was able to integrate much more powerful handhelds running far more sophisticated software. It is this software that paves the way for vast improvements. We will detail those improvements in our next blog.