Visual Basic as a Soft Engine

G

Thread Starter

gottwald

Has anyone out there used VB for the actual Controller instead of a PLC. If you have would you be willing to share your code?
 
The problem with using VB to emulate a PLC in a control environment is that one cannot achieve a constant scan rate.

Visual Basic is basically an Events Driven Software platform, in that it relies on the user input to trigger events. This means that the software processing time cannot be guaranteed. Even if one uses timers in VB, the time periods are not guarenteed as this period depends on the operating system and CPU loading.

A PLC has a predefined scan rate so that input processing is guarenteed to be acheived at a set rate. The scan cycle of a PLC is interupt driven in order to accomplished the scan rate.

If one is implementing PID control it is essential to have a constant scan rate.

Another factor is that VB on a windows platform is not as robust as a PLC. There are a larger number of external factors that can influence the reliablity of the program. Even a bug-free program can crash due to these exernal factors.

In a PLC most of these external factors are absent and normally a bug-free program will run until the hardware eventually reaches the end if its life.

I hope this gives you so insight.
 
I tried this a while back as a project at wentworth Inst. of tech, and it was a great learning exp. but in complex control loops it was very slow and unstable, even when using a ramdrive for OS and VB, all in all i would not use a PC for much more then an HMI w/ alarming and data trending
 
J

Jake Brodsky

If I saw anyone doing anything this stupid, I'd try to get them removed from the job. Never mind VB, a Microsoft OS is simply too unreliable to use as a controller for an industrial process.

You may not like the price, but one of the things you get in a PLC is a carefully tested firmware which should contain almost no glitches or bugs.

If you really want a high level environment to work from, there are DCS solutions available. If the process is simple and not critical, write your application in C and embed it on a single board computer. Any of those solutions is better than using a bloated wad of mysterious software with a very poor record of reliability.
 
M

Michael Griffin

Read your inputs, assign their states to boolean variables, solve the logic, then write the results to your outputs. This is essentially what a PLC does.
When solving the logic, a series of "If ... Then ... Else" statements each
represents a rung of logic. In another language, you might implement this as a series of simple boolean equations (e.g. C = A and not B), but the loose syntax and automatic type conversions in Visual Basic make this rather risky and prone to bugs. This is a language problem in VB which perhaps some Visual Basic expert has a solution to.
You can implement a state machine or SFC (with no parallel paths) design as a "case" structure. This can be quite good for simplifying a complex design, but be sure to actually draw out your complete state diagram or SFC before
writing the code.

I have recently been repairing (replacing) someone else's object oriented VB
spagetti code control logic by using the above methods. It is more difficult to work with and more verbose than ladder logic, so expect to spend more time on it than you would with a PLC. Also, spend the time to simulate running each code section off line. You can set up screen buttons and lights to simulate real I/O and run the code manually.
Unfortunately, the language design of VB means that while it is easy to get a program to run, getting it to run correctly is another kettle of fish altogether. Be especially careful of things which may cause VB to do automatic type conversions on your boolean variables, as this can cause no end of problems in this sort of application.

************************
Michael Griffin
London, Ont. Canada
************************
 
K

Krishna Sastry From Kuruganti Computers

I have developed a windows based ladder logic programming software in VB. It works realtime. It is interfaced to a hardware module that consists of I/O modules. It sold as a product of my firm and so I cannot disclose the source codes. If you are interested, I can send you an instruction manual of our product.
 
C

Curt Wuollet

Why would you do that? MS bashing and reliability aside, it would probably kill your event driven response and is ill suited to consistant timing for the cyclic portion unless the variations
are swamped by scanning every second or so. To do a lot better than that you have to know a lot about how it works. Not very easy with a large closed product. If your task can be sequential and event driven without critical timing it's reasonable but, often VB doesn't keep up with human speed. It would make much more sense to use some sort of small executive and use the VB to display the results. Of course using RTLinux and say, TCL/Tk would be better yet but that's another story. Even on Linux with C, I decouple the display and the scanner/solver.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
 
M

Michael Griffin

