LabVIEW
How much is too much for Labview ?
Overall I see no problems to write a LabVIEW application that could do it. Principally I would even consider going with cRIO for this. Not so much for real-time capabilities (your requirements don't really seem to mandate that, but for the benefit of rugged hardware that can be put near the setup in an E-cabinet). However if suddenly your client asks for some tight control loop, everything is already there.
But some of the architectural points make me believe that you never wrote such a system before.
- I used to be a fan of Functional Globals but the thing with them is that they TOTALLY do not scale!
"Ohh I would like to have a second subsystem just like the one we already have, can't be complicated to add that as all the code is already written and you just have to duplicate it."
"Sorry it's not so easy, this uses a Functional Global (or two or three...) that can't just simply be copied to duplicate the functionality!"
- Don't do Tolkien! "A single state machine to rule them all" is an architectural fiasco waiting. A state machine with 150 or so states? A nightmare in coming! You don't have to do Actor Framework, I would not recommend it unless you want to fully embark on that path, but something in the style of multiple message based state machines is definitely a good thing. You can build your own or take a short cut by using DQMH or similar. They are very capable but not quite as complicated to get started with as the Actor Framework.
You want one state machine per functionality and let them communicate with each other when needed and for the rest each is running on its own and simply doing one thing as perfect as possible, rather than umpteen things in a mediocre way. This also helps de-serialize everything. You do not want to have your data logging or alarm handling being blocked because a serial device is slow in responding.
@MogaRaghu wrote:- I am sure all of above is very much within LV capability in a single project and does not get into limiting areas to slowdown ?
It's challenging enough to think well about how to make it. I'm sure it can be done (well), but I also know for sure you can make this in a way it won't work, or with a continuous 90% CPU load.
@MogaRaghu wrote:- Functional Globals - How reliable are they as I am planning to rely on them for all data sharing between main and sub vis ?
FGV are 100% reliable. They always do what they are supposed to do, good and bad.
The mentioned scaling is a problem, as with any global resource. The problem is a global resource is global...
You could add indexing to a FGV. That's a great way to loose all changes of parallel execution. A FGV is a great way to force sequential execution.
If you for instance store large data in a FGV, and you want to perform a timely operation on that data. You will have to choose to either get the data from the FGV (an expensive data copy) or to let the FGV execute the operation, blocking all other operations until it's done.
Data by wire is simply the best way to use LabVIEW (scalars, arrays, classes, clusters).
References by wire are next (unnamed queues, DVRs, control references).
Global resources are least preferred (Globals, FGV, named queues). There are some grey areas, a private global (or FGV) is much better then a plain global. A named queue can be passed by reference, and is a global resource.
The moment you go from data by wire to references or Globals, you complicate testing (because there's external state) and run the risk of race conditions.
Grokking Simplicity: Taming complex software with functional thinking: Normand, Eric (Amazon) is about functional programming, but applies to any kind of programming
@MogaRaghu wrote:- On the SUB VIs - Is it OK to have one large SUB VI for all four stations and run four distinct State Machines in one common While Loop ( or ) have independent SUB VI for each station and call as required.
I'd have 4 instantiations of the same (reentrant!) VI. Make data control the behave (SM1, SM2, ...). OO works really well for this, as classes (data) can very conveniently change behavior by both it's private data, and\or polymorphism.
One loop managing an array of 4 state machine's data could work, but it's much more complex than needed. Maybe if the 4 SM need to be in the same state at all times, but then you'd basically have 1 SM with 4 sets of data.
4 SubVIs with modified copies would be terrible. I think you didn't mean that ("independent SUB VI for each station "), but to be sure: don't do that. There's never a good reason to copy code and use it.
Search LabVIEW like a graph! 
The requirements don't sound very harsch, your system will handle it.
I agree with Wiebe, make 1 station work and then create 4 instances of it!
Since they're sharing hardware i'd probably make some parallell sample-process which you can get/set channels from with queues or events.
As mentioned, FGVs do exactly what they're supposed to, but not always what you want them to, they scale bad and it's easy to create race conditions. What are you planning to use FGVs for? Maybe it's easy to integrate into the sample engine or have some Administrator function/class.
@MogaRaghu wrote:
This is a general query to estimate the suitability of LV for a machine control / data logging application.
I do not trust Windows for machine control, especially if safety is remotely a concern. As soon as "control" enters the conversation, I'm looking at a cRIO. And when safety comes into play, I'm looking at the FPGA on the cRIO for at least part of the IO control.
