NIDaqmxbase Read VI till buffer empty challenge

[sth]

Joe,

I agree that having the -1 for count return all samples, and having the 0 not timeout if the # of samples is less than that originally available would be great improvements if the don't need a rewrite of the DMA engine.

Thanks for the VI, however when I open it, it throws the old line 1081 fontmanager.cpp alert that I have never gotten rid of.  Then it crashes LabVIEW 8.5.1-PPC!  Oooops.

Maybe I need to open a service request on this?

-Scott 

Path:            /Applications/National Instruments/LabVIEW 8.5/LabVIEW.app/Contents/MacOS/LabVIEW

Identifier:      com.ni.labview

Version:         8.5.1 (8.5)

Code Type:       PPC (Native)

Parent Process:  launchd [425]

Interval Since Last Report:          2697636 sec

Crashes Since Last Report:           4

Per-App Interval Since Last Report:  407243 sec

Per-App Crashes Since Last Report:   8

Date/Time:       2009-09-10 17:47:59.367 -0400

OS Version:      Mac OS X 10.5.8 (9L30)

Report Version:  6

Anonymous UUID:  EC6BBFFA-C7E0-428E-B174-2BF879441341

Exception Type:  EXC_BAD_ACCESS (SIGBUS)

Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000

Crashed Thread:  0

Thread 0 Crashed:

0   com.ni.labview                 0x00864b20 TDNameImp::CheckIn() const + 92

1   com.ni.labview                 0x00841884 TDImp::MemberCheckIn(TDImpPtr&) const + 112

2   com.ni.labview                 0x008cce6c TDBasicNumericImp::MemberCheckIn(TDImpPtr&) const + 36

3   com.ni.labview                 0x0083fa50 TDImp::CheckIn() const + 196

4   com.ni.labview                 0x00ae8670 TDDataReader::ConstructEltTD() + 18212

5   com.ni.labview                 0x0007c448 LVDataReader::ReadTD() + 100

6   com.ni.labview                 0x00083d0c LvVariant::UnFlatten(LVDataReader*) + 336

7   com.ni.labview                 0x0008cbc0 LvVariantUnFlatten(LVDataReader*, LvVariant**) + 88

8   com.ni.labview                 0x0090c4ac TDLVVariantImp::ReadData(LVDataReader*, void*, long, long*) const + 216

9   com.ni.labview                 0x00099f7c UnFlattenFromPtr + 124

10  com.ni.labview                 0x00137f18 InitExternalNodeVIRef(ObjectHeap*, BasicObject*) + 1360

11  com.ni.labview                 0x00138364 GetExtNodeVIDataPtr(ObjectHeap*, BasicObject*, ExtNodeVIParam*) + 32

12  com.ni.labview                 0x0013cb9c ExternalNode::InternalEditSelection(long, Args*) + 68

13  com.ni.labview                 0x00c9ea40 AbstractDiagram::InternalEditSelection(long, Args*) + 1056

14  com.ni.labview                 0x00d3420c Structure::InternalEditSelection(long, Args*) + 1140

15  com.ni.labview                 0x00dcd15c Select::InternalEditSelection(long, Args*) + 920

16  com.ni.labview                 0x00c9ea40 AbstractDiagram::InternalEditSelection(long, Args*) + 1056

[sth]

And it crashed LV 8.2.1.... 😞

[JoeFriedchicken]

I wrote it on Linux. Let me see what happens when I open it on Mac. If it crashes there too, then I'll rewrite it on Mac and repost.

[JoeFriedchicken · Accepted solution]

So it was 'Save for previous...' that confused LabVIEW. Here's a re-written version from a PPC Mac with LabVIEW 8.2 🙂

[sth]

Well that linux version was special!  I see you had to "rewrite it"!  I wonder why it didn't transfer...  Oh well, one of life's little mysteries.

I see how you did that.  Very nice.  I was hesitant to go in and use those X-Nodes.  But I see how you get the HW Reference from the Task ID and all is well.

So I don't have to wire an array of length zero to get zero samples but it works if that array is just not wired up?  I know on call library that is supposedly bad to leave the result array completely unwired, but X-Nodes may be different.  (Those blue things are X-Nodes, right?).

I see why it is limited to E-Series, but for me this is incredibly useful!!

Thanks,

Scott

Message Edited by sth on 09-11-2009 04:31 PM

[sth]

One small improvement should be that when you pull out the scan list to get the number of channels you should pull out the DMA channel and feed it to the X-Node.  Assuming that so far you always use Channel 1 is good, but it may not always be the case? 

[JoeFriedchicken]

I don't know what the problem was with LabVIEW saving for a previous version. I imagine it was that node you noticed 😉 It's not exactly an X-Node, but their precursor. I was also able to reproduce the crash in Windows, so there's something going on there.

All of the code in my property VI is gleaned from the E Series DMA VIs -- what happens in them has been distilled to get this single number. You don't need to wire an array, and if you do, you'll end up pulling samples out of the buffer, which may be something you don't want to happen.

If you like, you're welcome to pull out the DMA channel and feed it to the proto-X-Node, but it's not neccessary. The DMA chip only has three DMA channels on it, and in Base, only AI uses DMA, so channel 1 has been hardcoded in the driver.

[sth]

---

Joe F. wrote:
 I imagine it was that node you noticed 😉 It's not exactly an X-Node, but their precursor.

If you like, you're welcome to pull out the DMA channel and feed it to the proto-X-Node, but it's not neccessary. The DMA chip only has three DMA channels on it, and in Base, only AI uses DMA, so channel 1 has been hardcoded in the driver.

---

Ahh, the precursor to an X-Node the infamous W-Node!!

I just have an irrational fear of hard coded constants.  I like code to be future proofed.  I noticed that DAQmxBase has a lack of Strict TypeDefs.  Was that a design decision of just historical happenstance?  

[JoeFriedchicken]

As far as I know, it's a historical convention. I can imagine the extra flexibility provided by standard TypeDefs helped Base's code generalize itself between desktop and PDA targets.

[sth]

Joe,  And others who might be interested in this thread....

Since I can't leave well enough alone, and was trying Joe's nice routine and suddenly realized that I was working on a machine with an M series card instead of an Eseries that prompted the original question.  So I have modified the routine for M series and E series cards (as well as S series but that is untested).  It takes up much more screen space, of course, but it is a bit more universal.

 

In doing this I noticed that the  S series card stores all the relevant data as "variant properties" rather than in an array.  It is a bit more flexible and can allow user expansion.  Though it should not be much different than using strict type defs.  One problem is that it does allow for typographical errors to creep in at run time rather than all the type checking at compile/writing time that strict type defs would do.

I guess the question is if this is the future of NIDAQmx base or not?

But here is the VI for everyone's enjoyment, this will give the number samples in the DMA buffer for M, E and S series cards.  USB of course is not supported for this functionality.

Enjoy!