LabVIEW RT versus PLCs

  • Thread starter Taylor, Carson - TOP
  • Start date
T

Thread Starter

Taylor, Carson - TOP

Hello: I'm new to the group and I'm starting on my first real-time control project.

LabVIEW Real Time and Modicon PLCs are candidates for my project, with some in-house programming talent in each. LabVIEW is used in our company in some data acquisition applications, and Modicon PLCs are used in some control applications.

What is experience with LabVIEW RT in critical control applications?

Some aspects of my application are:
- Fuzzy logic control may be used.
- Occasional tuning and algorithm changes may be done by users (casual/infrequent programmers). I think this would favor LabVIEW.
- High reliability/fault tolerance is important. Some of our PLC applications have 2 out of 3 voting or analog middle value selection is used.
- Input data is analog over a wide-area network at 30 samples/second. The number of input channels is modest (100-200).
- Output will cause discrete, feedforward control action.
- It's basically one of a kind implementation. Cost from hardware/software vendor is not critical compared to development cost, reliability, maintainability and ease of change.

I think a PC solution may offer more flexibility and sophistication in the algorithms, and LabVIEW has a lot of capabilities in signal processing,
filtering, linear algebra, etc.

Does anyone have experience with fuzzy logic tools in either LabVIEW or PLC?

Carson Taylor
Bonneville Power Administration
 
A

Alexander Paulsen

I have no direct experience with LabView, but have used fuzzy logic algorithms on PC based control before. I used a development system called Fide to generate the C code based on the rules and member ship sets, imported the code into Factory-Link 4.4 compiled Math+Logic, then downloaded the de-fuzzified values to an Allen Bradley PLC-5/40.
It worked well, but I used it on a slower process. You have to be mindful of the fact that any PC based solution will not be true realtime, and will not be as deterministic as a pure PLC based solution.
It worked fine for me on an anaerobic digestor, since the process is lazy, on a faster process I would worry that the system would hunt too much.

I would be interested in knowing more about your application and how it turns out.

Thanks

AP
 
R

Ralphsnyder, Grayg

What are the failure modes of your system? Will it blow up or will it just stop and sit there? How reliable does your system need to be?

My suggestion is that the PLC (Modicon) will be more reliable than the PC (LabView). I have used PCs for control when the system fails it just stops and sits there until you fix the problem and restart it. For anything that requires more reliability I use a PLC.

