evaluating LabVIEW suitability for industrial machinery control

[RSalsgiver]

Greetings,

I am trying to determine whether LabVIEW and associated hardware are capable of fulfilling several organizational needs - one of which is direct control of industrial machines as the primary operator interface.  Specific IO is fairly simple and not timing critical with the exception of some safety controls.  

I am trying to locate information or use case examples of where LabVIEW has been used in an auto-start configuration where the user/operator is ONLY presented with the Labview VI that acts as the machine's UI - without being allowed access to the underlying OS - whether that be *NIX or Windows.  

Most of what I have found so far seems to point toward LabVIEW providing an overall monitoring type environment, where the individual machinery control is handled using dedicated PLCs and/or HMIs.  I would like to know if LabVIEW and associated products can be used in place of traditional PLC and HMI hardware.  If not, what are some of the existing approaches to blending the environments?

If anyone has experience or pointers to information I would appreciate it.

Cheers,

Rob

[tst · Accepted solution]

We do industrial control all the time with LV. The first thing to understand is that it's a programming language like any other - what will happen is what you write. Nothing more, nothing less.

The second thing is that there is no "associated hardware". LV code can run on a number of platforms, but the actual IO modules you use could in principle be any devices which you can speak to (meaning they have dedicated drivers or support protocols you can use, like Modbus).

