Code bloat with NIDAQ-MX ?

[CoastalMaineBird]

I just switched my app from Classic NI-DAQ to NI-DAQ MX on LV 7.0. (I'm an old hand at LV and DAQ, but new to MX).

As it's loading the LOADING dialog comes up and announces how many VIs have been loaded, etc.

Before, the highest number I could see was about 450 or so before the main panel came up.

After moving to MX, which involved replacing 10-12 VIs with 10-12 different VIs, this number now shows up as 630+.

I didn't (intentionally) add that many VIs.

The VIs that I did put in don't have that many subVIs.

They ARE however, massively polymorphic (DAQ-MX Read, for example).

The UNOPENED SUBVIs list shows a lot of the unused variations.

Somebody PLEASE tell me that it's not really LOADING all that unused stuff. When it says "Loading", it really means "finding" or something, just so it's available if I changed the polymorphic selector. But it's not really bloating my app by that much is it?

LabVIEW has never been THAT dumb before, please tell me they're not now.

[LV_Pro]

I guess the real test would be to make an exe with each "technology" and see what LabVIEW thinks has to be there at run-time. Or run it with the traditional and then with the DAQmx stuff and see in task manager how much the "foot print" changes. Do you see all those in the heirarchy?


Putnam Monroe

Message Edited by LV_Pro on 05-26-2005 10:14 AM

[CoastalMaineBird]

Do you see all those in the heirarchy?

The Hierarchy is a completely useless tool on apps this size. There are places where I have a hundred "connections" within a half inch on the screen. Not too readable.

But if you rummage through all that crap and find MX-READ for example, the Hierarchy does show that MX-READ is connected to 30 or 40 subVIs, all variations of MX-READ :
DAQmx Read(Digital 1D u8 NChan 1Samp)
DAQmx Read(Digital 1D Wfm NChan 1Samp)
DAQmx Read(Digital 1D Wfm NChan NSamp)

etc., etc., etc...

MX-WRITE has a similar number of children, but I am only using 1 or 2 of those variations.

So my question is, are they eating up my RAM memory? or not?

I CERTAINLY hope they are not in the EXE...

[CoastalMaineBird]

I have a documentation generator which generates a list of VIs called by a given MAIN vi.

It normally excludes stuff in VI.LIB, but I changed it to include that, and it reports that all these variations are present.

Umpteen versions of DAQmx Read, umpteen versions of DAQmx Create Channel, etc., etc.

NOT a good sign.


I have another doc generator that writes an HTML file for each and every VI in the hierarchy, showing it's callers and callees, revision, history, etc. (and I THINK they have to be in memory to get the history info).

It shows every bloomin' one of them.

NOT a good sign.

[LV_Pro]

I don't know, certainly hope that the compiler, either at runtime in the development mode, or when a exe is created, has been optimized to realize that polymorphism isn't an issue when running (unlikely that you would change type of sensors on specific inputs, even if you could!)

Good luck, have a good weekend. I think that I'm stealing out of my customer early today, the weather is uncharecteristically nice at the moment for Central New York (no snow and a bright light in the sky that I will investigate for a source!)


Putnam Monroe

[RobCole]

When it comes down to creating a deployed application, the application builder has an option on the application settings tab called "Disconnect type definitions and remove unused polymorphic VI instances". Make sure that this is checked to remove the "code bloat" or you WILL have all of those included.

And, yes, DAQmx uses more memory than traditional DAQ. We haven't characterized it yet, but have noticed the difference on our PXI systems.

DAQmx data acquisition is faster, but initialization is slower. You have to decide if you can live with that.

Rob

[jspaarg]

I realize that I am resurrecting an old thread, but this addresses the issue that I am having.

I am using a PCI-6503 and it seems that there should be a far simpler way to address that card than the bloat that occurs with the DAQmx calls.

There isn't even any analog on the card, yet the hierarchy lists about 24 analog calls being included.

Can I still use the old DAQ calls, or do I need the DAQmx?

Is there a simpler way to do this?

Any input is appreciated.

[Ed W]

Hi jspaarg,

Technically, you can use the Traditional DAQ drivers for the PCI-6503, but it is strongly recommended that you use the DAQmx drivers.  These drivers do have a long initialization period than the Traditional ones, but DAQmx is much more robust.

The following document addresses a lot of the questions about the advantages of DAQmx over Traditional DAQ.

Answers to Frequently Asked Questions about NI-DAQmx and Traditional NI-DAQ (Legacy)

I hope this helps!

Ed W.