What you might want to do is to use the PLC to control the equipment and use the PC as a SCADA device. It can be your operator interface, data
collector, information processor, and report generator. (Don't forget a hardwired E-Stop button.)

I last used LabView about five years ago so could not comment on the present capabilities. I presently use Wonderware.

Grayg Ralphsnyder
 
We don't use Labview -- we only know something about that it's based on PC, so we think it would be better use a PLC.
We use Modicon PLC for a long, long time and we consider it is one of the most reliable PLC on the market. It's very robust and it is very updated with the newest technology too. Quantum is a Modicon PLC that include functions as Fuzzy logic (using Concept programming software.

Alisson from CVRD, Brazil
 
B

Bryan Joles In-Control Systems

At my previous job we used PLC's for everthing, they were very reliable, easy to program, and troubleshoot. If something went wrong it only took a turn of key and we were back running. I always wondered why we didn't use PC based
control. At my current job I realize why. It is too unreliable, to difficult to handle multitasking. I feel that the PC should only be used in data aquisition. PLC are designed to handle automation, logic and I/O. PC's are designed to do word processing.
Bryan Joles
Symbol Technologies Inc.
 
I have worked in a LabVIEW shop, and can tell you this ... IMHO; be careful when using LabVIEW (or BridgeVIEW) to control industrial applications. Both can be unpredictable and should not be introduced into a plant environment unless you're confident that it will work as tested. Also, the vi's are not always transferable
between versions of the program. This often requires reprogramming of the original vi's when a new LabVIEW version comes out. It would be best to stick to PLC control at this time, and leave LabVIEW to do what it's best at ... data acquisition.

Regards,

John
 
D

Daniel Boudreault

Hi,

>Hello! I'm new to the group and I'm starting on my first real-time
>control project.

Aren't most control real-time?

> LabVIEW Real Time and Modicon PLCs are candidates for my
>project, with some in-house programming talent in each.

Does LabVIEW say Control ? No...it says VIEW...

> LabVIEW is used in our company in some data acquisition
> applications, and Modicon PLCs are used in some control applications.

Keep it that way.

>What is experience with LabVIEW RT in critical control
>applications? ...<clip>

Critical means using the trustworthy PLC, which was designed specifically for "real-time" controls.

If it is for your own "shop", then I can't stop you from using what ever you like to use... but if you are going to sell the end product to a customer, better check if they have the staff to maintain the PC.

PCs take tooo long to reboot. PLCs take a second.
PCs have too many moving parts.
PLCs has none (if you are not using relay outputs).
PCs has slow I/O. PLCs has fast I/O.
People like to mess around with PCs.... and they don't even notice that PLC eists...
PCs configured correctly costs more than a PLCs.

You can't fix the hardware with software...
PCs are not REALTIME devices. Realtime OS only can mimic realtime...
I think PCs will be ready for critical tasks in 10 years. (My opinion.)

I only use a PC on non-critical control projects, user interfacing, data collection and analysis,
and for trouble shooting. LabView is good for these kind of tasks.

Good Luck, Dan B.
 
Hi,

First of all I have to precise what is LabViewRT. This software used the standard G graphical language of LabView but the runtime is
implemented (dowloaded) to a PXI card (or in a near future to a FieldPoint embedded controller). So the remarks regarding the stability of a PC is not a criteria for your application.

Regarding the application you want to control, my opinion is that G language is more flexible than PLC languages. So for an application like yours I will recommend LabViewRT.

If you need more information, please feel free to contact me directly.

Steve Monnet
SAMPI2
www.smapi2.com
[email protected]
 
That is correct,and they still can't get it to work reliably. What chance would you have with a "real" application that also had the responsibility of equipment and personnel safety?

I don't use a screwdriver to hammer nails, right tools for the right job.

Cheers All
 
C
Hi Guys

Let's not make blanket judgements here. I wouldn't use crashware for anything that involved life or limb either. But there is a FAA certifiable version of Linux that I would trust more than the hardware. Many modern PLC's have a lot of PC internals so the difference isn't as striking. I did an analysis recently on how well the stated advantages of PLC's held up in practice. In our situation, they aren't doing very well. They are expensive, single sourced, buggy, not remarkably easy to program for advanced work and the bulk of our development time is spent trying to integrate them as the vendors work hardest on preventing interoperability. The support software is expensive and fairly unstable as well. Our electricians wouldn't stand a chance trying to fix the more complicated bits.

They _are_ mostly reliable and not very fragile.

I would be extremely interested in a run-off with a good commercial spec SBC running Linux or QNX in true cost including development, initial cost,
maintenance, and downtime in our environment. The most reliable box in the place is an old P60 clone running an ancient version of Interactive UNIX and GE's Cimplicity IU which they will no longer sell us. It usually makes it a year between planned downtime to blow the dirt out and oil the fans. I think the recent trend to NT
and even W9X for process control is really giving PC's a bad wrap..

Regards

Curt Wuollet, Owner
Wide Open Technologies
 
R

Robert Trask, P.E.

> PCs have too many moving parts. PLCs has none (if you are not using
> relay outputs).

Huh? What about a PC running NTE with flash memory? What are all these 'moving parts'....

> PCs has slow I/O. PLCs has fast I/O.

Huh? EVERYTHING depends on the application and what is applied.


> People like to mess around with PCs.... and they don't even notice
> that the PLC exists...

One of the reasons to use an industrial computer that does not have the appearance of a desktop. And you totally devote the "IPC" (Industrial PC)
to the application. A good interface will not have the Windows task bars, and as far as the operator is concerned, is just another interface.

> PCs configured correctly costs more than a PLCs.

NOT TRUE in many control schemes! Just try to get a motion platform, AND an interface, AND the machine/process logic, AND database/data collection, AND and inhouse web server to run on a PLC platform. The generic, ubiquitous PC
platform we have now allows this on a VERY cost-effective basis. PC's are not meant to replace SLC's and the like.

> PCs are not REALTIME devices. Realtime OS only can mimic
> realtime...

PC's are indifferent. The OS and any related kernels decide this. And BTW, every control platform 'mimics' realtime because there is no such thing. There is always a delta t to get something done. But will that delta t get in the way or not? And is that delta t predictable and repeatable? Try running a SERCOS motion ring on a PLC. For that matter try and get ANY highly synchronized motion done on a PLC.


> I think PCs will be ready for critical tasks in 10 years. (My
> opinion.)

They have already been doing many critical tasks for the past 10+ years.

Robert Trask, PE
Wilmington, NC
 
P
Can you share that analysis with the rest of us?

Paul T


> I did an analysis recently on how well the stated advantages of PLC's held up
in practice. In our situation, they
> aren't doing very well.
 
Hi Curt

You make some valid points and some questionable points.

I am not a regular contributor but when I do contribute it is normal a rebuke for Rockwell Automation's products. However, even with the
problems I have with AB products it is still a no brainer on whether I would use their PLCs over a computer based system. We all speak from experience and all have our favorite stories, both good and bad. So there is always going to be contention in this matter.

Again however, sound engineering testing will go a long way to substantiate claims made by individuals. Your statement "I did an analysis recently on how well the stated advantages of PLC's held up in practice." is an important one since this is the type of information that the list would like to see to remove some of the
subjectiveness and replace it with objectiveness.

So here is your chance to substantiate your claims with solid evidence, I for one would be extremely grateful to see what bugs a PLCS had when compared to a PC.

With regard to cost (and saying this does not sit well with me) I believe even AB would be competitive when comparing the equivalent apples for apples. The SLC500 product range would be
of a similar price to a computer populated with the same I/O and comms configuration.

With regard to electricians not being able to fix the "... more complicated bits" are we talking H/W or S/W. If hardware then I would suggest replacing your electricians, if S/W then the normal (average, etc) electrician will probably have no PC programming skills or very little to support the complex structure of a control
program, especially if it is multitasking. At least with ladder logic (yuk) they have a chance. Yes ladder logic has gone beyond the normal relay structure, but the sites I support use the electricians to do slight code modifications (under instruction) and to troubleshoot, not to write new code. If there is a section of code
that may be complex then proper documentation will assist greatly. I feel if the average sparky knowledgeable with PLCs cannot understand my code then it is my fault - not theirs.

Finally, I am not familiar enough with LINUX, QNX, UNIX to comment, however, I am familiar enough with NT and 9x to know I do not even rely on them totally for HMI applications. I program to
allow the operator to feel comfortable when they are "blind" because of another 'feature' coming to light from M$ needing a reboot - even with NT.

For all its worth, that is my 2c.

Cheers
Allan Dow
Embedded Systems & Solutions
 
Curt,

I do agree with you about the hardware aspect. In theory, there is nothing wrong with using a PC instead of a PLC. However, the software aspect is
still unproven with respect to PC's.

The big problem I see with respect to LabVIEW (whether for Win x, Linux, or Unix) is that the vi's are complex subroutines. When you wire vi's together you can't predict whether there will be a bug or logic problem that will rear it's ugly head. Once you do have a problem, you can only debug the vi's you created. The vi's provided in LabVIEW have no source code to analyze.
Therefore, you would have to find a workaround in order to get the program functioning correctly. This can be the time consuming part w.r.t. LabVIEW, and can test your graphical programming skills.

On the plant floor, no one can afford to have a process down while the engineering staff (or engineering consultants) try to figure out which wire paths or vi's are preventing the system from working. I have seen one case where a motor controlled by LabVIEW RT, started to hunt without any input signal to the board. The programming error was difficult to find for even the contractor's best programmer.

LabVIEW can save both time and money when used in test or research environments. Provided your only desire is to quickly paste together a tailor-made program without having to code from scratch. In a plant environment, most companies can't afford to play around with unproven systems. In my opinion, this is why PLC's still rule. I would have to agree with Allen's statement "don't use a screwdriver to hammer nails, right tools for the right job."

John
 
C
No, the customer and contractors are kinda touchy on this but, that's the jist of it. This may be unusual, but we are integrating machine tools
with PLC's from the same manufacturer as the nc controllers and robots and there are no protocols shared by even two of the three. We end up using rs232, ascii modules, and bcd hardwired IO to
communicate. We want a fieldbus to tie all the cells together, but can't find common ground there either. Many comm modules arrive DOA or at best require vendor support to bring them up due to poor or incorrect documentation. We have had to invent our own protos for the machine tools. The easiest thing to integrate was our Linux based machine vision because we wrote that and can adapt to the bugs and idiosyncracies on the other end of the cable. Fortunately, we have the talent available to do this, but, isn't this supposed to be simple? If I'm kinda hardcore on the open protocols and interoperability points, it's not just rhetoric, this makes the integrator look bad and accomplishing heroics for a customer who's still unhappy about cost and time is most tedious. If the vendors started now with the best of intentions, it would take years to sort out this tower of Babel. The worst part is that starting with all new equipment isn't all that
much better and the vendors don't give a damn. Today they pay lip service to "open" and even straight up lie about it, simply declaring their existing stuff to be open with no other change. They obviously know people want it, they want to say it, but not do it. None of this is a problem I guess, unless you _need_ to interoperate.

Regards

Curt Wuollet
 
C

Curt Wuollet

Curt Wuollet <[email protected]>

> From: [email protected]
>
> Hi Curt
>
> You make some valid points and some questionable points.
>
> I am not a regular contributor but when I do contribute it is normal
> a rebuke for Rockwell Automation's products. However, even with the
> problems I have with AB products it is still a no brainer on whether
> I would use their PLCs over a computer based system. We all speak
> from experience and all have our favorite stories, both good and
> bad. So there is always going to be contention in this matter.
>
> Again however, sound engineering testing will go a long way to
> substantiate claims made by individuals. Your statement "I did an
> analysis recently on how well the stated advantages of PLC's held up
> in practice." is an important one since this is the type of
> information that the list would like to see to remove some of the
> subjectiveness and replace it with objectiveness.

This is not an objective study, I prefaced it with "in our situation" but most of the bugs we have seen are in the communications protocols and even in the hardware. We do unusual things like talk to robots and machine tools and PC's. I don't think any of the interfaces is operating as documented.

> So here is your chance to substantiate your claims with solid
> evidence, I for one would be extremely grateful to see what bugs a
> PLCS had when compared to a PC.

Today's example is a hard limit of 20 tables as opposed to a spec of 100 on a GE 90/30 running State Language. half a day of rework. I'd need to dig for specifics from previous episodes. And
yes, we reported it.

> With regard to cost (and saying this does not sit well with me) I
> believe even AB would be competitive when comparing the equivalent
> apples for apples. The SLC500 product range would be of a similar
> price to a computer populated with the same I/O and comms
> configuration.

Ok Controller with all needed software and 12 dc in 12 dc out, Ethernet attached, remote $1040.00 with 8 additional rs232 ports for lathe, vision, etc. The next one will be a little higher because the rackmount cases are going up. We do assemble our own but would do better commercially if we could find someone who would build to order. This includes a monitor which we could reasonably do without. The software is RedHat Linux 6.2 and the Linux PLC. RHLinux is $1.98 from cheapbytes and the Linux PLC is free from
www.linuxplc.org or ask and I'll mail you a copy. It's very basic right now but the price will remain the same as it gets better.

> With regard to electricians not being able to fix the "... more
> complicated bits" are we talking H/W or S/W. If hardware then I
> would suggest replacing your electricians, if S/W then the normal
> (average, etc) electrician will probably have no PC programming
> skills or very little to support the complex structure of a control
> program, especially if it is multitasking. At least with ladder
> logic (yuk) they have a chance. Yes ladder logic has gone beyond the
> normal relay structure, but the sites I support use the electricians
> to do slight code modifications (under instruction) and to
> troubleshoot, not to write new code. If there is a section of code
> that may be complex then proper documentation will assist greatly. I
> feel if the average sparky knowledgeable with PLCs cannot understand
> my code then it is my fault - not theirs.

But it is not the advantage it is sold as.

> Finally, I am not familiar enough with LINUX, QNX, UNIX to
> comment, however, I am familiar enough with NT and 9x to know I do
> not even rely on them totally for HMI applications. I program to
> allow the operator to feel comfortable when they are "blind" because
> of another 'feature' coming to light from M$ needing a reboot - even
> with NT.

You should take your Linux machine down at least once a year and blow out the power supply and check all the fans. An SBC would be even better but they are kinda spendy.
 
Good Morning All

Again Curt you make some interesting comments, most of which I agree with. For example anyone who dabbles with PLCs will know the problems encountered in getting two devices to talk, even from the same company "Oh I'm sorry sir, you need our 'special' XYZ cable that only costs 10 times its real value, plus a firmware upgrade".

Aren't you glad that PCs always interface perfectly first time every time :) :)

But again here is your chance to gain a convert - could you please enlighten me on how using a PC based system you where able to circumvent all these interfacing issues. You alluded to the point that you where able to modify your code to interface to this shambles. You are most fortunate to have the source code available to do
this. Do you provide your proprietary (IP) code to the client at the end of the day for no cost so that they may continue to reap these benefits, or do you keep it close to your chest. I am sure that if the "source code" was provided for the other equipment the same result could occur. The unfortunate reality is that very little source
code is generally available to allow such a practice to happen. You make mention of using an ASCII module, probably a bit basic (excuse the pun) but most companies now provide co-processor
interfaces that accommodate such desires. I used a SLC500 basic module years ago to write a PG7 pager protocol to allow my client to alert their operators of problems via pagers, it is really not that difficult.

You state that your client is a bit touchy, why not just call them Mr Smith :), surely referencing equipment types and idiosyncrasies
would not be breaching confidentiality. I would think that you client would be grateful to have such info made available so that others will not fall into the same trap. The suppliers would quickly have to clean up their act if integrators publically broadcast the problems encountered so that other could understand the bigger picture
outside of the glossies presented by the sales "engineer". The information you appear to have could be quite valuable from a learning point of view.

