Visual Basic for Automation

First of all, I hope you guys had a great Thanksgiving!

Here's a project-type question. I've been programming Rockwell PLC's for the last five years, but that has been the limit of my automation experience. I've been doing some thought experiments, lately, and was curious about something.

If someone didn't have a PLC and wanted to accomplish some simple automation tasks (reading sensors, turning on a relay, etc.), could a Visual Basic program be written on a PC to replace a PLC? Nevermind the question of whether someone SHOULD (cost, efficiency, ease of troubleshooting, etc.) I'm just wondering if it's even possible.

If so, what all would someone need to accomplish it besides the PC and Visual Studio?

Is there any kind of I/O hardware that could interface with it? If so, is there a way to get the tag data into the program (OPC server, etc.)? What type of communications media could be used to transmit the data from the I/O hardware to the PC? I'm not seriously considering it. I'm just trying to broaden my general knowledge of what I do, everyday. I think I do a lot of things, sometimes, with little knowledge as to why I'm doing it and what is going on behind the scenes once I dump my program into the PLC.

I know a little bit about hobby engineering -- microprocessors, ICs, etc. But all hobby engineering seems to use the PC only as a means of programming a microprocessor to handle all the external tasks. I was just curious if the microprocessor could be skipped and the PC used to accomplish the tasks that the microprocessor would normally do. If so, what would I need.

Thanks for any help you can provide.

Yes it is possible BUT it is definitely not easy.
I have not done this myself but I have worked with somebody who did it purely to see if he could. You will need a very good understanding of OPC and an OPC server such as Linx. You will also need a very good understanding of how Windows works and a good reference book on API calls useable in VB. The biggest issue my colleague had was keeping all of the different processes running at the same time. (this was with VB6. It may be easier with .Net). The solution is to run each critical process in its own thread but VB cannot do this without some fairly obscure API calls. As an exercise it might be interesting but as a practical application I would not recommend it.

Yes, this can be done and it is not an easy task from neither a hardware nor a software point of view. The hardware can be either internal or external to the PC, see the following links:

http://bb-elec.com/productcat.asp?topLevelid=4

http://www.advantech.com/products/Multifunction/sub_1-2MLKC9.aspx

and it is up to you, the designer, to decide which hardware platform will best suit your application. On the software side, most manufacturers of these I/O devices will provide ActiveX or .NET components to hook into your VB App. They typically provide sample code, as well, to help you along, but you still have to consider that PCs and PLCs are inherently different. A PLC has a definite, repeatable scan and deterministic I/O updates, but this is not the case with a PC. You have to handle much of this detail when writing the program and timing can be a very big issue.

I have done this with applications that are not critical, but I would probably not attempt to use this platform for any type of critical control, just for the fact that the PC has a lot of overhead from the OS and other components that could cause problems with your application. Also, unless you use an Industrial PC, the hardware will not be as robust as a PLC-based solution.

Regards

What you are asking is actually pretty common to my industry. If the process has complex math, typically one-off pieces of equipment will come to us with PC control with a custom program written in maybe C++, C# or whatever. Not too much VB anymore, but I have done this in the past. OPC is typically for PLC communications, so wouldn't be generally applicable here. You still need hardware, but there is plenty of DAQ hardware out there - the most popular being National Instruments (http://[URL="http://www.ni.com"]www.ni.com[/URL] and another brand: http://www.mccdaq.com). Search google for daq hardware and you will find plenty. It's in all flavors - PCI cards, USB, ethernet, firewire. Whatever you may want! Most of these companies have development software to make your applications anyway, so if I go the PC route, I would try to use the prepacked software route first anyway. Labview from NI is very popular, and I have seen DasyLAB used and it is very simple to setup.

These hardware companies typically provide libraries for interfacing to their hardware for use by the various programming languages- so instead of an OPC call, you use the provided commands to access the data. Same concept, just a different implementation.

I typically prefer not to have PC control, though. If I can do a PLC solution I almost always prefer that. There are so many issues with PCs - IT support...Antivirus software...Web surfing after hours...Windows updates rebooting the machine...automatic updates causing issues with the libraries...PC upgrades in 3-4 years...hard drive failures in a dirty manufacturing environment...I could go on.

Take a look at www.drdaq.com

I would echo robertkjonesjr on the availability of off the shelf solutions. National Instruments seems to have built their company around this from day one.

I suspect that most of the negatives mentioned about using a PC have also been addressed fairly well. On the plus side, you get to work with true object oriented architecture using a powerful and intuitive development environment such as Visual Studio.

Think of a small PC with solid state hard drive, running Windows CE, integrated graphics, no browser but built in Web Services. I familiarity is a bit out of date but I would like to catch up with this approach myself.

I am afraid that I will have to go against the flow here and say that I would not recommend the use of commercial DAQ equipment as a control system. I have had experience of a number of such systems and none of them worked very well. These were all using NI hardware and custom software developed with LabView/LabWindows. The problem in every case was keeping the systems running 24/7 due to memory leaks and other resource issues. The NI kit works very well for lab type installations and is fine if the system is turned off at the end of every day but for continuous round the clock use I have found that PLC type distributed IO with a proven OPC server is far more reliable. This is not an anti NI thing as I would use their kit every time for a high speed data acquisition job.

