LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How much is too much for Labview ?

This is a general query to estimate the suitability of LV for a machine control / data logging application. 

 

Requirement :

- Machine has 4 identical stations. ( about 10DI / 15 DO / 16 AI / 4 AO per station ) 

- Each station has a sequence of operations ( Finite State Machine architecture planned ) with something like 150 states.

- The FSM runs inside a While loop at 50ms intervals 

- There is also a display update via COM port ( 115200 baud ) but only when there is a change of any data.  And user input is via buttons on this touch  display

 

Hardware :

- Industrial PC running WiN 11 software ( no RTOS ) and with i7 Processor and 16 GB RAM

- PCIe 6323 ( 3 nos ) and PCIe 6738

 

Software :

- LV 2017 ( will upgrade to LV2023 shortly )

- A MAIN VI runs to handle all  DI/DO/AI/AO and 4 nos COM ports interface ( 50ms scan rate while loop ) 

- Each station has a SUB VI that gets all required hardware inputs via a functional global variable and sends all hardware outputs to the MAIN VI via  functional global variable. HW input and output also include the data from the Display connected via COM port. 

 

I suppose I have enlisted all key info to get an idea of what I am planning. Question is :

 

- 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 ?

- Functional Globals - How reliable are they as I am planning to rely on them for all data sharing between main and sub vis ?

- 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. 

 

Any inputs appreciated ! Thanks. 

 

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 1 of 21
(1,777 Views)

I would say $2.5k every year is too much. 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
Message 2 of 21
(1,745 Views)

but seriously, hardware timed DAQ running a 50ms control loop is not an issue. "Big sub VI" Architecture is questionable but not a limitation of LabVIEW. Also, 150 states for a FSM? that is a lot of states, have you defined all those? 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
0 Kudos
Message 3 of 21
(1,742 Views)

😀

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 4 of 21
(1,705 Views)

I have i3 processor with 8GB ram on my dev computer and run about half your requirements (regarding IO and COMs) without much problems. I do have slower loops and acquisitions though, depending on your complexity 50ms might be too fast (idk how many calculations you need to do per state) but probably not.

Message 5 of 21
(1,667 Views)

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.

Rolf Kalbermatter
My Blog
Message 6 of 21
(1,664 Views)

@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.

Message 7 of 21
(1,651 Views)

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.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 8 of 21
(1,637 Views)

I'm gonna focus on hardware.

 

4 independent stations means you can expect to make independent and simultaneous demands on your DAQ devices.  And if your AI and AO need to use a sample clock, such simultaneous access won't be allowed.

 

There are ways to code around this, but they aren't trivial and you will typically end up compromising some things along the way.  Given the kind of question you're asking, it doesn't sound like you'll be ready to tackle that level of coding.

 

It'd be much better to have dedicated hardware per independent station.  At a quick glance it appears that a single 6323 device could support all your I/O needs for a single station.  If so, just populate your PC with 4 of those and forget the dedicated AO card.  Then each independent station can own its own device and you avoid the headaches of hardware sharing.

 

Beyond hardware, I'd especially endorse Wiebe's advice to make sure you develop only 1 copy of your code, set it to be reentrant, and then run your 4 station controllers as 4 distinct instances of it.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 9 of 21
(1,604 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 10 of 21
(1,585 Views)