LabVIEW and large data sets are incompatible. T/F? I say T.

[GerdW]

Hi 3d0g,

---

@*3d0g wrote:

Is there really 32MSa in those waveforms?  I'm not so sure about that.    

---

There is a function palette dedicated to waveforms: those functions will help you to determine the number of samples in your waveform! (WaveformComponents + ArraySize)

---

@*3d0g wrote:

Of course I started with the OEM; I asked them what to do.  However, they couldn't help, saying they had no LabVIEW license, which I find odd being is they're saying their equipment works with LabVIEW. 

---

You always (should) get a reasonable ProgrammingManual with your measurement equipment.

Nobody forces you to use the driver supplied by the manufacturer, although most often that is a good starting point!

You can always implement your own device driver, using exactly the commands you need with the parameters you need. Some devices offer optimized data transmission settings, like switching from ASCII formatted data to binary encoded data using less memory…

[cstorey]

What's the make and model of the scope?  Here's how the data transfer and conversion is done in a Keysight scope VI.  There's no need to make it double, it was just the default type they chose.  You could make your own VI (essentially a duplicate of the given VI) to get the data and convert values to single precision. 

 

[*3d0g]

I tried to avoid pointing a finger, but since you asked the question...

Teledyne LeCroy HDO6000B series  (Their driver covers much hardware; hence, series covers the model number.)

To do what they claim to have done they had to be using the 64-bit LabVIEW, in my opinion.

They're claiming they can work in LabVIEW after bringing in at least 50MSa through a waveform indicator, and they can do this with at least four channels.  I'd bet that were I to run it in 32-bit LabVIEW the thing would die.

Incidentally, to anyone still participating, here, I just posted another thread about LabVIEW Memory Management requesting others take a look at my vi.  (I figured I'd get it for continuing with it here in this thread vs starting a new thread.  So I started a new dedicated thread just for it.  This memory management really has me perplexed.)

[altenbach]

---

@*3d0g wrote:

They're claiming they can work in LabVIEW after bringing in at least 50MSa through a waveform indicator, and they can do this with at least four channels.  I'd bet that were I to run it in 32-bit LabVIEW the thing would die.  

---

A waveform is just a 1D array plus some timing information (t0, dt) and can have many representations (DBL, SGL, I16, U8, CDB, etc. etc.), so if the driver is doing it right, it should not be DBL as you claim.

---

@*3d0g wrote:

So I started a new dedicated thread just for it.  This memory management really has me perplexed.)

---

For completeness, I think you are talking about this discussion. It always helps to give links!.

[cstorey]

It's not finger pointing, its being specific so other LabVIEW users who face the same issues can find solutions.

Companies produce these IDNet "drivers" as examples, not full blown solutions.  They aren't APIs that expose every feature of their hardware.  They usually provide the bare bones features of a primitive LabVIEW instrument control program; initialize communication, basic measurement setup, basic data transfer and close. 

If you need complex triggering, or to squeeze high speed acquisition or other more advanced features it's highly unlikely that the manufacturer has gone to the point of providing that functionality.   For a lot of general use cases they are probably more than sufficient to save a beginner a bit of time learning all the ins and outs of the hardware.  

Since these "drivers" are not the solution but a mere starting point for learning how to program the instrument purhaps the title "driver" should be reconsidered.   

[Eric1977]

I think we all need to see how your implementing your code to get these memory error messages that you claim to get. Without it, we can only make suggestions and comment on what you are telling us. I haven't seen the OP post that throughout this entire thread.

PLEASE upload your VI and not an image. You'll get chastised for it if you do.

[*3d0g]

Ok, here's my simple vi that runs out of memory.  I cannot go to 64-bit LabVIEW; it is not an option.

This vi is LabVIEW 2014.

I request a solution if there is one.

Thank you. 

[*3d0g]

I just brought the simple array test I did to this thread, but I don't know if you would find it easily, so I've added it below anyway.  This vi is LabVIEW 2014. 

In

https://forums.ni.com/t5/LabVIEW/LabVIEW-Memory-Management-VI-question-a-special-request-to-you/td-p...

I posted a vi that shows I have loads of memory with stored data, but I don't understand how I can get that stored data out in order to work with it.  This vi is LabVIEW 2018.

I also don't understand how to free up memory afterward.  Does LabVIEW give memory back somehow? 

I need to understand how to work with large data sets without running out of memory. 

[*3d0g]

Going to 64-bit LabVIEW is not an option. Period. 🙂

Now what?  I can get the data I need into memory, but how do I get it back out in order to work with it?

After I've used memory, how do I restore it such that it is available again for LabVIEW to reuse as needed?

[*3d0g]

In this other thread

https://forums.ni.com/t5/LabVIEW/LabVIEW-Memory-Management-VI-question-a-special-request-to-you/td-p...

I have data stored in large amounts of memory -- the memory is there.  Now how do I get it out in order to work with it without LabVIEW running out of memory as was demonstrated in this present thread with my simple array vi?

One answer I know is don't use indicators except for troubleshooting.

How do I release memory for reuse by LabVIEW?  Or is that memory just gone for good?

Switching to 64-bit LabVIEW is not an option.