I was in no way suggesting using a cheap PC Daq for high integrity control! Just anwering the original question. "Nevermind the question of whether someone SHOULD (cost, efficiency, ease of troubleshooting, etc.) I'm just wondering if it's even possible."

Back to the OP, I've done a couple of them over the years. The last one was to exercise GM automobile instrument panels to failure in a environment chamber by faking its inputs & verifying outputs using digital and analog I/O in a PC running VB. Other projects used LabView. The National Instrument I/O boards (and other mfgs) come with drivers for different languages, include VB, so that you can do exactly what you describe.

Andy, your not against the flow - to be clear, in my judgement this is the 'last option'.

It's all a trade-off anyway. There is a value (or cost) to the various pros/cons we have all discussed. I don't own the business so sometimes I am told what I am going to support, even if I advise against it.

To me, if you put all the alphabet-soup to the side, you're left with an easy question to answer:
PC prices have dropped at a higher rate than PLC prices have dropped (over the last 20 years). IF PC-based control were a viable option at all, don't you think it would have kicked in at some point?
Add to this question: Which do you trust: PROM based operating systems or Microsoft based operating systems?
End of issue.

I'll just have to telegraph my ignorance and inexperience here since I hear this robustness argument all the time against PC's vs PLC's. My understanding is that our banking system is not run on a PLC. I suspect many other critical system we depend on everyday run on PC's (Servers) with more advanced operating systems. Someone must have figured it out.

My only attraction to the PC side is my frustration with the seeming lack of good object oriented development environments for PLC's. Maybe I have been looking in the wrong places. I am currently suffering through the use of Siemens Step7 to implement logic that could be done and tested in a fraction of the time in Visual Studio.

I have done this a couple times and only because the client wanted it done. The simplest solution I found was to use a Beckhoff BK8100 RS232 bus coupler. Their protocol is very easy to implement. If you like like to see a demo of it, I posted the source code (visual basic .net 2008) :

https://sourceforge.net/projects/bk8100/


Although automation using VB works, you will find it is not as easy to debug or troubleshoot.

A cheaper way to get some relay outputs would be to use a parallel port board. You can get them with 8 relays for abot $35.

recondaddy said:

If someone didn't have a PLC and wanted to accomplish some simple automation tasks (reading sensors, turning on a relay, etc.), could a Visual Basic program be written on a PC to replace a PLC? Nevermind the question of whether someone SHOULD (cost, efficiency, ease of troubleshooting, etc.) I'm just wondering if it's even possible.

Click to expand...

Yes but may I add non critical to the simple.

If so, what all would someone need to accomplish it besides the PC and Visual Studio?

Click to expand...

Yes. It is done all the time.

Is there any kind of I/O hardware that could interface with it?

Click to expand...

There are plenty of DeviceNet, Ethernet and Profibus DP I/O devices out there.

If so, is there a way to get the tag data into the program (OPC server, etc.)?

Click to expand...

Yes, we use MySQL.

What type of communications media could be used to transmit the data from the I/O hardware to the PC?

Click to expand...

I mentioned a few above but the right one depends on the application.

That said, I would not use Windows because it isn't real time and Windows CE is more for products than one off projects.

We use QNX for real time control and VB.net doesn't work on QNX unless there is a MONO port for QNX.

The key may be to off load the real time part to a PLC or motion controller anyway.

I saw some NI comments. We use NI for our automated test systems. It works well for that but it is not a control system. NI can make a good front end for a PLC or motion controller. I know a lot of our customers use it.

I'll just have to telegraph my ignorance and inexperience here since I hear this robustness argument all the time against PC's vs PLC's. My understanding is that our banking system is not run on a PLC. I suspect many other critical system we depend on everyday run on PC's (Servers) with more advanced operating systems. Someone must have figured it out.

Click to expand...

Our servers have a a room to themselves with plenty of air condition. They are not in the dust, heat, cold, moisture, and vibration environments that PLCs are subject to. They wouldn't have a chance at passing the test the PLC OEMs make their equipment go through.

I have been to the labs or test centers for both Modicon and Rockwell. I know how their boards are tested or any third part boards are tested because they must meet the same standards. Believe me a normal PC would not like being cooked at 60 or 70 degress C and shaken violently. Rockwell is brutal because they thermal cycle the boards from cold to hot to cold quickly.

Anything big and heavy like big filter capacitors will shake lose. Any high powered PCs will generate too much heat.

That doesn't mean that one can't find industrial strength PC, you can. However, they will be MUCH more expensive than the Dell's you find at Costco and Walmart. They will be as expensive as the PLCs.

Finally, long term support is important. The PLC manufacturers will try to be able to supply replacement parts for as long as possible. Do any of you have PCs with ISA buses? They went the way of the dinosaurs years ago. My Modus Plus card doesn't fit in any my new PCs. I keep some old Win98 computers around that have a ISA slot so I can still use the old cards I need to. So what is the next PC fad? The manufacturers don't like using Intel CPU because there are new ones every year that obsolete the old ones making them difficult or expensive to get if it is possible at all.

Now that I think about it the DeviceNet or Profibus DP card in the PC may not work in future PCs. That has happened to us.