Finally, I am amazed that products were chosen without consideration to interfacing to start with (as a part of the whole picture). Maybe the lesson to be learnt is layout out the panels
before you start cutting. In case you haven't noticed, one of my hobbies is woodwork - its amazing what you can learn from the "old" trades.

Cheers
Allan Dow
Embedded Systems & Solutions
 
C

Curt Wuollet

Hi John

Couldn't agree with you more on closed source proprietary solutions. I would add that you are kinda in the same boat with proprietary PLC's
and their programming software. The part that you write is accessable, but, the other half or more of the picture is secret and impossible to audit, inspect or fix. That part of the picture could certainly use some peer review and debugging. Instead, when something doesn't work as advertised or crashes, people just find a work around or assume they are doing something wrong. There is a lot of discussion on the list about PC hardware that doesn't work or is unreliable. Having a Linux shop is a great revelation on the reliability of the hardware. I am using a lot of "unreliable" Windows castoffs around the place here. They were replaced because they would crash too frequently or would scribble on the hard drive or other expensive and annoying tendencies.
A few were simply too slow after an upgrade or had driver problems. One had a bad motherboard, but the rest were miraculously healed by installing Service Pack 6.X from RedHat (RedHat Linux Ver. 6.X). It was good while it lasted, our parent company has now converted to Linux and the stream has dried up. It's gonna be kinda lean around here. Fortunately, W2k is now out and I should be able to get used machines that are fine for Linux for a song as the waves of upgrades
deplete IS budgets across the nation. It's humorously ironic that the MS upgrade merry go round is fueling the Linux revolution. I've got a
lot of reliable compute power for almost nothing. I've been toying with the idea of building a free Beowulf supercomputer. The PC hardware vendors are really getting a bad wrap. Try a RedHat "repair".

