I hate Visual Basic!

Ok... I love PLC's. If you dig down deep enough there is always a reason things happen the way they do. It's all fairly low level when you think about it.

But more and more I see visual basic making it's way into traditional controls applications. This may not be too bad on it's own, but then it's always stuffed with 15 someodd ActiveX applications...

How the hell is a field tech supposed to support some ActiveX module that was built to be black box proprietary? Why weaken a nice ControlLogix PLC by making it deal with some crappola DELL running some badly written VB code that dies randomly when one of the ActiveX module decides not play nice?

In my mind, 'safe reliabilty' is the goal for an industrial process. How can relying on code that you can't even see be safe or reliable?

Grrrr... Sorry for the rant, but at least in the company I work for all the new machinery seems to rely on the principle: 'PLC's for interfacing with physical devices and PC's for the rest.' Even when the PLC is more than capable for the specified application.

I do this quite often. We've got computers at each work station for general use, and don't want to spend the extra bagload of $$$$$$ for specialized HMIs that only com with a PLC.

Perhaps as the HMIs get to the next generation, with email, pdf, and a host of other functions, I might reconsider.

But in the mean time, for my industry, the answer is computer based interface.

(That even rhymed, how clever am I?)

monkeyhead said:

How the hell is a field tech supposed to support some ActiveX module that was built to be black box proprietary? Why weaken a nice ControlLogix PLC by making it deal with some crappola DELL running some badly written VB code that dies randomly when one of the ActiveX module decides not play nice?

In my mind, 'safe reliabilty' is the goal for an industrial process. How can relying on code that you can't even see be safe or reliable?

Click to expand...

That doesn't sound good. I like using VB for applications programming when I must write for the Windows platform but for a SCADA terminal ? I wouldn't dream of it. I've seen my own VBA apps bring Excel down for no appearent reason.

Of course, with the cost of traditional HMI systems, I can see where managment could be convinced to go this route. Managment isn't know for making good decisions when a large cost difference is involved. They'll always go with whats cheaper.

The only thing that could offset this trend ( if it is one ) will be when the open source HMI tools are mature enough to use in industry. I see this taking a LONG time. On that note, all of the open source stuff is meant to be interfaced via a web browser. A bad idea in my opinion.

But back on subject, does the HMI cause unpredictable behavior or shutdowns of the machines being controled ? If this happenes often, I would think that the downtime alone would justify the cost of traditional HMI software.


Just my $0.02.

castlerock said:

But back on subject, does the HMI cause unpredictable behavior or shutdowns of the machines being controled ? If this happenes often, I would think that the downtime alone would justify the cost of traditional HMI software.

Click to expand...

This goes beyond just HMI... large chunks of the control logic itself are being handed off to these apps. And when the process starts acting goofy because the 'PowerTCP' activeX module is doing who knows what... then we've got a problem.

And unfortunately in my particular business, nothing justifies a higher initial cost to management. One year turnarounds on all costs no matter what the scale of the project is... Aparently downtime is easier to hide in the budget than the initial capital request.

Offloading controls onto the apps? That's insane. There isn't anything that these appsare capable of that ControlLogix can't handle with just basic input from the HMI.

monkeyhead said:

This goes beyond just HMI... large chunks of the control logic itself are being handed off to these apps. And when the process starts acting goofy because the 'PowerTCP' activeX module is doing who knows what... then we've got a problem.

Click to expand...

ACK! It sounds like this system was built by a VB programmer who dabbles in PLC programming. Thats scary.

monkeyhead said:

And unfortunately in my particular business, nothing justifies a higher initial cost to management. One year turnarounds on all costs no matter what the scale of the project is... Aparently downtime is easier to hide in the budget than the initial capital request.

Click to expand...

