PID on a diet? How to tune your PID

There are two facts about PID that truly amazed me. The first one is the amount of people that use it and the second one is how many rules and utilities are out there to tune them.

In my mind, implemeting a PID is a little bit like going on a diet. Everyone wants to loose weight (or improve performance) and there are lots of different diets (tools, rules of thumb, programs) but there is no "magic diet" that miraculously lets you loose weight without some effort.

I don't have a solution for it; if anyone does feel free to add it in the comments!. What I do have is an Adaptive PID Example. It is not perfect, by any means, but shows the interesting concept of using online system identification to identify the plant and change the PID gains based on it.

My colleague Brian McCleery wrote a whitepaper about it and Dr. Jeannie Falcon demonstrated it

Enjoy!

The importance of being in Sync - Centralized vs Distributed

As if often happens, this post comes from a discussion I had with a customer.

One common trend that I see with test systems, is the need for them to be distributed. Having a distributed system has several benefits

- You can get your instrumentation closer to the signals, thus reducing noise. I had a customer that had to read lots of signals from sensors all around a facility and having very long cables didn't work very well with small signals, particulary when the cables had to run paralell for a long trek

- Since there will be some sort of data bus, less cabling is needed. In the case above, some of our systems act as concentrators, drastically reducing the needed lengh of cable

- You can have your instrumentation with the unit under test while having the control of your instrumentation on a safe location.

I think a graph will help explain it

So why don't we have more of this distributed architectures? Well, as you might guess from the post title, we might want to have the data that is collected synchronize. But what does it mean to be "synchronized", it basically means that signals use clocks that are correlated. The tighter the synchronization the closer the clocks need to be in synch.

Is this always neccesary? As usual, it depends on the application and the signals being developed. If you are building a control system based on temperature readings on different parts of the building (to activate the boiler, for example) signals do not need to be closely synchronized, as it is typically a slow control systems and temperature doesn't change rapidly.

On the oposite side of the spectrum, you might be building a iron-bird. In this case you need the information to share a timebase, among other things.

How is this accomplish? You'll have to read my next blog post :D

You want to see a system tightly sincronized? Behold the "Gears of Death" Demo!

Have fun!

MIL, SIL, PIL, HIL..... How is the "in the loop" term used.

Hello all!

It's been a while. I read a while ago that one shouldn't apologise for not writing and just keep writting as if nothing happen, so I'll take that advice.

Often in my customer interactions I hear and use the term "HIL". As you might know, HIL stands for "Hardware In the Loop" and is a testing methodology to verify and/or validate and embedded system design. I heard it was developed around 30 years ago by the automotive industry (feel free to correct me!) and had evolved much since. You can learn more from the wikipedia entry.

Interesting enough, there are a number of different "In the Loop" variations, depending on methodology used, equipment and even culture inside a company. By no means the terms I will refer below are anything like industry standards, but that's the way I have them in my head and make quite sense.

To simplify the explanation, let's assume we are developing an embedded control algorithm that will act over a physical system. The plant execution is needed to provide the information needed to close the control loop on the embedded device.  For example, let's assume the control system for an automatic transmission.

MIL ("Model in the Loop"):  In this instance, both the control algorithm and the plant model (transmission and car) are implemented as simulation models. Here is one example that ships with LabVIEW

SIL ("Software in the Loop"): Here we have created the optimized code for the embedded target but still run it against the plant model on a computer environment.

PIL ("Processor in the Loop"): The embedded code is running on an embedded target. The plant model. Here is great video below about simulation, control theory and a PIL system

HIL(or HWIL "Hardware in the Loop"): Embedded target is finished (or nearly so) and plant model is executed on an external device.

Test Cells: This is an extension of the methodology where both the embedded system and the plant are physically present and external elements are simulated. In the case of our automatic transmission, both transmission and TCU (Transmission ECU) exist and the engine input torque and road/car  load are simulated by electrical motors. Here is an example for a transmission from a customer.

There are many more terms I've heard like "Person in the Loop", "Sensor in the Loop", etc, but thought it would be good just somewhere to start on.

At the end of they day, when I have to explain my kids what I do, I tell them I help people build "simulators"