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

[*3d0g]

BTW, if it turns out to not be a bug and it's my goof, you bet I'll let you know, because this is a stinker.  I have to move on.  I can't sit on this memory hog local due to a bad tunnel and a Always Copy that doesn't help me.  I knock on NI's door.

[Intaris]

---

@*3d0g wrote:

Bob: Also, this thread isn't about me teaching anyone anything.  It's me learning.

---

Then start a blog or label your posts accordingly. You're using up bandwidth of the forums because people are actually trying to help.

We're all work jobs, we're not employed by Emerson (NI) and our time here is offered for free.

If you're not looking for feedback, state that explicitly. Otherwise you're being a di.

[Eric1977]

---

@*3d0g wrote:

Bob: Also, this thread isn't about me teaching anyone anything.  It's me learning.

---

No, you're being disrespectful and a Richard to other forum members that are trying to help you yet you don't want to help us and babble on about how "it doesn't work." You won't share your code, or even an example, of what's wrong. You are on your own.

I am beginning to wonder if you are even using LabVIEW and are just wasting everyone's time being a troll. Based on your username, I am beginning to wonder if that is the case...

[JÞB]

I give up.  

[JÞB]

This is what happens when you open a toolbox and only pull out a screw-hammer.  I give up.  

Won't follow advice, won't actually read material in Knowledge Base articles links provided, won't show example code.  Won't define the measurement needed.

Yes, those links to large data and the LabVIEW compilers inner workings ARE the explanations.   We are not going to rewrite that information in your thread.  I only have so much time. I'll use it for someone who will learn.

[*3d0g]

"This thread isn't about me teaching anyone anything.  It's me learning."

That's what my question was about.  I wanted to learn something.  The answer is T, unless it's 64-bit.  32-bit is incompatible, for all practical purposes.  Large datasets?  Leave 32-bit or prepare to get very creative.  (LVOOP.  Still a great post.)

Then later, while investigating various routes, I ran into a LabVIEW response I've never seen before and learned of something similar that happened five years ago, having a CAR attached, where participants in my current thread were present. (!)

I'm really stunned that when I finally gave in and dropped pictures of the conditional structure in question into the thread everyone gets bent out of shape that there is no code and no one recognizes horizontal shift register lines for some reason.  Even the novice knows the shift register line.  Likewise, even the novice knows what a tunnel is and can recognize one.  It's very disappointing that LabVIEW pros won't even take a stab at the problem, not even speculation.  An array just goes blank, but retains its size, and I'm the bad guy for not dropping code for everyone to play with.

[mcduff]

The picture was lacking along with your descriptions that is the cause of the problems on this thread. You say you are using a Teledyne LeCroy HDO6000B, but nobody is sure.

For example, would it be easier to describe the Mona Lisa in words or show the painting itself and a not just a small section of the background.

Some things to keep memory at a minimum, assuming you are using a Teledyne LeCroy HDO6000B as I just looked at the driver:

1. This is a VISA based instrument.
   1. Don't download the points all at once. I could acquire millions of points from a VISA scope by looping over the download.
   2. Loop when you acquire the points from the scope. For example download the 1st 1M points, then the next 1M points, etc.
   3. When you download all at once you create a buffer for that data, which is a "string" type. You then create another buffer when you convert to I16. By looping you avoid that extra full buffer.
   4. Create one array to hold all the points and add them using replace array subset in your download loop.
2. You are using MoveBlock in your picture which normally is only used for special circumstances.
   1. We can't see how it is being used.
   2. We see wires but don't know where they came from.

Not sure if you have used Google Maps when driving, but the map shows ALL the surroundings not just the street you are on. You showed a narrow view and expected insight. At this point I have no idea what you are asking, what your problem is, or even why I am responding to the thread.

[*3d0g]

LeCroy was in fact using 64-bit LabVIEW for their claim.  (Wrapping up that question of this thread.)

I'm still using the local variable-bypass with the PicoScope and I'm moving on. ...but looking into the LVOOP idea.  I know you hate me for not pasting code, but thanks anyway.  That's interesting to me just the same.

One thing I will say is I apologize to you all for not limiting the scope of the hypothetical(, but true) situation to 32-bit LabVIEW.  Had I done that from the beginning there probably wouldn't have been much 64-bit LabVIEW!!! banter.

[*3d0g]

It is correct what another said that few actually read the thread.

I am not and never have used a Teledyne LeCroy oscilloscope with any version of LabVIEW.  Rather, I was examining the driver LeCroy had provided for the HDO6000B series to determine whether the LeCroy would work for my purposes.  The only reason I even said LeCroy is someone asked.  I wanted to learn about LabVIEW-tools technique, how to work with what was being presented in the driver package, no matter who wrote the package.

Last, I'm using PicoScope -- I even posted a picture.  Never in a million years would I use VISA to bring in 32MSa x 4.  PicoScope screams; all the data gets pumped in via USB, right into memory -- bang!

But that's where it all stops.

[*3d0g]

Eric1977: You're correct. It's a big lie and I'm using an Apple ][e.