Sometimes what you are dealing with is a PC application which has to interface with the real world via digital I/O. This is fairly common with
computerised test equipment, where you need to directly control the test fixture, or to handshake with the PLC which is controlling the rest of the machine. In these applications the concepts and methods used in PLC programming can often simplify the control logic compared with conventional "computer programming" style. Typical computer programming classes do not deal with these sorts of applications, and most people are left to learn this on their own.

I wouldn't however write a VB program purely as a substitute for a PLC. Leaving the practical aspects of this aside, the extra man hours involved would render it very uneconomic.

************************
Michael Griffin
London, Ont. Canada
************************
 
A

Asif Khokher

This question is in many minds in the recent times, and definitely this is future question. The question is of Reliability and Robustness which VB based system shall lack. One of the solution to get some reliability upto some point is to have a PC with FlashEEPROM harddisk installed. Develop only Control Modules (PLC prgramming) in the VB, without any Operator
Interface code there, so most probably it shall come as DLL files. Run it on a PC with minimum installations and better Operating System kernel, even without keyboard and Monitor. Then have a second PC to make it Operator Interface Station(s), also for the Engineering purposes i.e. developed in VB. This OPerator Interface PC shall communicate on Network with the earlier Control PC. You can even install an industry standard network.

One of the reason behind this idea is that Frequency of Windows crashing increases when there is more Human Interaction with the PC. Getting Robust Harddisk with better Operating System shall definitely increase the reliability as compared to the solution where you will run every thing in one PC and allowing the human interaction.

Asif Khokher
INTECH Process Automation
 
M

Michael Griffin

As I understand it, you are suggesting that since programs written in VB and the Windows operating system are both unreliable, it would be better to have two PCs with two different VB programs, two copies of Windows, and then link them with a network. I should think that the end result will be a system that is several times *less* reliable. You've simply added more things to fail.

If you feel that Windows is an unreliable operating system, then don't use it. There are a number of alternatives. If you feel that programs written in VB tend to be unreliable, then don't use VB. Again, there are alternatives.

There may be valid system design reasons for using a networked pair of PCs, but making up for reliability problems with Windows or VB applications shouldn't be one of them. If the software you use is unreliable, get better
software.

************************
Michael Griffin
London, Ont. Canada
************************
 
A
Actually, as other people have pointed out, its not the reliability of the Windows PC that's the problem. Its possible to put together a reliable Windows PC (it just takes a little work, know-how, and some TLC). The problem with VB as a control solution is the fact that VB is an event-driven programming language best used for create interactive applications that interface to something else (e.g: database) that does the real work.

Want some other reason VB would make an awful plc?

* Lack of built in support for common types. VB (as of my VB 6.0 SP5) doesn't have signed 8 bit values, and unsigned 16 and 32 bit values.

* Lack of transparency. Want to optimize your program? Good luck. With C and C++ (among others), its easy to profile code. If something becomes very critical, you can drop to inline assembly with C and C++. Can't do that with VB. (Well, you could always CALL a function that is written in assembly...)

* Timers. The built in windows timer will only fire once every 55ms. You can get faster using a high-resolution "multimedia" timer, but I suspect the jitter will kill you if you try and do something intensive like move the mouse.

VB, while useful for many GUI oriented front end tasks, isn't suitable for control.

Alex Pavloff
Software Engineer
Eason Technology
 
M

Michael Griffin

On May 15, 2002 04:25 pm, Alex Pavloff wrote:
<clip>
> Want some other reason VB would make an awful plc?
>
> * Lack of built in support for common types. VB (as of my VB 6.0 SP5)
> doesn't have signed 8 bit values, and unsigned 16 and 32 bit values.

What I have found to be a worse problem is when VB decides it wants to convert your data to a different type from what you declared it as. I could do without such "help". Does anyone know of a cure for this?

> * Lack of transparency. Want to optimize your program? Good luck. With C
> and C++ (among others), its easy to profile code. If something becomes
> very critical, you can drop to inline assembly with C and C++. Can't do
> that with VB unless you.

Worse again is that the language is not designed to encourage good programming techniques or practices. It's simply an agglomeration of features intended to encourage twiddling. You end up with object oriented spagetti code very easily.

> * Timers. The built in windows timer will only fire once every 55ms. You
> can get faster using a high-resolution "multimedia" timer, but I suspect
> the jitter will kill you if you try and do something intensive like move
> the mouse.