Regards
 
C

Curt Wuollet

> Again Curt you make some interesting comments, most of which I
> agree with. For example anyone who dabbles with PLCs will know
> the problems encountered in getting two devices to talk, even from
> the same company "Oh I'm sorry sir, you need our 'special' XYZ cable
> that only costs 10 times its real value, plus a firmware upgrade".
>
> Aren't you glad that PCs always interface perfectly first time every
> time :) :)

They don't, but I sure am glad that I can do something about it.
Getting anyone to change the closed stuff is nearly impossible
unless you're GM or ATT. Closed products on the PC are a
problem also. Having one end open at least lets you build a
working interface. If both ends are open you simply use the
open protocol tha meets your needs Both ends closed is
either possible or not and there's not much you can do.

> But again here is your chance to gain a convert - could you please
> enlighten me on how using a PC based system you where able to
> circumvent all these interfacing issues. You alluded to the point
> that you where able to modify your code to interface to this
> shambles. You are most fortunate to have the source code available
> to do this.

Yes, I am fortunate but, it's not a matter of luck. I develop on Linux specifically for the enormous advantage having the source gives me.
Because of it's excellent and accessable support for Ethernet, serial communications, appletalk, SMB, IPX/SPX, arcnet, and more, it is ideally suited as a toolbox to solve these problems.
Nothing else that I know of gives you as many tools to work with, free and open. Note that this requires no cooperation or source code from the vendors. I have found them to be less than helpful
anyways Their attitude is either that you simply can't do it or all requests must be written on a piece of money. Most often we simply don't have time or inclination to kiss their respective *sses. As a customer I don't feel that I ahould have to. They, unfortunately feel I should.

