C or LabVIEW?

[PaulG.]

I, too am working on an NDT application, and have experienced the most trouble with the live updates, too. But we also pulled that off. I'm not familiar with the concept of "distriputing the application across multiple platforms". Maybe I know what it is already but have never heard it called that before. Could you explain in layman's terms?

Paul

7.1/XP/2000

[Ben]

What I was thinking about was breaking the DAQ requirements up into small enough chunks that no single machine is over-burdened.

Most of the time, I have not had to resort to this approach. I did do a a jet aircraft engine simulator that needed to keep multiple (7?) PID loops closed at 1kHz while logging and displaying a bunch of channels at 1KHz.

I did all of the logging and display work on a Windows platform and closed the PID loops using a RT node. Since then CPU's have grown up a bit so I may not have taken that path with modern CPU's.

My NI Week paper on this application was published in Compact PCI magazine and can be found here.

http://www.compactpci-systems.com/articles/id/?195

I will not enumerate all of these distributed apps but will touch on one of my current apps. The customer requires 20,000 channels at 1000Hz.

By implementing all of the sub-systems using VI server type plug-ins, I will be able to deploy logical chunks of the app to multiple CPU when the time comes.

So...

If the application is too demanding for just one machine, share the fun across multiples.

Again, I would not like to have to do this in C!

I hope this helps,

Ben

[Jumper_Bones]

I know this is an old thread, but I am trying to locate the whtie paper that "Chris C" said he was updating, because it seems it has been updated to now be completely off the NI web site...!

I sent a broken link report to the NI.com webmaster about this.  But meanwhile, does anyone know where this is?  Or if they have the paper, can they attach it here?  (assuming it's PDF or RTF or whatever).

Thanks, JB

[SteelStonehenge]

As biased as we may be, we all realize that at the core of many VIs is a Code Interface Node that works at the C or C++ level.  The general rule is, the closer to the hardware you are, the faster it will run.  (I imagine it's possible to write sloppy machine code, but it's a lot harder to hide it!)  Most seasoned Labview developers do a fair share of low level bit twiddling.  It's not a matter of Labview or C...it's BOTH.

eric

[Kevin_Price]

As you really start pushing the limits, a manually-tuned C app is liable to be better at execution performance.  There are some places where LabVIEW uses crash-resistant "By-Value" array copying where a C program could just sling around pointers or pointers-to-const.  The DAQ driver layer is one such key place -- the data returned from a DAQmx call to a LabVIEW app must be handled as a copy while protecting the part of system RAM used for DMA buffering.  A low-level C driver could conceivably pass around pointers to the raw system RAM area instead.

I think LabVIEW generally does a pretty good job under-the-hood at deciding when it truly must make array copies and when it doesn't need to, so for the vast majority of apps it's likely to be fast enough.  It also provides a pretty clear and understandable interface to the DAQ drivers.  The occasional post I see making long series of DAQmx function call with VB or CVI, each containing maybe 60 chars per function, make me shudder.  And a lot of the #def'ed constants seem a lot more cryptic than the corresponding DAQmx vi's and categorized property nodes.

-Kevin P.