LabVIEW Disadvantages

[ITA]

Hi,

What could be the disadvantages of the LabVIEW to built a system that would incorporate large No. of I/O count (3000 to 4000)? What all things may go wrong with LabVIEW in terms of Performance, programming complexity, reliability etc.?

[Graziano]

Hi!
    I don't think it depends much on LabView, about performances..... maybe it's a matter of hardware.  What is the hardware you need? Are you building a PC-based system, PXI, distributed....? Do you have Real-Time constraints? Do you need to quickly "close the control loop"?

graziano

[Norbert_B]

ITA,

LabVIEW has one very critical disadvantage regarding your application:
Since LV is a graphical programming language and therefore easy to step in, it is very often used in an improper way:
- building an application without any planning
- awefull code design
- overly elaborative algorithms

What i am trying to point out is: if you don't care about projectmanagement, you can get screwed up quite easily. But this isn't imho the fault of the tool, but the fault of the projectengineer.....

For the rest, i concurre with graciano 😉

hope this helps,
Norbert

[ITA]

Hi,

Thanks for replies.

Grazinao, I would be using MXI express and PXI based system but not the real time scenario. And the responce time expected is 500ms. Is this possible for 3000 I/O count through LabVIEW?

[Graziano]

Hi!
   handling, for example, an array of 3000 boolean is quite simple in labview. About the time for getting all the inputs, it strongly depends on Hardware, which I don't know... do you need digital I/O, or you have many analog channels?

   I don't know in depth PXI, so I don't know about system capability of handling 3000 I/O...it seems a high value to be stored in a single chassis...but really, don't rely on this answer, it's a system I don't master....

   I know for sure that FieldPoint can handle that number of I/O, the time to collect them can be higher...

graziano

[Ben]

"Is this possible for 3000 I/O count through LabVIEW?"

Depending on your hadware and sample rate, then 3K is do-able in LV.

I have an app that does 30,000 I/O points at 1KHz sample rate. (multiple CPU's with SCRAMNet back-bone).

But don'tget the idea you can just run off and do a high channel count app without good planning.

Ben

[ITA]

Hi Ben,

I am impressed with your reply!

If possible could you just share the high level architecture of your system. I am not asking you to share information that is confidential, but a very abstracted architecture diagram if you can....How you are using multiple CPU etc.......

Thanks!

[Ben]

"If possible could you just share the high level architecture of your system. I am not asking you to share information that is confidential, ..."

Ouch!

I'd catch hell if I shared anything useful.

The application consisted of a dozen or more (re-configurable) nodes all interconnected using SCRAMNet (Reflective memory- fiber linked by Curtiss Wright) or ethernet. Central station monitored I/O status of all configured nodes and monitored, controlled, displayed and logged all  interactions bewteen nodes as well as the analog digital and counter I/O from two PXI chassis using Remote Data Access.

App was developed using a "divide and conquer" approach with 30 (configurable) supervisors running that in-turn were implemented by starting with a generic structure (DAQ, Logging, Display, Publishing) that was adapted to the data subset controlled by the associated supervisor. In laymans terms, A lot of VI-Server combined with "inplacenesses" and hung on a structure that I called "Advertising with Self Addressed Stamped Envelopes".

Ben

[Ben]

RE: my previous.

I understand that the above does very little to help you with developing a large app. The above mentioned app includes more than a 1000 VI's and took three developers almost four months to develop. It's hard to describe an app like that in a couple of words. THe design documents all include confidential info so I would have to scrub all of them before I could post them.

Sorry!

Ben