I've also found this to be true...until after the fact. Last May I was involved in the installation of a new SCADA project on one of our outlying platforms ( oil/gas production ). The project was push out the door 2 weeks early because the drilling was completed. We were all getting yelled at because testing was taking too long. ( they expected me to bypass all of the safety devices and open the wells ) Then I heard many complaints about 'that damn computer' from managment because the system was buggy and we would get random shut-ins, the logic wouldn't chage itself to meet our needs(well sort of), etc. The 'damn computer' statment came from a pretroleum engineer. He calmed down after I explained how easy it is to change the logic in the plc compared to re-running tubing for pneumatic controls.

What i learned: If your good at what you do, have the backbone to tell managment how it is. They won't fire you and if they do its easy to get another job. I still work here. =]

One solution is our approach.

We don't use or accept any controls outside of our basic package. No custom activeX, no fancy custom graphics, just what we consider to be standard tempate stuff.

Sure in this nice computer world, you can make things look good, but what happens to basic controls when you do that. Well, everyone here apparently knows. We accept that our system will not look or feel state of the art, but it functions well without crashing. The only things on our scada is scada related. Our historian historizes, and our web server supports the web applications. Easy as that. Each machine does what it is intended. We don't add other software to attempt to make things pretty or just because we can.

Brave new future

This happens all the time here. Some are written in C++ and you never get the source code. If you want the product, you buy what they have available. The latest here is a computer with the companies own "interface Cards" for encoder, digital and positioning control. It came with a Micrologics 1200 even though we have a PLC5/40E remote rack sitting right next to this new control box. They offer teck support and a modem line was installed into their computer running windows 2000. The system works and is, for the most part, trouble free. We also have a number of HMIs running VB code from a private individual. I do not like Windose, but these work and are reasonable in cost.

Bruce99 said:

The latest here is a computer with the companies own "interface Cards" for encoder, digital and positioning control.

Click to expand...

Who made that?

Deltacompsys...!? :-D

CroCop said:

Perhaps as the HMIs get to the next generation, with email, pdf, and a host of other functions, I might reconsider.

Click to expand...

Have you looked at the C-More panels from AD (http://c-more.automationdirect.com)? I know it does email, ftp, and www, but I'm not sure on PDF. Video is supposedly coming soon as well.

panic mode said:

Deltacompsys...!? :-D

Click to expand...

We don't make PC cards. Our controllers look like my Avatar.

Have you looked at the C-More panels from AD

Click to expand...

Apparently AD and EZAutomation have locked horns and are suing
each other. EZAutomation claims that these panels are a copy of theirs.
Neither Company makes their stuff in US.
EZAutomation have looked at other designs and then put together a wish list. This wish list was then turned into a product in India.
As far as I am concerned both Companies are just re-marketers
who sell basically the same thing produced elsewhere.
On top of it EZAutomation intends to re-market here in US all sorts of other cheap controls made in low cost countries.

I for one will stick with one Company that at least makes some their stuff here - Allen Bradley.

marksji said:

Have you looked at the C-More panels from AD (http://c-more.automationdirect.com)? I know it does email, ftp, and www, but I'm not sure on PDF. Video is supposedly coming soon as well.

Click to expand...

Yes, I have. They are almost where I want them to be, but the industry I work in is basically a machine shop, and it's nice to let the machinists have access to the Pro E models & drawings to check dimensions and tolerances.

It's getting closer.

Jiri Toman said:

As far as I am concerned both Companies are just re-marketers
who sell basically the same thing produced elsewhere.

I for one will stick with one Company that at least makes some their stuff here - Allen Bradley.

Click to expand...

Umm... OK so AB makes some of the products they sell and they even make some of those products that they make themselves in the USA. So?

AVG does have a manufacturing plant in the US so I assume that some of their stuff is made here.

To the best of my knowledge AD doesn't make anything (except money and happy customers), but many of their products are designed and built in the US... anyone ever here of HOST Engineering?

The C-More product was a joint US-Japan design between Koyo and AD and is made in China; I have no idea who 'makes' the C-More panels, but I do know they can only be purchased from AD.