The third thing is that while it is possible to use a desktop OS for this (we do it regularly), these systems are not designed for this. Beyond the safety considerations you mentioned, which should be implemented in dedicated hardware anyway, you should always accept that running on a desktop OS means there's a chance things won't happen on time due to being preempted, or your machine might get stuck altogether, etc. For the systems we do, this is usually perfectly acceptable (and doesn't actually happen often), but it is something to be aware of. We usually leave the OS UI in place, but it is also possible to replace the shell application with your own application, and then you won't see the classic shell at all (although users who know what they're doing can get to it if they really want). There are various OS versions which may be more suitable for something like this, but I have no experience with that.

An obvious point to bring up is that NI does have dedicated PLC-like hardware which can run your LV code and is actually designed for this. The most obvious one is the cRIO family of devices. These work exactly like PLCs, with the exception that they are both considerably more capable and considerably more expensive.

As for blending things, the classic way is to have the code on the PLC and share information using something like Modbus, exactly like interactions with HMI systems work. LV is not an HMI program, though. It has some advantages, like being able to code and do custom things, and some disadvantages, like not being able to do the basic UIs or logging as easily. There is an add-on to LV which is supposed to add some of that, called the DSC module, but I don't really have experience with it. The decision on whether to use an HMI program or code your own (in LV or any other language) should depend on the system and the implementor.

To reiterate, LV is a programming language just like any other. You can do control apps in C, but you will need to know C and build the relevant parts. The same applies to LV - you will need to know it and to be able to write the specific code that you want. NI does have some reference designs that they released on the topic, but I never looked at them closely. You can look at the chart at the bottom of this article to see this - http://www.ni.com/example/30331/en/

[crossrulz]

I replace PLCs with cRIOs all the time.  I have also talked with PLCs using Ethernet/IP.

As far as HMIs, I know you can configure Windows to go into a kiosk mode where it only shows the running application.

[RSalsgiver]

Thanks for the input. Part of my problem is that I'm still trying to grasp the hardware choices with respect to OS choices, etc - and the capabilities (or limitations) of each.

I understand the cDAQ environtment to use Win/CE, and cRIO to use a Linux variant.  I like the >potential< to have LV be my "common interface" across several pieces of machinery and a common data collection platform / application, but as with most things the devil is in the details, and I'm trying to understand enough details to make an informed decision.

I am at the point that I need to start putting intelligence into our machines.  What form that intelligence takes is the question - traditional PLC, LV, or something else?    The question is whether LV can (cost effectively) perform that role.  "Cost effectively" has many variables though.

On one hand we can implment PLCs in individual machines and potentially use a LV app to pull/push data and operate as a data collection and/or UI point (I believe).  In this case, we have to learn PLCs and associated programming, maintain separate source and program control, separate IO tools, knowledge, etc, etc.  Those all have costs as well.  If we use LV as a monitoring or data collection tool, we have that learning curve and all associated costs ON TOP of all of the PLC stuff.

If on the otherhand LV CAN do it all - even at a modestly higher "equipment" cost, then at least everything is under the same umbrella and we save one layer of complexity, learning, tools, and potentially different hardware.

Not sure if that makes sense, but it somewhat feels like I'm trying to find my way in the dark <g>.  Any more help is definitely appreciated.

Cheers,

Rob

[tst]

Again, this can certainly be done with LV and there are certain advantages LV has over PLCs (for instance, you can run LV code on an FPGA in the cRIO, which can be critical for certain applications). The question isn't whether LV can do it, but whether or not you can get someone who can do it (since they will need to know LV and they will need to know how to build the relevant application properly) and whether it's worth it in terms of costs and complexity and that depends on your specific situation.

Your desire for clarity definitely makes sense, but here's the problem - If I was doing it, I probably would do the whole thing in LV, but I have a certain background which makes that easy. I know I probably wouldn't give concrete replies to any client who approached me with the same question without hearing more details about their situation. I would suggest that you try to find a local consultant or contractor who has experience in this area and can hear the exact details of your situation and help with advice and/or planning and/or code. I assume your local NI branch has people who know both what NI has to offer and the relevant players in your area.

To draw a bad comparison, if someone asked me "I want to start operating on the neighborhood cats and I'm trying to decide whether I should use a scalpel or a laser scalpel" I would probably tell them that the question they're asking is too generic and if they don't already know the answer they should probably either get a professional to help them design their operating room or they should learn about the topic enough so they feel comfortable answering the question. I do realize how such a response can seem disappointing/condescending. It's not intended to be.

[PatrickLye · Accepted solution]

I’ve been changing a glass factory over to LabVIEW for years. I have been replacing old systems for a long time, and haven’t interfaced with any of the legacy systems yet. I would much rather get rid of the old junk whenever I can. I was ready to abandon ladder logic the first hour that I used LabVIEW.

I find that running things from a LabVIEW PC is fine if:

1. No safety features, which are required to be hard wired and/or on safety certified gear anyway.
2. I won’t run any actuators that could even get close to hurting a person.
3. The computer needs to have good enough specs, I currently buy new i7 systems with 32 gb on computers that will run other programs or are resource intensive, and at least 16 gb on systems that won’t run other programs. I tend to look at my performance monitor, and when the system is getting above 30% usage it makes me nervous. It is too easy for things not to happen when they need to above this level. For some systems I’m actually running nice Dell server grade hardware. This was initially set up as a redundant pair of OPC servers, which I’m considering abandoning for direct Modbus control of some Automation Direct Field I/O. Then these servers would be repurposed. One for my MS SQL server and the other for my Master Controller program which monitors a lot of items in the factory.
4. Always get rid of any factory bloatware off of the PC.
5. Don’t allow any RDP to the computer running any critical programs. ( I would really like to find an alternative for this feature, but I don’t have time to look into it… )
6. Run automated reconnection in state machines for external cDAQ or other field devices whenever possible.

We do a lot of temperature control here, and I have no issue with running heat on/off or analog output levels to drive items like this from a PC. Beacons, Alarms, and other items that can’t hurt anyone are also fine on a PC.

***I always spec out cRIO for anything that could conceivably hurt someone.***

On the systems that will only be running my LabVIEW program I kill access to the desktop without an access code, disable alt ctrl del, disable the charms bar, disable the windows keys, and on the next system I set up I want to try the booting directly into the program instead of Windows. There is always a way for someone with talent to get around things, but I’ve found this works out pretty well. The only time I’ve run into a problem is when I didn’t uncheck the correct values on my main.vi before compiling and building the installer. It is easy enough to go back, uncheck what I needed to, and repeat the process to lock people out like it needs to be.

There are some PC systems that I’ve set up to monitor the factory and alarm when certain alarm conditions show up in the MS SQL database. These PCs all run other programs so I had to lock the specific program to keep MOST users from shutting off the program.

I really love the ease of interfacing NI software and hardware to the modern world such as databases, email, web browser, etc…

With my current programs I’ve set it up so that users can select an alarm and go directly to my website. I have this bridged for access to both the office network and the industrial network. I’ve tried writing manuals to help the guys, but they won’t read them, with one exception. Doing help on a website allows people to access the help they need for a specific item so that they don’t have to dig through pages of a manual, which most of them won’t do anyway. It’s easier for them to just call for help…

One nice thing about using a website for help is that it is easy for me to update the help files as needed without recoding anything. It is amazing how often I think of something helpful, add it in quickly, and it is all backed up as needed.

A new item that I’m rolling out is a common events table for the entire factory. Any computer can view the events and drill down by system, event type, etc… The second stage of this is to start gathering the things that fixed problems by emailing the correct people when certain events happen to get their input on the issue, what actually fixed the problem, etc…

I find that with the power of LabVIEW I try and achieve things that I never would have considered in AB or Siemens PLC systems. Now, both have many features, but the companies I worked for would never spring for the thousands and thousands of dollars needed to buy it all.

I’ve also found that the DBAdmin, who won’t touch anything except Access, and is a pretty slow to learn anything about MS SQL, can easily read info from or send data to my system easily through a database table using LabVIEW when the owner wants him to, but it is still easier for me to just write a client for what is needed since it doesn’t take a lot of meetings before anyone can start work on something.

There are Pros and Cons about being the only programmer at a facility, but with LabVIEW I can get a lot more done than used to be possible with Assembly, ladder, C++, Visual Basic.net, Automation basic, and some even more arcane tools.

I’ve only been using Windows systems, as some people, not me, are anti-MAC and anti-Linux.

So LabVIEW and NI products 9 stars out of 10, since nothing is perfect..

[johnsold]

I agree with the advice given by tst. To put his precautionary remarks into a different perspective think about the consequences of a failure of the system you put together based on the advice you received on the Forums. When you go to your boss or the insurance company's lawyer, how will it sound if you say "Well, I did not really understand it completely but some guy on the Interset said it would work."? 

I trust tst's advice. This  is not critical of that at all.  As he did, I avoid making specific suggestions about systems where I do not have sufficient knowledge of the detailed requirements and conditions to do so safely.

Lynn

[RSalsgiver]

Thanks again for the info, and to johnsold for the concurrence.

I fully realize that getting into any solution will require resources - either learned in-house, contracted, or some combination of both.  This is true whether going to PLCs, LV, a combination approach, or something totally different.  

The goal in asking the question was to get a better "warm fuzzy" as to >whether< it could be done in LV, and to some extent develop an understanding of the "hands on" limitations of given hardware selections (cDAQ/Win, cRIO, etc).  I at least know now that it CAN be done, which was step 1 of the journey.  HOW to best do it requires a much more in depth discussion - either with folks like you, contractor/consultants, or LV folks directly.  

We've been in initial discussions with a LV partner but some of the answers have been slow in coming.  This is not a slam by any means on LV or it's reps.  I imagine they have quite a few irons in the fire to keep up on.  That said, you've filled in some of the gaps in questions I've asked of the sales channel and not heard back on yet.  Hopefully when the get to it I'll have even more of the picture filled in.

Now that I have a higher percentage assurance that it CAN be done, I can start to focus more on the HOW.

One more question specific to the cRIO.  Does the cRIO architecture give me the ability to boot entirely into a VI and prevent user access to the underlying OS?

Cheers,

Rob

[crossrulz]

---

@RSalsgiver wrote:

One more question specific to the cRIO.  Does the cRIO architecture give me the ability to boot entirely into a VI and prevent user access to the underlying OS?

---

The cRIO architecture is a Real-Time OS with an FPGA for accessing the IO.  When the RT boots up, it loads a LabVIEW executable immediately.  There is nothing else to get to.  And the FPGA is actual hardware, so there is definately nothing extra happening in there.

It is recommended that you have a seperate PC (I have seen Windows Embedded and full up Windows used) to be your HMI and communicate with the cRIO over an Ethernet connection.  If you really want to dive into it, have a look at the NI LabVIEW for CompactRIO Developer's Guide.  I know there are ways to lock out things in Windows.

[tst]

cRIOs run a real-time OS (in current versions it's a flavor of Linux). As such, there is no UI for the user to see and no OS to access. It's basically a headless system which is designed to run on its own and you can certainly configure it to load your compiled EXE of choice on boot.

If you want a UI to interact with the program running on the cRIO there are any number of options, from the standard interacting with "registers" you get with PLCs (the quote is because it doesn't have registers, although there is some kind of built in option to map things to Modbus) to connecting to a VI running on it to running a web server serving web pages to sharing data through some custom things which allow you to configure UIs which will sync with them on Android/iOS devices. It's all a matter of configuration, code and balancing.