My system gets weird at loop count ~2050

[Scrx]

Scrx (put up here because putting the carriage returns after the text I entered pushed that text down and started the cursor above!) 

And just a quick comment for the administrators of this web forum - What the flying hell is wrong with your parsing of carriage returns and line feeds?  Maybe your web browsers work fine, but your forum puts the carriage return before the text!  Test in Opera 9.6, please!

[Scrx]

Hi Altenbach again, 

You did provide an example of a many-input AND gate, and I overlooked that in my first response.  But that part works!  I don't need to optimize it.  What I need fixed is why my system goes haywire at 2050...

Thanks, Scrx

[altenbach]

---

Scrx wrote:

I did calculate the data required - 9000 cycles, sampled 64x, at 16 bits, is not two megabytes.  I've got computers with RAM measured in gigabytes.  I don't see the problem here. 

---

Your xy graph has a data copy and your xy graph express VI keeps another data copy (or more). Whenever the buffer runs out of space, it needs to newly allocate memory and copy everything over. Arrays are stored in contiguous memory locations, so you might run out of contiguous memory space because of the constant memory thrashing. ...Then you are doing everything with dynamic data, which carries a lot more baggage. The arrays are probably DBL internally.

Have you looked at the memory usage during a run, e.g. via the VI properties or task manager?

---

Scrx wrote:

 You're right, I do want to plot a finite history (all 9000x64 points seen).  But I want the graph to build over time, so the operator can watch it.  Just scraping up the data and dumping it later on won't do.

The answer might very well be a 'picture' indicator.    

---

Since you know the exact number of points from the start of the program, you should allocate the final size array into a shift register and then replace it with data as it arrives. Simply bundle the X and Y arrays and go to a graph, no need for all that express stuff. You could also store it in a single CSG array (complex single precision) array and graph it directly as RE vs IM in an xy graph. Initialize the arraqu with "NaN+iNaN" so invalid data (=data not yet acquired and replaced) is not plotted.

---

Scrx wrote:

 What I'd really like for the input data validation is a bazillion-input AND gate.  Are there any LabView gates with more than two inputs?  

Anyhow, that part works fine.  It's not the user input that's the problem.

---

Well, you would use arrays. For example if you want to know if none of the elements in a bazillion sized array are zero, wire the array to "not equal zero" (comparison palette) followed by "AND array elements" (boolean palette) and you're validated. Right?

(...and as I said, the compound arithmetic node can be set to mode=AND and you can resize it for the number of requred inputs as shown in my image above)

---

Scrx wrote:

 The last while loop does nothing because I want it to conditionally print or reset based on user interaction.  But I can't find out how (I started another thread on this) to print the front panel on completion based on a user input.

---

 There is an invoke node to print the panel (see image). Simply place it inside a case for conditional printing.

Message Edited by altenbach on 11-05-2008 04:00 PM

[Scrx]

Hi again, Altenbach 

Well, I think the opinion is pretty clear that it is a memory thrashing problem, and that gives me leads to get on with fixing it.  You've provided many good ideas for doing something about it, although I'm not sure how many I can readily implement...  *grin*  I have looked at memory accesses, and found not so much actual space dedicated to LabView, but a heckuva lot of 'handles', which might also be part of the problem.  Also, I would really lurv to take all that 'dynamic data' and force it to I32 or something (better, an array of Booleans), but that seems to cause errors in the connection traces every time I try it.  Anyhow, my job is obviously not yet done..

Thanks, Scrx

PS - Thanks very much for the printing item!  Solved another problem for me.  S.

[Scrx]

Still not much joy.  I did get it to print nicely, thanks.

Total memory consumption never runs much over ~150k MB.  Doesn't seem badly fragmented.

Using boolean arrays in some areas did clean up the block diagram some, but did absolutely nothing for functionality.  I did put little delay timers in all my 'user interface' loops, and CPU usage plummeted.  So that's better.

 Moreover, I could put *long* delay timers in my main loop, and it sorta worked again.  But the timing delays were 300-500ms, and resulted in an actual sampling rate of something like 32 samples per second.  I need more like 32,000 samples per second... Is that too much to ask from a card officially rated at 150k? 