> Do you provide your proprietary (IP) code to the client at the
> end of the day for no cost so that they may continue to reap these
> benefits, or do you keep it close to your chest.

I follow this standard policy: If they paid me to develop it, it's theirs. If it's likely to be useful for my toolbox, I donate the time and GPL it. If they agree to release the stuff they paid me to do we do that. When they see the value they recieve from Linux for free, many are open to releasing code not specific to their company.
Quite often it is of no interest or use to others that don't have that particular problem and the point is moot. I sell the knowlege not the code.

> I am sure that if
> the "source code" was provided for the other equipment the same
> result could occur.

Of course and it would be a great step forward in interoperability even if it's not free.

> The unfortunate reality is that very little source
> code is generally available to allow such a practice to happen. You
> make mention of using an ASCII module, probably a bit basic

Actually it's a horriffic and expensive kludge

> (excuse the pun) but most companies now provide co-processor
> interfaces that accommodate such desires.

Usually for twice the price of a Linux box plus software and a learning curve. And you can still only do what they decide to let you do.

> I used a SLC500 basic module years ago to write a PG7 pager
> protocol to allow my client to alert their operators of problems
> via pagers, it is really not that difficult.

If and only if they will provide the necessary information. With a datascope you can usually get enough info to do what you need to do for serial comms.