I think the timer resolution depends upon which version of Windows you are using. I ran an experiment to find the "tick" counter resolution on different PCs (the seconds since midnight value). WIth Windows 98 the tick resolution
was 55ms, but with Windows NT4 it was between 8 and 12 ms (it jittered between those two values). I don't know if the regular timer control can take advantage of the Windows NT tick resolution, but it seems the old 55ms timer chip interupt which originated with MS-DOS disappeared with WIndows NT.
Realistically though, it seems that unless your VB program is doing something fairly trivial, you would be lucky to have a consistent response at 100 ms. Windows and VB will "try" to service your program at the interval you requested, but Windows isn't a real time operating system, and VB doesn't support real time operations.
Also realistically though, most control applications don't need real time control. They just need reasonably fast response to events which are going to wait for your program to get around to servicing them.

> VB, while useful for many GUI oriented front end tasks, isn't suitable for
> control.
<clip>
People have been using it in applications that bridge these two domains though, such as test equipment. You need a good GUI so people can see what the tester is doing (even if it's fully automated, they still need to set it up and diagnose rejects), and you also need a bit of control to conduct the test. There are various third party VB tool kits and controls available for this application.
I'm not so sure though that it is a good choice for this application, for the reasons you have stated above as well as for others. I think what happens is that the people who are writing the test programs are often engineers without much programming background, and Visual Basic has a reputation for being "easy". It's often just seems to be the obvious choice for people who don't like programming for its own sake.
My opinion on that now though is that it is easy to get a small and simple program working with VB, but difficult to use it to get a large and complex one working correctly. Unfortunately, there are very few real world test systems that can be considered "small and simple".

************************
Michael Griffin
London, Ont. Canada
************************
 
A
Michael & Alex!

You have rightly pointed out that VB is not suitable for control purposes. But the question was to use VB solely and implement it in Microsoft
Environment. Getting the maximum from VB based solution is difficult, but finding ways in low level languages i.e C, C++, Assembly.... is not easy for an average programmer especially diagnosing & maintenance. VB is user friendly and generation of lot of ActiveX control in the markets has lead to use of VB. Windows is also striving to be real time operating system, and hopefully dream of VB based soluton can become reality in near future.

Regards
Asif khokher
INTECH Process Automation
 
A company called Mabry makes a high res timer for VB called Hitime. It can trigger events down to 1 MS. I have experimented with it for animation but I have not used it in production.

The control has a variable to monitor missed events. At .001 second, it missed frequently.
At .01 second, it was pretty good, but it missed some when I moved the mouse around. I boosted the apps priority to "realtime" under Win2K.

With a little experimentation, and NO MOUSE, you might be able to make a soft PLC with VB, but I would not use it for any time or safety critical processes. It would be better suited for a test
stand or other data acquisition applications.

Search for Mabry on the net. They have a free demo of Hitime.

Bill Sturm
 
C
Hi Asif

> You have rightly pointed out that VB is not suitable for control
> purposes. But the question was to use VB solely and implement it in
> Microsoft Environment. Getting the maximum from VB based solution is
> difficult, but finding ways in low level languages i.e C, C++,
> Assembly.... is not easy for an average programmer especially diagnosing
> & maintenance.

That depends on what you call an average programmer. I am conversant in all the mentioned low level languages and half a dozen (more or less) high level languages, but I still wouldn't bill myself as a programmer. It seems definitions have slipped a lot in the Microsoft era. But, as a general rule, if you can't properly program the task at hand, you're not a programmer.

> VB is user friendly and generation of lot of ActiveX
> control in the markets has lead to use of VB. Windows is also striving to
> be real time operating system, and hopefully dream of VB based soluton
> can become reality in near future.

Oh the horror!, the horror!

IMHO the blight of people who think programming is running end user software and pointing and clicking something together is directly responsible for the lack of progress in PC automation. When a "Hello World!" program is two megabytes, it hardly qualifies as progress. Think of it this way, how on earth can you possibly make two pages of control code perform poorly on a 1Ghz machine? Code it in VB. I'm not sure it is possible in any other way. And that's programming? In any of those "low level" languages, with skill, you could run hundreds of instances of the same logic before slowing the machine much. I think we're moving backwards fast. Opinions?

Regards

cww
 
Top