I did find out why it goes haywire at ~2050, though.  The FIFO buffer on my PCI-6143 has a 2,046 byte FIFO.  Coincidence?  It's not generating any errors, it's just that the internal 24-bit counters start sampling at highly weird times instead of on the neat timing schedule I had them on at the beginning.  Refer back to the PDF I posted at the very outset of this if I'm making no sense.  

And in other news, I started another thread on counters, and how to use an external digital input to clear them.  Just FYI. 

Thanks, Scrx 

[Jeremy_B]

Hi Scrx,

You are reading two sets of 10000 samples from your DAQ Assistant, and then sending them to a Build XY graph. The Build XY graph is not set to clear, so you are probably buffering additional data.  Even if your memory usage stays low, LabVIEW has to move large chunks of data around, and that gets slower with increasing size.  You should set the graph to clear, since you cannot actually view 10000 points anyway.

I would also recommend doing a continuous acquisition, rather than running a finite in a loop. You will get discontinuous sets of data since the acquisition is stopped until your loop completes.

You can use the From DDT VI to convert your dynamic data to another type. 

[Scrx]

Hi Jeremy,

Thanks for getting back to me. Much appreciated.

And, well, 9,000, but yes. That's the idea - To have lots and lots of data trample all over itself so the outliers can be seen. This is a *requirement* (of the customer!) so let's take it as a given that I need 9,000x64 data points plotted. If I clear them every time, I get one cycle plotted, or one little wandering dot on the logging plots. This is unacceptable.

I'm thinking of a two-pronged approach myself - One is to sample all the data into an array (or several arrays), then plot it all offline in another following sequence frame, and to do all my precision counting externally, by building separate counter/DAC hardware, and just feeding LabView another analog signal.

It is a pity, but it seems that the two on-board counters are useless for this application.  I'll keep one to calculate the sample rate.

For data conversion, I've been using what I find in the 'Numeric' functions panel, selecting which seems appropriate at the time. Does the 'From DDT VI' do anything interesting that those don't?

I appreciate your suggestion about going to 'continuous', but I like using N samples because the external driving trigger signal is synchronous with the incoming sine waves. One fun trick is to turn off 'vectors' in the Lissajous figure, and I get a little ring of 64 slightly fuzzy spots. Not entirely unlike the EU flag.  Note also that the user is supposed to be able to select the number of samples, and that rules out 'continuous' entirely.

Again, thanks for getting back to me, but I'm afraid the real problem is inability to accurately read and clear the counters. I was going to start another thread about that, as I mentioned, but after reviewing some others, I have decided that the counters really are useless for this application, and I should just feed the card another analog signal. I've got six left over, after all. Observe also the very original PDF file that showed the output. The 'Ratio' graph was fine for all samples (although I think it was skipping every other one). It was only the 'absolute err' that went wonky, and that was dependent on precision counter measurements.

Have fun,

Scrx

PS - speaking of wonky, something is still really really wrong with your forum software.  Why in the world does it treat a carriage return halfway through a posting as a command to 'take this line and push it down, and put the cursor above it?  No other fora do that...  Doesn't *anyone* else use Opera 9.6?  S.

[RavensFan]

---

Scrx wrote:

PS - speaking of wonky, something is still really really wrong with your forum software.  Why in the world does it treat a carriage return halfway through a posting as a command to 'take this line and push it down, and put the cursor above it?  No other fora do that...  Doesn't *anyone* else use Opera 9.6?  S.

---

No.

It sounds like an Opera problem to me if other browsers aren't doing it.

Perhaps one of the other two Opera users can chime in and say whether they are having the same problem as you.

[Scrx]

Scrx 

Thanks,

under 'Feedback on NI discussion Forums'. 

See my post 'Bizarre carriage return behavior in Opera 9.6'

I guess not.  

Hi Ravens Fan,

[RavensFan]

?RPN with calculators HP old those like work to set is Opera Maybe