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

[*3d0g]

As I said to Rolfk, I'm sorry. I have hi-jacked my own thread, as of last night.  I saw I had knowledgeable people here and rather than keeping my troubleshoot to myself I dropped it in this thread.

The DBL in a waveform, that was LeCroy.  It is most reasonable that they started as 16-bit integer and then sent it out as floats, despite the memory need it brings. ...the question is whether I'd do as suggested and dig into their driver and API.  Been there done that.  I prefer paying lots of money for an oscilloscope and have software that works right out of the box.  I'm pretty sure management would like that as well.  True, it'd be fun, but time is money.

As for this debug, I'm really thinking this is about loss of scope, somehow.  The array just goes empty as it exits.  That reminds me of a function declaring a variable within and then the variable being empty after the function completes.  The fact is the variable may look the same name-wise, but there are actually two different variables.  That's what I think is happening.  

[*3d0g]

Thanks for the link, JÞB.  I read it last night.  When I get a chance I'll check out that software.

Then, I'm happy to be able to give you another kudo.  That latest information... Interesting.  "Always Copy" on a wire branch... Hmm.  I have to look at that.  I don't know what that is, exactly, but due to the discussion, here in these threads, I can take a stab at it.  Thank you!  That's what's great about this forum.  People use language I don't know but I can look it up -- at least I have "right" terminology.  That's the key to looking up things: the language used must be something in the database.  One can't say "array data disappears through a case structure wall/border/boundary" and get much.  (Then there's, at least this happens to me, entering something in the search input and the software behind the forum changing it and then giving the results of the new search input it wanted to use, not what you said.  That's annoying!)

That's interesting, though.  A new LabVIEW "feature."  Thanks! 

[*3d0g]

Altenbach:

"Yes, as I said, waveform can be I16!"

Yep, that's what I did to see my sine wave was coming out just fine as raw data -- dropped a tiny waveform display on the FP and fed it.  (I was thinking maybe something had gone to lunch with my MemoryMove. Nope, my sine wave was there just waiting to leave.)

"It all depends on how you program it."

You're a LabVIEW Champion.  I am not -- far from it!  I am thankful you're participating in my thread.  I appreciate being able to listen to your insight on how LabVIEW works.  (In the end, my code must be compatible with how LabVIEW works.  I may see X, but LabVIEW could be seeing Y.)  However, I must admit, often you folks are speaking a foreign language and I have to go to a translator to my rudimentary LabVIEW and programming skill set. 

[*3d0g]

dc

Well, this is even more interesting.  I got it to work, but get this workaround...

I created an indicator (loss of memory space) for my source buffer to the MemoryMove.

I created a local variable "CH1 buffer" just inside the getting-the-data case of my state machine.

I wrote "CH1 buffer" with the correct data inside the CH1 case (left side of wall, about to exit.)

I broke the line at the exit of the wall (the left side of the wall.)

I read the data from "CH1 buffer" back into the broken line, feeding the line with the correct data.  (IOW, I substituted the zeroes with the correct data via a bypass using "CH1 buffer.") 

Viola!  There's my sine wave.

Now why?  There are brilliant LabVIEW giants here.  Why?  Why was my array getting zeroed going through the wall?  ...and yes, I still call it a wall.  That what it is.  It's a local structure inside another local structure inside a global structure.  This creates a series of walls.

Before you answer why, assuming you do, before going to this "CH1 buffer" bypass route, I tried a few things that didn't work:

1. I replaced the buffer array with a brand new buffer array, just rebuilt the array entirely via initialize array.  Nope.

2. I rebuilt the entire case structure of the impenetrable wall.  Nope.

3. I deleted the (shift register) path from the buffer to the case structure and reconnected it.  Nope.

4. I deleted the path from the state machine case and reconnected it as one long drag directly into the MemoryMove.  Nope.

5. Finally, despite the memory hog of "CH1 buffer," I managed to get my data through the wall. 

Why did I have to force the data out?  Why just this one line, channel 1?

I'm thinking "CH1 buffer" will lose scope leaving this case of the state machine and, maybe, I can have that memory back.  But, I just read a very long memory management document in LabVIEW help, and I don't think that's going to happen, unless I request to deallocate at the exit of the subvi, but then that'd cause recreation of the data to the driver vi.

