ASP.NET versus Windows Forms for Industrial, Manufacturing, & Laboratory Automation

Platforms

There are three main platforms you can choose to develop on: Windows Forms, ASP.NET, and CE.NET. 

Windows forms is most of the programs that you install and run on your computer.  Very fast, nice user interface, and you have control over what it does. 

ASP.NET is a web based program.  There is a web server somewhere, running Microsoft's IIS that has your ASP.NET application on it.  You use Internet Explorer to connect to the web server and the web server serves the web pages to you as you go from page to page.  This is primarily intended when you have lots of users all running the same program.  Note that user interfaces are harder to develop than Windows Forms and the computer is not usually tied directly to the process. 

CE.NET is the closest platform to a real-time operating system.  CE.NET was designed for computer processors that have limited horsepower, memory, and other resources.  Examples are cell phones and PDAs -- battery powered, compact in size, limited function.  Industrial computers that run CE.NET have more limitations than a regular computer running a regular operating system like XP. 

So what type of platform is best?  It depends, of course...

What are the Real-Time Requirements?

There are three primary functions that automation software performs: control, monitoring, and distribution of information.  Let's look at these requirements with respect to time. 

The problem with "real-time" is defining what is "real-time".  It can vary from programmer to programmer, application to application, and industry to industry.  The reason so many people have problems defining "real-time" is because it is different for every application.  But hopefully you don't expect weasel answers to come from our website!

"Real-time" is twice as fast as the user needs and expects the response time to be.  Ten times as fast as the user wants is beautiful and ensures a safe buffer for when things go wrong (as they always do in the real world). 

For example, if you have 1,000 consumer products racing down a production line per minute then "real-time" better be at least twice as fast or 30 milliseconds (33 times a second).  In 30 milliseconds, you need to be able to detect something, make a decision, and change an output.  At ten times the response rate, you are looking at 6 milliseconds. 

Whereas an engine production line may only produce 1 engine every minute.  So real-time becomes 30 seconds. 

Suppose a user wants to look-up the number of rejects from a process.  In "reporting" types of cases -- users are willing to wait several seconds.  Two to three seconds is great, five to seven seconds is okay, 15 seconds or more makes users very unhappy and likely to burn down your cubicle -- computer and all! 

Let's go back and visit the three purposes: control, monitoring, and distribution of information.  As a rule of thumb for one application (not comparing one application to a different application), "control" typically has faster real-time requirements than just monitoring and monitoring has faster requirements than just reporting. 

But for application to application -- you can't define real-time in terms of control / monitoring / reporting.  Since controlling an engine production line could be slower than returning report type information. 

To make things even more confusing  -- most applications have more than just one real-time component!  For example, you may have to control the line at a 10 ms (millisecond or 100 times per second) response rate -- but your reporting response rate does not need to be but 5 seconds.  In this case we might call the "control" a real-time controller and the "reporting" non-real-time. 

Windows Forms

We love the way that Windows Forms performs in all three of these applications.  For the high speed control applications, we feel that using a real-time controller (such as PLC, soft PLC, etc.) and using Windows Forms as the non real-time controller is a great combination.  In applications where the fastest real-time response rate is 250 or 500 ms (milliseconds) then we probably would just use VB or C# to do control, monitoring, and reporting.  Again it all depends on what all needs to be done.  We are typically very conservative in developing our system architecture. 

With all of these vendors selling "soft" PLCs that tell you that you can run their real-time controller at single digit ms response times and run a full VB or C# operator interface on top -- try it out on one of your non critical, easy applications first. 

Although VB and C# can achieve 1 ms (or faster) response times in some applications, trying to do so with all applications is not going to happen.  Even with the HT (hyper threading) technology.  You will be pushing your luck.  In fast applications it is better to separate your requirements between real-time and non-real-time and use two controllers. 

ASP.NET

The hype surrounding ASP.NET is that it would be integrated into Visual Studio and be just like Windows Forms.  Wrong.  Although it is a lot more like Windows Forms -- it is still very different. 

Note that we don't suggest using ASP.NET for control.  Depending upon the application -- probably not for monitoring.  For distribution of information -- if you have the data sitting in databases and want a web based configuration then ASP.NET is the best way to go. 

We still prefer Windows Forms for control and monitoring.  We like Windows Forms for distribution of information also.  We like the capabilities of a Windows Forms client instead of a browser -- much richer user interface. 

There is a lot of overhead involved with IIS and getting real-time, consistent response time is a challenge.  However, as a reporting tool of process data (or especially for any data sitting in a database) -- ASP.NET definitely make sense. 

The main reason we are using ASP.NET in our example programs is so that you can see the examples without having to download the code, unzip it, load it into Visual Studio, build the solution, and then run it.  However, you will see that some of our example programs are not done in ASP.NET since we would rather have pins pushed up under our nails than try to convert the programs to ASP.NET. 

We are not trying to bash or diminish ASP.NET.  It's just that ASP.NET and Windows Forms are two totally different technologies and used for different purposes.  You should think about the consequences first.  We feel that if you can get the customer to use a client application in Windows Forms then that should be your first choice.  Otherwise, use ASP.NET and have the clients use Internet Explorer to view data.  We still recommend using Windows Forms for control and monitoring applications. 

PLCs with Web Servers?

Although some vendors are pushing this -- we don't agree.  Most people could care less what a PLC thinks.  They want to know how a process is doing.  Ordinarily that is reported by a SCADA system, not a PLC.  So we assume they are trying to implement a SCADA system in a PLC, which IOHO, is not a great idea. 

Second, process data needs to be Microsoft based so that it is compatible with the rest of the world.  If you are a production manager, process engineer, or a quality control person which would you rather have -- a web screen that you print or an Excel spreadsheet full of numbers waiting for your use?  A non Microsoft solution is taking steps backward. 

We try to offer a fair and balanced opinion on every page of our website.  We would appreciate more information from other users to express their opinions which we will then incorporate.  If you have questions or comments please post them on our message board (see button in left hand column) so that others can read and benefit.