> You state that your client is a bit touchy, why not just call them
> Mr Smith :)

They are touchy about the time and effort expended on problems that should not exist.

> , surely referencing equipment types and idiosyncrasies
> would not be breaching confidentiality. I would think that you
> client would be grateful to have such info made available so that
> others will not fall into the same trap. The suppliers would quickly
> have to clean up their act if integrators publically broadcast the
> problems encountered so that other could understand the bigger
> picture outside of the glossies presented by the sales "engineer".

Yeah, sure, I've noticed the concern. Actually, if you read my past posts I've named names. They are becoming irrelevent to strategy going forward. I am being charitable because they have shown some more encouraging trends lately and I want to evaluate them in good faith. From what I've seen, they are not unique in their attitude towards interoperability, this is an industry problem.

> The information you appear to have could be
> quite valuable from a learning point of view.
>
> Finally, I am amazed that products were chosen without
> consideration to interfacing to start with (as a part of the whole
> picture).

Yes, it's amazing that a customer actually wants you to make the stuff they already own work together. What a ridiculous notion, doing what the customer wants or what's good for the customer. The big companies would never even think of that. That is the crux of the whole sorry mess. You are supposed to do what's best for
the vendor.

> Maybe the lesson to be learnt is layout out the panels
> before you start cutting. In case you haven't noticed, one of my
> hobbies is woodwork - its amazing what you can learn from the "old"
> trades.

I'm sorry, you can't patronise the truth away. It is a reasonable expectation that it should be possible to make things work together without buying all new equipment, from only one vendor.
 
Top