Hence, technically, debug continues.  What in the world is going on?  I need to look at that force LabVIEW to copy thing at the branch. (This is what I mean by terminology and searching.  The terminology must be correct or you won't find it.) 

[JÞB]

---

@*3d0g wrote:

dc

Well, this is even more interesting.  I got it to work, but get this workaround...

I created an indicator (loss of memory space) for my source buffer to the MemoryMove.

I created a local variable "CH1 buffer" just inside the getting-the-data case of my state machine.

I wrote "CH1 buffer" with the correct data inside the CH1 case (left side of wall, about to exit.)

I broke the line at the exit of the wall (the left side of the wall.)

I read the data from "CH1 buffer" back into the broken line, feeding the line with the correct data.  (IOW, I substituted the zeroes with the correct data via a bypass using "CH1 buffer.") 

Viola!  There's my sine wave.

Now why?  There are brilliant LabVIEW giants here.  Why?  Why was my array getting zeroed going through the wall?  ...and yes, I still call it a wall.  That what it is.  It's a local structure inside another local structure inside a global structure.  This creates a series of walls.

Before you answer why, assuming you do, before going to this "CH1 buffer" bypass route, I tried a few things that didn't work:

1. I replaced the buffer array with a brand new buffer array, just rebuilt the array entirely via initialize array.  Nope.

2. I rebuilt the entire case structure of the impenetrable wall.  Nope.

3. I deleted the (shift register) path from the buffer to the case structure and reconnected it.  Nope.

4. I deleted the path from the state machine case and reconnected it as one long drag directly into the MemoryMove.  Nope.

5. Finally, despite the memory hog of "CH1 buffer," I managed to get my data through the wall. 

Why did I have to force the data out?  Why just this one line, channel 1?

I'm thinking "CH1 buffer" will lose scope leaving this case of the state machine and, maybe, I can have that memory back.  But, I just read a very long memory management document in LabVIEW help, and I don't think that's going to happen, unless I request to deallocate at the exit of the subvi, but then that'd cause recreation of the data to the driver vi.

Hence, technically, debug continues.  What in the world is going on?  I need to look at that force LabVIEW to copy thing at the branch. (This is what I mean by terminology and searching.  The terminology must be correct or you won't find it.) 

---

The LabVIEW function to force LabVIEW to Always Copy the data at a wire branch is called "Always Copy"  that's why I asked if you had tried using the function previously. 😀

So now, let's go back and get your thread back on the tracks.  State plainly the software requirement involving the measurement your system must record.  Ignore HOW you expect to find the measurement. Thats what we will help you with since we have amoung us centuries of experience with developing test and measurement systems using LabVIEW. 😀

[rolfk]

---

@*3d0g wrote:

However, there is no way I'm posting my scope software to this forum.  It is loaded with non-public material.  It is not happening.  I may post a snapshot of a dataset or a partial screen output, but that's about it, and maybe.  No, we go by words this time or we don't go on this one.  I know everyone wants to see vis, but sometimes you can't have it.  It is what it is.

---

Nobody is talking about you posting your huge VI with all kinds of proprietary super secret patent pending technology. What works best is to actually take a step back and try to recreate the problem you are seeing in a much simpler VI. If you can reproduce it in that way you have proven there is a bug in LabVIEW once some knowledgable people have looked at it.

i’m still fairly convinced from my own 30 years of wire working, that it is a wiring error that you did but can’t see without starting to move around the tunnels to see if there are no hidden wires that connect differently than you think they do from a cursory glance at the diagram.

[*3d0g]

JÞB:

First, to answer your question.  I want to capture 32MSa of 16-bit data from four channels of an oscilloscope and work with it without LabVIEW running out of memory.

Currently the subject is PicoScope.  The thread began as trying to understand LeCroy's software, how it could possibly be sending >32MSa out to (DBL) waveforms.  (I tried to retain the OEM, but someone asked me who it was.)  The other tandem thread was me playing with MemoryMove, seeing just how much memory I could use before LabVIEW ran out of memory on me and get input from folks like you about what I could be doing wrong in my vi design.  Both threads have been very helpful, information-wise.  However, I have not found my solution, yet, which means no one has solved my immediate problem.  Currently I'm trying the shift register idea, but I've had to find a clunky workaround to get it to work.  BTW, when I said "source" referring to the buffer (pointer) to the MemoryMove, it should be understood I was saying that's the destination buffer pointer, where the raw data will go, the source for further processing.  I see that fundamental buffer, outside the whole shebang as the source for raw data.

This thing really has me puzzled.  I can only figure this is a LabVIEW bug with MemoryMove, somehow, or something is up with the shift register on just this line, somehow.  I've found this "CH1 buffer" workaround, but I don't really want to keep it.  I don't think I've implemented the shift register concept correctly for just this one line, somehow.       

[*3d0g]

Rolfk:

That's where I was going next. 🙂  Make a case structure that reads memory using shift registers to store the data.

It's a pain to do that, but this is quite the puzzle to me, and it'll help me understand LabVIEW better than I do, hopefully.  This would be an odd LabVIEW bug.  I think this is an error in my shift register implementation.  But, I still need to rule out something, first, and it is something that must be done, anyway.  For all I know it'll fix this problem.

I still haven't implemented the other shift registers, the ones for the double (DBL) data.  In other words, that side of things hasn't been changed.  That side used the "hairball." 🙂

[*3d0g]

I should correct that and say that double side also used the "hairball."

Both sides used the hairball, but now the raw data side is using shift registers, instead. ...which then led me to this peculiar issue with the CH1 path.

[*3d0g]

I should also add one other thing.  The solution to a problem isn't a statement of words unless the statement is proven to be correct by a result.  What I'm doing, now, is testing the solution offered by that vi of years ago, the one that suggested shift registers.  Will they do the trick?  I don't know, yet.