Jason K. Firth, C.E.T.

Instrumentation, Control, and Automation

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!

Siemens WS300 teardown

Dec 232014

December 23, 2014

I'm Jason Firth.

I had an opportunity recently to tear apart a Siemens WS300.

I was hoping to troubleshoot a problem with it, and in the process I learned a bit about how they were put together.

Here you can see the mechanical components. The thick metal shaft is the part that sticks out of the sensor. It has a single bearing (the big round circular thing with the blue plastic) held in place by a retaining clip. Next, there was the circular piece of metal, and another bearing, which is then held in place with another retaining clip. The shaft with the bearings slides into the housing, and is held in place by the large retaining clip. The very end, where the shaft becomes small, has a little metal pin in it, which acts like a handle.

The orange part of the coupling has a slot cut in it, which slides over the shaft, holding onto it. Then, the orange part connects to the black coupling, which is held onto the binary encoder. The encoder is held to the circuit board with the metal clip, which screws onto the board, and holds the encoder with the large nut and locking washer.

The rotary encoder might look like a resistive potentiometer, but it is something a bit more complicated. Instead of changing from 0 to 100% resistance over the course of its range, it consists of a pair of lines which change differently in response to rotating in different directions.

Here's the circuit board. Let's look at some of the components:

There's a LM317. This is an adjustable voltage regulator.

The AC74 looks like a dual flip flop chip (the model number isn't exactly the same, so it's possible it isn't the right chip). This makes sense, because the output of this transmitter is a pair of signals: one changes when you turn the sensor in one direction, the other changes when you turn the sensor in the other direction. This chip is probably where our final logic comes from.

There are two transistors, Q1 and Q2. These probably take the logic signals from the AC74 and convert it into a full voltage signal.

The HC132A chip seems to be a quad NAND gate. You can create a lot of different logic using a few NAND chips, so this makes sense.

Knowing what these parts are, we now have a general idea how this works: The input voltage is regulated down, then some NAND gates and flip flops are combined to provide a pair of pulse outputs.

We determined that the rotary encoder was destroyed, since we now understood how to feed +5v signals to force the board to operate we were able to confirm that the electronics functioned and the sensor did not.

I hope you found this look at a common instrument as interesting as I did.

Thanks for reading!

Omega Engineering got smart

Dec 182014


December 18, 2014

I'm Jason Firth.

We set up some Omega wireless temperature transmitters the other day, and I thought the method they used to get wireless connectivity is quite clever.

Take a look for yourself:

That's an XBee Pro wireless transceiver.

XBee is a wireless communication standard for instrumentation that's been made popular thanks to its association with Arduino microcontrollers. This popularity means that the chips are easy to acquire, and that debugging tools are simple to find and quite inexpensive.

Using an established protocol probably made their development costs way lower, and it also makes this whole system a lot more repairable. Really smart move, from where I'm standing.

Thanks for reading!

Discuss this post on Reddit

XBee Data Sheet

XBee video presentation