Re: what are the limitations of using labview 8.5.1 developers suite verses a real-time module in field point applications?

[centerbolt]

You will need LabView Real Time to create code for a cFP.  This could be a stand alone copy or it could be part of a developer system.  Once the vi has been written and tested, an .exe can be created and embedded on the cFP.  At this point the cFP can operate independently.  
 
While it is very easy to create a host vi to control a cFP, it is not required. 

[norka]

I have gotten a number of different answers to this question. I have been told by one NI rep. that I can load a LabView 8.5.1 Developers Suite exe. on the cFP. Another strategy maybe to run the cFP program on a PC attached to a cFP via ethernet. I have been looking for guidance on NI's website, but there appears to be no clear and concise discussion of how a cFP is programmed or if there are options. My question concerns the need to spend an additional $3k or more on another LV software package when we already have LV 8.5.1.
Thanks for your response. I always seem to encounter problems using NI's website, for it appears to be written by experts for reading by other experts. Thanks again!

[centerbolt]

I've deployed 6 cFP systems to date and last I knew, it was still necessary to have the Real-Time Module loaded in order to create and deploy .exe's to cFP.  I don't think you can even load the cFP drivers and libraries until the RT module is installed.
I'll admit that the things seem a bit muddy on the front end.  Can I ask what kind of application you have for cFP?Message Edited by centerbolt on 07-22-2008 03:55 PM

[StevenA]

centerbolt is correct, you can't load a .exe or even run a program on the fieldPoint controller unless you have the Real Time module.  However, that does not mean you can't use your FieldPoint bank without the Real Time module. 
 
From LabVIEW for windows you can make calls to the fieldpoint IO using the fieldpoint read/write functions. 
<img src="http://forums.ni.com/attachments/ni/110/7638/1/fp%20pallet.PNG">
This program runs on the PC not the FieldPoint controller.&nbsp; If you loose network connection to the fieldpoint, your program will loose connection to the IO.&nbsp; For many data logging applications this type of arrangement can work just fine.&nbsp; However, if this is the only type of application you are ever going to run, then you may as well not buy the <a href="http://sine.ni.com/nips/cds/view/p/lang/en/nid/204804" target="_blank">Real Time controller </a>for your fieldpoint but the <a href="http://sine.ni.com/nips/cds/view/p/lang/en/nid/202209" target="_blank">network controller </a>only.&nbsp;
&nbsp;
If your application requires more reliability, and/or greater determinism than can be achieved by running a program on windows, then you should use the LabVIEW Real Time module and develop a program that can run down on the FieldPoint controller independent of windows.
&nbsp;
&nbsp;Message Edited by StevenA on 07-22-2008 04:14 PM

fp pallet.PNG:
http://forums.ni.com/attachments/ni/110/7638/1/fp pallet.PNG

[redtile]

CENTERBOLT, I have found some items buried in the NI maze of information which supports your comments. I am upgrading four test stands which require PID control of RPM and applied force. Also, a count of revolutions, temperature, RPM, and other attributes is required. Typical control circuits which affect power, start, stop, etc are needed also. I have concerns about accomplishing PID control over an ethernet buss between a PC and a cFP controller. We have recently been successful in controlling four test stations employing a PXI and straight LV 8.5.1 programming. This latter system is far more complex and demanding than the former under consideration.&nbsp; We had no significant WINDOWS OS problems. I am not familiar with the term "determinism" used in the context of a Real-Time controller. I have some idea of what it might mean, but can not reduce it down to the level of how it affects my application and NI's cFP information just assumes the reader knows what they are talking about.
I have looked at various cFP modules and understand some of their speed and resolution and bandwidth limitations as compared to what I have been using in my earlier PXI system. I think I can work with the cFP modules available. But, it begins to appear as if the whole concept of cFP relies on a significant software upgrade of an additional costly software module and whatever else I am not aware of yet such as installation fees and R-T toolkits. I understand that if I just want to monitor cFP module outputs and change inputs on a very slow time scale, then I can use a PC with LV 8.5.1 and a non-R-T cFP controller. All of this drives me back to using LV exe. programming and 5B modules and SSR switches along with a large number of cables and attendant interconnections. I would really like to drastically reduce the cabling needed to implement the 5B module approach and go to ethernet, but it appears that the cost impact is very significant.

[AnalogKid2DigitalMan]

Any chance of a hybrid combination? Use dedicted off-the-shelf stand-alone PID controllers for loop control and use (c)Fieldpoint for the other I/O functions?
Just a thought.
-AK2DM

[redtile]

StevenA,
Thanks for the definition. I had looked in a dictionary and the definition was couched in terms of a philosophical theory...it began to sound like quantum mechanics. I get it now. I found some more "knowledge papers" which added to my understanding. I even found a slide show on R-T Timed Loops&nbsp;which has enough volume to be heard.
Just one more point of understanding; I gather that a R-T module on a PC would allow deterministic timed loops to drive multiple cFP units via ethernet connections or a R-T program could be loaded onto a cFP controller which could also run other properly configured cFP controllers/modules without a PC. One advantage would be removing the PC from the actual running of the program; it would then act as a monitor for data queries and a possible location for data downloads. But, some cost could be saved if an embedded R-T controller could be replaced by an ethernet expansion I/O backplane.

[centerbolt]

redtile,
The catch is that ethernet is not deterministic.