I wrote this article a little over a year ago, before I was into the .NET MF community. I’ve actually used this (despite people’s comments) in a highly complex PC based control system, as well as an AutoPilot for boats.
http://www.codeproject.com/KB/recipes/IndustrialDotNetPID.aspx
Figured it may be of some use to somebody here.
I’ll make a Fezzer project as soon as it’s integrated with TinyCLR.
Thanks Ron. Good stuff. Look forward to using that. Those comments are crack smoking .Net haters. .Net PID works just fine on robots, cars, helis, and boats as you said.
I have a PID class in FEZZer…
That said, even though I don’t like NETMF naysayers, they are absolutely right that NETMF should NEVER be used to directly fly any sort of UAV such a as a fixed wing aircraft or a helicopter. Anyone who says that NETMF will not be able to run such a system is indeed not smoking crack, but merely following proper time critical design practices.
I would consider any design that uses NETMF to directly control a PV that requires a high level of stabilization to be highly unprofessional unless special considerations were factored in [like a native interop].
There are plenty of people who have tried to make .NETMF quadcopters. How many have flown with any sort of stability? None.
The proper way to implement such a design is with a time critical coprocessor; either an FPGA or something running native code.
That said, NETMF will happily run something like an RC car or a boat where there is enough slag to not make much of a difference anyway, no aircraft though.
Chris-
I do understand what you are saying, and I would (almost) agree that in high update rate systems you need something a little more real-time, but take it from me, you can’t blanketly say it’s not good for large scale systems.
Case in point, I wrote a 500,000 line control system in C#, pure c#, that controls, in real time, ships (not RC boats). Look up Dynamic Positioning on Wikipedia, we are in the final stages of getting our product approved.
The AutoPilot for boats that I was speaking of wasn’t an AutoPilot for RC boats, it’s an AutoPilot for offshore vessels. I’ve also written joystick systems for smaller vessels (we are going through the prototype stages on one product now) in C# and .NET MF, that uses PID loops and these systems are proven in the wild. I’ve got a degree in Software Engineering, and I’ve been writing control systems for over 10 years, so please don’t say it’s unprofessional because it’s a little insulting.
You would be surprised how many critical PID and Kalman loop systems that are out there that are written in interpreted languages on Windows Systems… Beckhoff PLC’s (which are industry renowned) run Windows XP, and do real time motion control. The time of PC’s and interpreted languages such as Java and .NET being slow and unfit for real time control systems is quickly coming to an end. Linux RT was recently approved for real time flight control systems and can be PC based.
Not trying to criticize what you said or put you down, just giving you examples of how professional systems can run PV controls.
ships and small boats are one thing running on full .NET – that’s a slow control loop. A ship is unlikely to enter a 1,500FPM climb with a bit of back pressure on the stick. 
Temperature also works quite well. PV doesn’t respond quickly so there’s no issue with the loop being held up for some milliseconds.
An aircraft is a different scenario, and this is what I specifically talked about in my post. You can easily get a PV that suddenly changes value dramatically within a very short time period.
Something else I noticed was that you were taking my post in comparison to .NET on an x86/x64 target. I said NETMF specifically, I have done a lot of testing on NETMF (on a USBizi) in regards to control theory. I found that it can handle single PV loops fairly well, but as you start to lump stuff in, performance degrades enough to the point where I wouldn’t trust it anywhere near an airplane. That was on a 10hz loop, and an aircraft may need to have a loop that runs in the range of around 500hz, possibly more depending on the natural stability of the aircraft. Not only that, but a typical fixed wing aircraft is at least a 4 PV (airspeed, roll, pitch, yaw) scenario.
I never said that control theory within .NET can’t play nice in a boat, so the unprofessional statement doesn’t apply to you 
Time. Look at the T in the system. This will show what process control algorithm needs to be implemented. There are “times” when a classic PID just will not do it. Also look at how the set point variable changes and the “time” scale of the change. If the set point changes smoothly, almost linear then a PID maybe fine. If the set point changes chaotically with a demanded relatively short response time then most likely a PID will not work. Then a predictive or feed forward control algorithm will need to be looked at. There are many things that would be fine with PID on the micro frame work and there are some that do not fit.
As always your requirements will dictate a solution. Not sure anyone said you can or should use it on a 120mph aircraft. The comment was related to wholesale comments saying it won’t work or c# is crappy, etc.
Always remember the universal truth. [italic]Before C#, there was only darkness…[/italic] 
In the days where everyone used assembly, you were called an idiot for using C compilers! Using C is not bad anymore Now, they do not want you to use C++ because of the overhead…then mention C# and someone wants to shoot you!
I think they are forgetting that a $2 micro is now faster than my first PC
So yes C/C++/C# are horrible if you are still using 8051 (many companies sill do!!!)
Like I always say, 8-bit should be illegal to use, unless you are making a hand watch!
Very interesting topic. I could go on for hours talking on it… but I have to go to a meeting in ten minutes or so
When I started my research, the first thing my professor told me was never to make blanket statements. He went on to say that never make assertions implying that you are making an absolute statement. Always blame the results … The results indicate that… and so on.
Well, the article, and responses to it, are not totally crap. Unless you try to understand the system dynamics, you can never say whether a particular controller is going to work for it or not. The problem is that people are too quick to jump to the conclusion that .NET micro is only fast enough for thermal processes, and won’t work for physical systems. Look at the self balancing robot that I’m working on. I’ve had hours long discussions on whether .NET MF will be able to handle it or not. So I just went ahead and did it. I’ve also done some detailed analysis of real-time response of different microcontroller platforms, which I may put here some time.
At the same time, you can’t expect .NET MF to get DO-178B certification. So I understand where Chris is coming from. Also, you can’t blame C# for making systems slow. C# is just a tool. The speed at which a complex C# application will execute on a 10-core machine will certainly beat 8-bit microcontroller running a real-time OS.
As for timing, consider this. If the frequency of the system is in msecs, then a small variation in timing (jitter) in microsecs can be treated as noise (if you think about it, it will come to you). Normally, noise level in sensors is higher than this noise introduced due to timing. In most of the processes, even physical systems (where you don’t require DO-178B compliance), it will work. Reliability for critical processes is another thing. If the process is critical (I’ve worked with such processes too), I’ll stick to assembly for full control over timing.
-Ahmad
p.s. I am not married to .NET MF, and won’t use it for all my applications, but I’m really impressed with it. Quite an improvement over BASIC STAMP introduced back in 1993 If you’ve been in the software development industry long enough, you’ll appreciate it.
I want to add something here. Using RLP you could achieve mora tha 1 Ksample/second easily. I actually have a little application taking samples on AD port into a queue on native code and .NETMF sending it over USB on the fly. There is plenty of time free on USBizi to make a faster loop or even a PID on native side.
The PC side is making a graph in realtime of the received data also on C# but there is allmost not free time there… (Of course I’m not an expert on PC apps I will need some help here…).
I’ll post this when I have some time if anyone is interested.
I also want to add that there is a thing in RLP we call “task” which gives you the ability to run a task at a very accurate time (real time). Let us say you want to record audio from an analog input and you want to sample it at 8K then you can very easily enable this in RLP which will fire your task exactly 8K times/sec. Then you can buffer the data…from C#, you will take the data and save to a file or send on network, which doesn’t need to be real time.
Gus sorta hit it on the head with native interop. Control theory stuff can be done just fine on NETMF [italic]targets[/italic] if special considerations are accounted for, like running the loop nativity.