Why should I prefer NI Compact FieldPoint to Siemens S7-400 PLCs?

[kasra]

NI guys please answer:

Why should I prefer NI Compact FieldPoint controllers to Siemens S7-400 PLCs to build an automation and monitoring systems for a factory?
I am asking this because one of our clients insists to use Siemens S7-400 family of PLCs to build an automation systems and we want to convince them to use NI cFP, but we need help from NI advisors to bring more satisfying reasons to our clients in order to change their mind.
The case includes 51 AI, 15 AO, 108 DI and 51 DO.
The whole process of this chemical factory must be automated and also monitored in a control room in two touch screen monitors and a big 52" LCD panel.

Any help will be appreciated from NI advisors!

[Stuart_R]

Compact FieldPoint is an example of a PAC. Take a look at the following link which should be a good starting point:

http://zone.ni.com/devzone/conceptd.nsf/webmain/bb14727c48c013ef86256f81007fb095

[tst]

As was said, Fieldpoint should be able to do more complex work.

It is programmed using LabVIEW, not ladder diagram, which is good for complex applications, but requires that you understand LV and LV real-time to avoid making mistakes.

It has built in support for ethernet (I don't know what the Siemens ones are like).

One problem with cFP is that you will probably need 2 cFPs (maybe even more) for your application because the rack only supports up to 8 modules. I don't know what the Siemens one are like in this case either.

If you were planning on using a custom program for you interface, it will be much faster and easier to talk to the cFP controllers from LV than it would be if you were using OPC.

One of the problems with LabVIEW in this respect is that it is not an HMI program - getting it to do nice animations and things like that is not very easy and requires some good understanding of LV.

[kasra]

We have a professional team of LabVIEW programmers and we don't have any problem either to understand LabVIEW concepts or to build high graphical and user friendly HMI softwares and I already know what are the benefits of programming with LabVIEW for the programmers. My problem is to convince the customer to pay the extra money for NI Compact FieldPoint controllers instead of Siemens S7 series PLCs or other lower cost PLCs from other manufacturers. The customer doesn't care if we write the language with LabVIEW or Ladder or anything else...
Two things are important for the customer:
1-Quality
2-Cost
Now I have a question from National Instruments guys: How Can I convince my customer to accept my solution of NI cFP devices which are PACs instead of PLCs (And I already have read that document on the NI's website about comparison between PACs and PLCs, but it didn't completely work for me).

And yes the Siemens PLCs support Ethernet and other communication protocols such as ModBus, PROFIBUS etc...

And I thought that, we don't need to use more than one controller in case of using more IO modules than one. Because NI has an Etherent communication backplane of 8 slot which connects to the original 8 slot backplane of one controller and expands it to 16 and using more of them expands IOs to virtually infinite!
Please look at NI cFP-1808 and tell me if I am wrong.
http://sine.ni.com/nips/cds/view/p/lang/en/nid/202210

[tst]

The cFP-1808 is a new product, so we haven't tried it yet. If it does allow you to "add" backplates to a cFP controller, that would be very nice as it is cheaper (although you still have to pay 15$ if you want the small piece of plastic that covers the spare terminals).

If the system is complex, then writing the code in LV should be much faster than writing it in ladder logic. This means less programmer hours and a certain decrease in price. It would also mean it should be potentially easier to upgrade and port the code in the future because you can simply take it and run it on other targets (like a real time OS PC). This can be presented to the customer.

As for quality, we have encountered numerous problems both with FP and with cFP, but I'm not sure how many of these are a problem with FP specifically (as opposed to the area where the controller was), and you can look at this board to see whether people are complaining or not. In general cFPs with proper RT code should be stable.

[kasra]

NI in their website in the Solutions section, say that some real big companies in the oil and gas fields such as Shell etc... and some other very crucial industries such as nuclear reactors and etc... are using NI cFP based monitoring and control systems. So, is it possible that in such crucial and very sophisticated control systems a Compact FiledPoint fails?
Please give me some examples of your problems with cFP systems, it is so interesting for me!

[tst]

I trust that if these people say they managed to run their systems without problems, then they did.
If you look at the messages in the board, you can see different types of complaints, like faulty readings and malfunctioning hardware. Since I know NI makes good hardware, I tend to believe these are the execptions rather than the rule.

Personally, we ran into problems with cFP where an analog card occasionally stops sending its data to the controller. I believe the diagnostics (basically replacing everything) showed that this was caused by the electric equipment where the cFP was, but I don't think we ever got it solved. I assume that in a more electronically isolated environment such a problem should not occur.
Additionally, I remember seeing instances where a controller (a FP) would simply stop responding and would have to be rebooted (this may have been a bug in our program where we were eating up the memory, but I never did check it, so I don't know).
I also remember problems with opening a TCP connection to the module, where LV would accept the connection opening (Open returned without errors), but would not send or recieve any data. I'm not sure this was a problem with FP, though, because I'm pretty sure I've tested this and seen it between 2 PCs as well. I've never been able to recreate it.

All in all, not a great number of problems, and like I said, I assume these are the exceptions.

additional advantages of using LV include a shorter time-to-market (because of the reduced development time) and the ability to analyze the data and transfer it to the factory's data processing tools.

[Jaime Rodriguez]

How about remote monitoring of your embedded applications? This usually helps with customers who dont really know CFP. Traditional SCADA HMI packages ten to be really expensive!! So if you could do the same type of monitoring application with less $$$, that should do it. Simply through a nice front panel and Internet Explorer they can actually access the live data being acquiered in the process.

Hope this helps out. The problems I have had with CFP have been due to the controller placed in a very noisy environment, (motors, pumps, etc.) and it created a lot of EMI. It was solved by isolating the controller from this area.

Good luck.

[Software_Monkey]

Hi,

I work in the nuclear industry and vendors often claim that their equipment is "used in the nuclear industry". While these claims are usually true, the equipment tends to be used for the more menial tasks and would not be used in safety critical applications unless it was designed and manufactured to very stringent standards such as IEC 61508.

[dj143]

For what it's worth, I'd like to make a comment.  It's difficult to compare the various PLC vendors with the NI line of products such as cFP because everyone has their various perceptions.  In short for me, the NI products are far easier to program than typical PLC's because of the much greater flexibilty and the rich features found in the LabVIEW programming environment.  I've programmed several PLC projects over the years that include GE Fanuc, Allen-Bradely, Omron and Siemens (Including the S7-400 series)  I'll take the LabVIEW environment any day over miserable ladder logic and the other versions such as instruction lists.  The customer gets a better product when it is easier to program and test.  I often provide features for the customer using LabVIEW and cFP that I would never think of doing using ladder logic.  The bottom line is that it's too easy to compare hardware without consideration of the software or benefits of features available.

And then there are the customer's perceptions.  Just the other day I met with a potential customer who hates Siemens with a passion because he had experienced a lot hardware failures.  Conversely I have other customers who will not accept NI products only because they are not familiar with them.  For example, their technical personnel are familiar with Allen-Bradley and so that's what they want to stay with.  I have a very large international customer who has a corporate mandate to use Seimens.  It goes on...

I consider my time to be somewhat valuable, which means that I have different pricing structures that are based on what the customer wants.  When a customer requires a non-NI product, I literally double the charge for programming time.  Some jobs I win and some I lose.  However, I'm very busy in the mean time and will continue the preference of vi's over PLC programming.