Author: jkfirth

Categories
Instrumentation

ProComSol DevCom2000 first impressions

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!

Categories
Process Control

Don’t give them what they ask for

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!

Categories
Process Control

Troubleshooting tools for Wonderware DAServers

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!

Categories
Industrial IT

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

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!

Categories
Industrial IT

On Openness

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 320×240, 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!

Categories
Instrumentation

Siemens WS300 teardown

Siemens WS300 teardown

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!

Categories
Process Control

Wonderware System Platform 2014 R2 now available

I’m Jason Firth.

Yesterday, without much fanfare (at least for their customers), Schneider released Wonderware System Platform 2014 R2.

Some quick notes from reading the documentation:

  • Windows XP, all versions; Windows Vista, all versions; Windows Server 2003, all versions; Windows Server 2008, non-R2 versions are no longer supported.
  • Modern InTouch Applications now allow you to better integrate ArchestrA objects into Intouch.
  • Wonderware Intouch now incorporates the ArchestrA Graphic Toolbox directly.
  • Additional Situational Awareness Library Symbols – There are now a number of new symbols for alarms, valves, and trends.
  • Graphic Connectors – It seems a new tool is available that can connect different objects together.
  • Alarm Shelving – This seems like a particularly useful function that will let operators “shelve” a nuisance alarm for a certain period of time.
  • Enhancements to Programmatic Export and Import of ArchestrA Symbols – It looks like they’ve added new ways to create archestra symbols using xml.
  • Conversion of InTouch Windows to ArchestrA Symbols – This is a huge win for anyone who was going to be forced to convert their windows by hand previously. Anyone doing an Intouch to ArchestrA conversion knows what I’m talking about.

When I first saw System Platform for the first time, my instinct was that Wonderware Intouch was going to slowly fade by the wayside, and it seems this is happening. More and more, the much more powerful ArchestrA framework is being integrated more into Intouch.

I’ll use it more in the coming weeks, and write more about my experiences with the new system.

There have been a lot of steps in the right direction for Wonderware in the past few years: It seems like they’ve spent a lot of time resolving a lot of the show stopper bugs in the core program. I’m hoping to see that continue.

Wonderware customers with a support contract can find the new software on their website at The Wonderware Development Network.

Thanks for reading!

Categories
Trades

Women in trades and technology

I’m Jason Firth.

I’d like to suggest today, that women should look more at the trades and technology as a career choice.

Of course, there’s lots of people right now suggesting that. There’s people who are way smarter, and way richer, and way more powerful suggesting that. Obviously, another voice isn’t really that useful right now.

So I’d like to give the one thing I have that many of those people don’t: A view from the floor. I’m going to tell you why it makes a lot of sense to get into the trades and technology, I’m going to tell you about some of the challenges you can expect to face, and I’m going to tell you why the trades and technology is about a lot more than wires and ports.

Let’s start off by by looking at why the trades and technology are a great choice for anyone. Many jobs in the trades and technology are highly skilled, highly paid jobs that tend to have great benefit plans as well. Even tradesmen who lose their jobs, often find new ones way faster than others. Besides that, you get respect: If there’s one thing that people respect, it’s “I can’t do this thing, but this person can, and I need them.”

Besides that, the trades can be really fulfilling. Imagine, at the end of the day, looking at a building you’ve helped build, or light, or control. Imagine working in maintenance and being the person who solves the problem nobody else could, or getting a plant running that was down, costing tens of thousands of dollars an hour.

As for why women in particular should be interested, let’s start at the beginning of your career: When any woman I know says “I’m thinking of going back to school”, I immediately suggest taking an engineering technology course. As a starving student looking at scholarships and bursaries, it was immediately obvious that there’s thousands of dollars up for grabs in scholarships and bursaries for women in technology. There are plenty of other options for women, and many sort of “Traditionally female” choices out there, but why pay full price to follow what others do if you can get a helping hand to try something different? Besides that, taking an unconventional path has other benefits: Companies want to hire women for trades and technology positions. The problem is that the applicants aren’t there! The rewards are there for someone who wants to take the risk of doing something different.

Now, it isn’t always going to be easy.

Imagine being the first human on an alien planet, and the aliens don’t know how to be around a human. They might behave quite inappropriately at times. Unfortunately, because technology and the trades are so male-dominated, you get people who don’t know how to act with women in the workplace. I have to admit, you’ll sometimes be treated unfairly based on your gender. It isn’t acceptable, but it is real. It takes courage to lead, and the only way things will get better is for more women to engage.

Another thing that is true, is that some trades take more physical strength than others, and that can put women at a disadvantage. If you’re a millwright, you might be asked to really strain against a wrench. If you’re an electrician, you might be asked to pull really large cables. In these cases, you’re going to have to rely on your team to help, or find a different way to do the job. Not every job is like that. Instrument technicians don’t tend to need much brute strength for most of their jobs, and you don’t need arms like tree trunks to use a mouse and keyboard to draw in CAD.

But one criticism that I don’t believe is true is the image of trades and technology as a cold, inhuman field, all ports and wires and bolts, disconnected from people.

I’ve always been told that it isn’t just important that you can do these huge things, but that you can help others understand it too. Besides being a person who can do things, you need to be someone who can teach others, to help better understand what you can do for them.

Consider the largest company in the world right now by market cap: Apple. Steve Jobs wasn’t the first person to make a home computer, but his company made the home computer accessible for human beings. They weren’t the first to create a smart phone, but they were the first to make it accessible for human beings. They weren’t the first to make an MP3 player or on-line music store, but they were the first to make it accessible for human beings. It’s important to be good at your trade or the technology, but it’s equally important to be able to connect the technology with the people who aren’t you.

I personally spend a lot of time repairing and calibrating instruments, tuning loops, running cables, designing systems, and programming. However, I spend more and more time working with people who aren’t instrumentation and control specialists trying to help them understand what my team can do for them, or helping people learn exactly what tools we provide and how they can use those tools to help themselves, or describing to non-technical folks work we’ve done. The genius who doesn’t deal with people probably isn’t going to succeed compared to a person with less technical skill who is nonetheless willing to work with other people and other groups, and really help those groups make the best use of instrumentation, controls, and automation for the benefit of the organization.

There’s no reason why women should count themselves out of that.

Thanks for reading!

Categories
Instrumentation

Omega Engineering got smart

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!

XBee Data Sheet

XBee video presentation

Categories
Process Control

Unity Pro 8.1 Released

I’m Jason Firth.

Because of an ongoing support issue we’ve been having, the folks at Schneider made sure to e-mail me about a point release of Schneider’s Unity Pro software that was recently released.

Additions include:

-support for new M580 devices

-Device Integration improvements

-references

-implicit conversions (no more real_to_int and int_to_real everywhere)

-security improvements

Interestingly, Unity Pro 8.1 supports Windows 8.1 but not Windows 8.0. Windows XP is no longer supported either.

It’s not mentioned anywhere, but there have been other bug fixes as well. I had a problem with animation tables when I built changes to the program, and installing Unity Pro 8.1 solved those problems.

We also had a problem where the program would slow to a crawl if the variable properties window (accessed by pressing ctrl-enter while a variable is selected) is open. This version solves that problem.

Thanks for reading!